Installing CiviCRM on Drupal 8 via composer.sh

################################
#           _           _   _  #
#     /\   | |         | | | | #
#    /  \  | | ___ _ __| |_| | #
#   / /\ \ | |/ _ \ '__| __| | #
#  / ____ \| |  __/ |  | |_|_| #
# /_/    \_\_|\___|_|   \__(_) #
#                              #
################################

#
# This is no longer the recommend way to get a Drupal 8 and CiviCR
# codebase assembled!
#
# Please see this article for the currently recommend way:
#
#   https://www.mydropwizard.com/blog/better-way-install-civicrm-drupal-8
#
# Below is the previous contents of this Gist...
#



#
# One day, hopefully, in the not-so-distant future, all that will be necessary is:
#
#   composer require civicrm/civicrm-core
#
# But for now, the following commands will do the trick!
#
# NOTE: These command should all be run at the top-level Drupal directory.
#

# What version do we want?
CIVICRM_VERSION=5.3.1

# Repositories aren't inherited from requirements, so we have to put this one from civicrm-core/composer.json again
composer config repositories.zetacomponents-mail vcs https://github.com/civicrm/zetacomponents-mail.git

#
# RE-RUN THE COMMANDS BELOW TO UPGRADE CIVICRM (after first changing $CIVICRM_VERSION)
#
# (NOTE: if you do an upgrade, remember to do the database updates on the site afterward
#  via /civicrm/upgrade?reset=1 or 'drush cvupdb')
#

# Require civicrm-core at the requested version.
composer require "civicrm/civicrm-core:$CIVICRM_VERSION"

# Run 'bower install' to get Javascript stuff
(cd vendor/civicrm/civicrm-core && bower install)

# Download the latest Drupal package to copy some stuff that's
# generated by the build and included in release tarballs.
wget -O /tmp/civicrm.tar.gz https://download.civicrm.org/civicrm-$CIVICRM_VERSION-drupal.tar.gz
tar -xzf /tmp/civicrm.tar.gz -C /tmp
# Copy the 3rd party dependencies (Whaaaat? Someone who's been doing CiviCRM for a while
# will need to explain this to me :-) Why not use composer for pulling in these too?)
cp -r /tmp/civicrm/packages vendor/civicrm/civicrm-core/
# Setup the civicrm-version.php
cat /tmp/civicrm/civicrm-version.php | sed -e 's/Drupal/Drupal8/' > vendor/civicrm/civicrm-core/civicrm-version.php
# Copy sql
cp -r /tmp/civicrm/sql vendor/civicrm/civicrm-core/
# Copy some misc other things
cp /tmp/civicrm/civicrm.config.php vendor/civicrm/civicrm-core/
cp /tmp/civicrm/CRM/Core/I18n/SchemaStructure.php vendor/civicrm/civicrm-core/CRM/Core/I18n/
cp /tmp/civicrm/install/langs.php vendor/civicrm/civicrm-core/install/
# Clean-up
rm -rf /tmp/civicrm.tar.gz /tmp/civicrm

When you unzip civicrm-4.7.22-drupal.tar.gz , make sure you delete the civicrm/drupal folder . The package you are downloading includes the Drupal 7 module and some submodules, and those need to be deleted.

When they build the tar file for download there is a build process with 3 repos, civicrm-core , civicrm-packages , and civicrm-drupal...Those are the names of the repos in Civicrm's github https://github.com/civicrm/ They create directory civicrm, put civicrm_core in that folder, then packages in a packages directory so in civicrm/packages. composer install, and it needs npm too as part of the process. I forgot if there's other repos...
after they run all the dependency things, the tar it up and put it on the download page.

You could just use 4.7.22 in vendor/civicrm , delete the Drupal folder. I don't think that master is very far ahead compared to 4.7.22 its only been a couple weeks since it branched off. An do Drupal 8 related stuff has been done in that time...

So, the unzipping of civicrm-4.7.22-drupal.tar.gz is placing the files in /tmp and just copying some stuff that I couldn't find in the Git repo, but that is necessary to properly install -- it isn't putting the unzipped code in the Drupal root anywhere, so I don't need to worry about removing the Drupal directory! But, yeah, that whole part could be improved (and, ideally, eliminated) :-)

Now that I know where civicrm-packages comes from, that bundle could be installed via composer (although, it'd be even better if each individual package was installed via composer, and composer totally can install legacy PEAR packages)

I'm not sure what to do about the SQL files or civicrm-version.php -- those are generated by some build process, but Composer is pulling the Git repo which doesn't have them. We'll need some work around for that.

Anyway, all the copying from the build tarball will need to be eliminated to have a pure composer install working - my CiviCRM knowledge is just not (yet?) up to the task. Thanks for the additional details so far!

You could just use 4.7.22 in vendor/civicrm , delete the Drupal folder. I don't think that master is very far ahead compared to 4.7.22 its only been a couple weeks since it branched off. An do Drupal 8 related stuff has been done in that time...

Well, then we're not installing via Composer! :-) There's also a couple minor changes in my fork necessary for the composer installed code to work, so I wouldn't want to totally wipe out that directory

We're moving the packages to be installed with composer over time...we just moved 3 to be installed by composer.json in civicrm-core this last release...in time most if not all of them will be done that way, I think that's Tim's plan. (Time is the head honcho of CivICRM development BTW).

This command fails for me as of the latest drupal release (8.3.7)
$ composer require 'phpoffice/PHPWord:dev-zend-version as 0.13.0'

Update: I was able to get around this issue by manually adding this to my composer.json require

    "require": {
        ...
        "phpoffice/PHPWord": "dev-zend-version as 0.13.0",
       ...
    },

 Problem 1
    - The requested package as could not be found in any version, there may be a typo in the package name.

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
   see <https://getcomposer.org/doc/04-schema.md#minimum-stability> for more details.

Read <https://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.

Can/should this be updated for 4.7.25?

@konadave Yes! We just started using 4.7.25 and so there should be a forked repo for it

I've updated the instructions above, and put in some notes on how to upgrade if you had previously installed 4.7.24 or earlier

This command fails for me:
composer require 'phpoffice/PHPWord:dev-zend-version as 0.13.0'

[InvalidArgumentException]
Package phpoffice/PHPWord at version dev-zend-version as 0.13.0 has a PHP
requirement incompatible with your PHP version (7.0.25.0)

Any advise...

Tried Drupal 8.4.3 and CiviCRM 4.7.27. Seems to install correctly but far to be functional, I just went to "localization" and changed some things, save, an DB Error: no such table. Now can't use Civi :)

First I commented reporting a different error but was because I forgot to log out/log in on the site.

Thanks

OK, I can confirm the error.
Install Drupal 8.4.3 + CiviCRM 4.7.27, then enable multilanguage support in CiviCRM from Settigns - Localization - Enable Multiple Languages and you get an error DB Error: no such table. I checked the log file and this what I can see: https://gist.github.com/yaazkal/498fc949c62bd125168e990ef5ba635a

Should I open an issue @dsnopek on JIRA? or on GitHub?

From the error log I see ** Unknown column 'v.label' in 'field list'

Looks like after checking the Enable Multiple Languages option and hit save, the label colum is renamed or erased.

Before enabling multilanguage support

describe civicrm_option_value;
+-----------------+------------------+------+-----+---------+----------------+
| Field           | Type             | Null | Key | Default | Extra          |
+-----------------+------------------+------+-----+---------+----------------+
| id              | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| option_group_id | int(10) unsigned | NO   | MUL | NULL    |                |
| label           | varchar(512)     | NO   |     | NULL    |                |
| value           | varchar(512)     | NO   | MUL | NULL    |                |
| name            | varchar(255)     | YES  | MUL | NULL    |                |
| grouping        | varchar(255)     | YES  |     | NULL    |                |
| filter          | int(10) unsigned | YES  |     | NULL    |                |
| is_default      | tinyint(4)       | YES  |     | 0       |                |
| weight          | int(10) unsigned | NO   |     | NULL    |                |
| description     | text             | YES  |     | NULL    |                |
| is_optgroup     | tinyint(4)       | YES  |     | 0       |                |
| is_reserved     | tinyint(4)       | YES  |     | 0       |                |
| is_active       | tinyint(4)       | YES  |     | 1       |                |
| component_id    | int(10) unsigned | YES  | MUL | NULL    |                |
| domain_id       | int(10) unsigned | YES  | MUL | NULL    |                |
| visibility_id   | int(10) unsigned | YES  |     | NULL    |                |
| icon            | varchar(255)     | YES  |     | NULL    |                |
| color           | varchar(255)     | YES  |     | NULL    |                |
+-----------------+------------------+------+-----+---------+----------------+
18 rows in set (0.01 sec)

After enabling multilanguage support (label is now label_en_US and also description is now description_en_US)

describe civicrm_option_value;
+-------------------+------------------+------+-----+---------+----------------+
| Field             | Type             | Null | Key | Default | Extra          |
+-------------------+------------------+------+-----+---------+----------------+
| id                | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| option_group_id   | int(10) unsigned | NO   | MUL | NULL    |                |
| value             | varchar(512)     | NO   | MUL | NULL    |                |
| name              | varchar(255)     | YES  | MUL | NULL    |                |
| grouping          | varchar(255)     | YES  |     | NULL    |                |
| filter            | int(10) unsigned | YES  |     | NULL    |                |
| is_default        | tinyint(4)       | YES  |     | 0       |                |
| weight            | int(10) unsigned | NO   |     | NULL    |                |
| is_optgroup       | tinyint(4)       | YES  |     | 0       |                |
| is_reserved       | tinyint(4)       | YES  |     | 0       |                |
| is_active         | tinyint(4)       | YES  |     | 1       |                |
| component_id      | int(10) unsigned | YES  | MUL | NULL    |                |
| domain_id         | int(10) unsigned | YES  | MUL | NULL    |                |
| visibility_id     | int(10) unsigned | YES  |     | NULL    |                |
| icon              | varchar(255)     | YES  |     | NULL    |                |
| color             | varchar(255)     | YES  |     | NULL    |                |
| label_en_US       | varchar(512)     | YES  |     | NULL    |                |
| description_en_US | text             | YES  |     | NULL    |                |
+-------------------+------------------+------+-----+---------+----------------+
18 rows in set (0.01 sec)

I found this issue: https://issues.civicrm.org/jira/browse/CRM-19915

I opened and issue on CiviCRM, I can reproduce the same error on a D7 installation: https://issues.civicrm.org/jira/projects/CRM/issues/CRM-21627

@yaazkal Aha, thanks for sharing your problem and the JIRA link. That isn't a problem that we've seen, but we haven't been doing upgrades from 4.6 with multilingual

If you want to also have multilanguage support you can add at the end of this script:

# Download languages
wget -O /tmp/civicrm-l10n.tar.gz http://downloads.sourceforge.net/project/civicrm/civicrm-stable/$CIVICRM_VERSION/civicrm-$CIVICRM_VERSION-l10n.tar.gz
tar -xzf /tmp/civicrm-l10n.tar.gz -C /tmp
#copy sql
cp -r /tmp/civicrm/sql vendor/civicrm/civicrm-core/
#copy l10n
cp -r /tmp/civicrm/l10n vendor/civicrm/civicrm-core/
# Clean-up
rm -rf /tmp/civicrm-l10n.tar.gz /tmp/civicrm

There is a workaround before enabling multilanguage support that you want to follow anyway: https://issues.civicrm.org/jira/browse/CRM-21627

Thanks, @yaazkal!

For folks who don't know about it yet, there is work to make a new installer for CiviCRM that would allow installing in Drupal 8 without some of the process in this Gist (yay!), including generating the multilingual data. Here's the relevant issue:

civicrm/civicrm-setup#1

Hello @dsnopek I am following your great gist and I found a problem with a dependency on composer on this line:

composer require 'phpoffice/PHPWord:dev-zend-version as 0.13.0'

Problem 1
    - Installation request for civicrm/civicrm-core dev-roundearth-4.7.28 as 4.7.28 -> satisfiable by civicrm/civicrm-core[dev-roundearth-4.7.28].
    - civicrm/civicrm-core dev-roundearth-4.7.28 requires phpoffice/phpword ^0.14.0 -> satisfiable by phpoffice/phpword[v0.14.0] but these conflict with your requirements or minimum-stability.

I changed that line to this:

composer require 'phpoffice/PHPWord:dev-zend-version as 0.14.0'

And it worked!

I know there is a new way to install this without this script incoming, but meanwhile, I believe this is the best thing we have. Just in case anyone else encounters this problem as well.

Thanks g3r4, I was getting the same exact error.

After using these instructions, when I try to run the civi cron job via "cv", or actually any run of "cv", I get this error:

 [Symfony\Component\Debug\Exception\FatalThrowableError]
  Class 'ComposerAutoloaderInitDrupal8' not found

Figured out my issue. Somewhere in my installation process, the autoloader init class used by all the composer autoload scripts was changed to ComposerStaticInita3016124dfda459b3e31053684e478b2 instead of ComposerStaticInitDrupal8:

vendor/autoload.php
vendor/composer/autoload_static.php
vendor/composer/autoload_real.php

Not sure what I did to cause that. (Admittedly, I've been all over the map getting certain things modified and noticed this problem late in the game, so perhaps I deviated from the steps somewhere.) Changing all occurrences of the corrupted value back to the correct one made "cv" work properly.

Now that cv executes, it still doesn't trigger the scheduled jobs. Running this:

cv api --user=admin job.execute

... results in this:

{
    "is_error": 0,
    "version": 3,
    "count": 1,
    "values": 1
}

And CiviCRM still reports no cron jobs have been executed in the System Status page and also shows no logs in the Scheduled Jobs area and says the Scheduled Jobs "last run" is "never". Any ideas?

Ok, from what I can tell cron jobs in Civi cannot be run through any known method once these instructions have been followed. I've tried cv, drush, and the old-fashioned web access. cv fails. drush fails, and the web access url doesn't exist. Has anyone successfully run cron for Civi? If so, what method did you use?

@g3r4 : This also worked for me -> composer require 'phpoffice/PHPWord:dev-zend-version as 0.14.0'

:...: Since this step did not help, -> composer require "civicrm/civicrm-core:dev-roundearth-$CIVICRM_VERSION as $CIVICRM_VERSION"

I took the advice from,
@yaazkal : This was very helpful, but the initial step I had to do manual:

# Download languages
:..: this step did not work or me -> wget -O /tmp/civicrm-l10n.tar.gz http://downloads.sourceforge.net/project/civicrm/civicrm-stable/$CIVICRM_VERSION/civicrm-$CIVICRM_VERSION-l10n.tar.gz

:.: Manually went here and found the file that has -> l10 in tar.gz <- (ex.. /civicrm-stable/5.2.1/civicrm-5.2.1-l10n.tar.gz)
-> https://sourceforge.net/projects/civicrm/files/civicrm-stable/5.2.1/civicrm-5.2.1-l10n.tar.gz/download
tar -xzf /tmp/civicrm-l10n.tar.gz -C /tmp

..everything else works

#copy sql
cp -r /tmp/civicrm/sql vendor/civicrm/civicrm-core/
#copy l10n
cp -r /tmp/civicrm/l10n vendor/civicrm/civicrm-core/
# Clean-up
rm -rf /tmp/civicrm-l10n.tar.gz /tmp/civicrm

Thank you all, great help.

@jptillman I wonder if you have a user "admin" on your install? Check the cms user you use in your cron task has permissions to run civi tasks required.

https://docs.civicrm.org/sysadmin/en/latest/setup/jobs/

@xurizaemon I figured this out a couple of weeks ago, and it was the admin user problem you suspected. My admin user is named something else. I dropped the use of --user=admin altogether and it worked, perhaps because it defaults to the normal admin user id.

Just tried running this script and got the following output and errors on a Drupal source directory that was created via the standard composer template project (https://www.drupal.org/docs/develop/using-composer/using-composer-to-manage-drupal-site-dependencies#download-core).

Looks like there are some version conflicts. Any tips on how to resolve?

./composer.json has been updated
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositorUpdating dependencies (including require-dev)         Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - civicrm/civicrm-core 5.3.1 requires civicrm/civicrm-cxn-rpc ~0.17.07.01 -> satisfiable by civicrm/civicrm-cxn-rpc[v0.17.07.01].
    - Installation request for civicrm/civicrm-core 5.3.1 -> satisfiable by civicrm/civicrm-core[5.3.1].
    - Conclusion: remove psr/log 1.1.0
    - Conclusion: don't install psr/log 1.1.0
    - civicrm/civicrm-cxn-rpc v0.17.07.01 requires psr/log ~1.0.0 -> satisfiable by psr/log[1.0.0, 1.0.1, 1.0.2].
    - Can only install one of: psr/log[1.0.0, 1.1.0].
    - Can only install one of: psr/log[1.0.1, 1.1.0].
    - Can only install one of: psr/log[1.0.2, 1.1.0].
    - Installation request for psr/log (locked at 1.1.0) -> satisfiable by psr/log[1.1.0].


Installation failed, reverting ./composer.json to its original content.

@jptillman (or others running into this): run composer require psr/log:1.0 --update-no-dev

Waiting for this to be merged: civicrm/civicrm-cxn-rpc#8

I posted a recap of blocking issues (and links to various resources) here: https://lab.civicrm.org/dev/drupal/wikis/drupal8-composer

regarding the conflicting psr/log requirement:

As it seems the dependency is about to be updated to 1.1 anyway, another workaround is to set an alias in your (drupal) composer.json to "fake" 1.1 to be accepted for 1.0.0 by changing"require": { "psr/log": "^1.1"} to "require": { "psr/log": "1.1.0 as 1.0.0"}