Drush 9 brings many breaking changes to common workflows. BLT version 9.0.x and above aim to be fully compatible with Drush 9. However, some manual updates to your codebase may be required.
Aliases
Drush 9 uses a new format for site alias files. You will need to convert your existing .aliases.drushrc.php files to the new .aliases.yml format.
If you are using BLT's suggested convention of storing aliases in drush/site-aliases, then the process of converting to the new format is as simple as running drush site:alias-convert.
Installing site from existing configuration
Almost all BLT builds import configuration during site install. To make this continue working with Drush 9, you must do one of the following:
- Use the most recent version of Lightning, or ...
- Use the config installer profile, or ...
- Make the following manual modifications to your application.
Heads up: the method described below is being deprecated. You can still use it for now, but it will stop working eventually.
Add core patch to support configuration import from profiles (this is manual, there is no command):
"patches": {
"drupal/core": {
"Allow a profile to be installed from existing config": "https://www.drupal.org/files/issues/2788777-91.patch"
}
}
Add the following key to your custom profile's [profile-name].info.yml file, indicating that configuration should be imported during profile installation:
config_install: true
Finally, it's recommended to remove any explicit dependencies, default configuration, or install hooks from your custom install profile in order to prevent conflicts with site configuration stored in `config/default`.
If you are using features, part of features is incompatible with Drush 9. Update project.yml to work around:
cm.features.no-overrides: false
Drush Launcher and global vs local binaries
Drush 9 should no longer be installed as a global package (i.e. available from the command line even outside of a Drupal project context). Every Drupal project should depend on its own local version of Drush. BLT already includes a dependency on Drush, there's no need to add it to your own composer.json.
In order to call Drush from the command line, you should install the Drush Launcher, a shim that allows you to call a project-local Drush version while in a Drupal project directory. See the Drush installation instructions.
Note that if you have a globally installed version of Drush (especially Drush 8), this may interfere with your ability to use Drush 9 on individual projects.
Converting Custom Code
Do not overlook the fact that any custom project modules that have been written that use custom Drush commands must also be converted.
Warning: migrating to Drush 9 will convert your drush.inc files into src/Command classes, which will cause BLT to validate these files during blt validate. It is likely that you will need to refactor your code to be better compliant with PHP standards during this process (e.g. dependency injection, comment length, etc).
Updating Cloud Hooks
BLT 9 has updated the paradigm for cloud hooks that interact with the Acquia Cloud. To generate new cloud hooks, follow these steps:
1. remove existing hooks
2. run blt recipes:cloud-hooks:init
3. commit updated hooks
Updating Cron Jobs
If you are running cron jobs with the Acquia Cloud that require Drush, the jobs must be updated to operate with the drush9 bin.
Warning: this includes site cron and backup scripts!
An example job is:
/usr/local/bin/drush9 --uri=http://[site-uri] --root=/var/www/html/[AH_SITE_NAME].[AH_SITE_ENV]/docroot -dv cron &>> /var/log/sites/[AH_SITE_NAME]/logs/[hostname] -s)/drush-cron.logMake sure to replace the tokens [] with the actual values from your subscription!