ACTION REQUIRED: Drupal 8 Installs and Upgrades: Composer and Patches

Veröffentlicht
2020-08-27 20:06
Written by
DaveD - member of the CiviCRM community - view blog guidelines

CiviCRM has patches that it needs to apply to 3rd party libraries. Composer has a plugin to apply those patches for you. Simple, right?

By now anyone who has tried to install CiviCRM on Drupal 8 has met Composer. You need to update its configuration to make patches work.

So this is only Drupal 8?

Mostly. There is one unusual scenario for other CMS's: If you manage a site using git pulls directly from the civicrm/civicrm-XXX repositories. In this situation you would need to just make sure to pull civicrm-packages first before running "composer install". This would not apply to the more common situation where you maintain your own repository updated by tarball and then your live sites pull from your repository.

What you need to do:

See the installation guide for more details but either:

1. Add "enable-patching": true in the "extra" section of the top-level composer.json file, the file at the same level as vendor and web.

OR

2. Enable patching in composer's configuration using the command line: composer config 'extra.enable-patching' true

When do you need to do it:

You need to have done it back when you started installing CiviCRM on Drupal 8.

If you don't have a time machine you can do it now for your current site and then run composer install to apply the patches.

If you don't do it before running composer to update the files to version 5.30, then CiviCRM will crash when you try to use 5.30.

More details:

CiviCRM has two methods for managing 3rd party libraries. There's the ones managed using the traditional system where they are stored in the packages folder and the patched files are stored in the git repository. And there's the ones that are managed using composer and are not stored in the repository, and are patched on-the-fly by a composer plugin as you install them.

The problem hasn't been noticed much yet because the patches to-date to libraries installed the second way as composer dependencies have not been critical patches. What is changing in 5.30 is that the PEAR::DB library that was managed as part of the packages folder is now being installed as a composer dependency, and it has a more noticeable patch.

The patch was a bridge when php-mysql was being phased out and moved to php-mysqli because everyone's civicrm.settings.php file still had "mysql:" in the DSN strings. They likely still do. Without that patch which silently replaces mysql with mysqli, the DB library will try to load its mysql handler instead of mysqli, and since php-mysql doesn't exist anymore it will crash.