Using the Configuration Module Filter in Drush 8

Having a Dev/Test/Live workflow is indispensable to safe and convenient website development. If your workflow involves frequently refreshing your development database with the latest information available on the live site, then you may find that you must keep enabling the modules used only in the development site on every iteration. Various solutions exist in Drupal 7 to automate this process; for example, the drush sync-enable example file allows you to list modules in your site alias file that should be automatically enabled every time the database is copied to that particular site environment via the drush sql-sync command.

Drupal 8 complicates this scenario slightly, though. In Drupal 8, the enabled/disabled state of modules is now also stored in the configuration system. It is therefore also important to ensure that config-import does not enable or disable any modules that must remain installed or uninstalled in a specific environment. There is an additional concern at config-export time as well: in Drupal 8 site development, exported configuration files are usually committed to a version control repository. It would be undesirable if every configuration export from the development environment showed the development modules being enabled, and every configuration export from the live environment showed them being disabled. Ideally, we want to keep this noise out of the configuration exports, so that the only items that show up in the commit diff are the configuration changes intended for that commit.

The config-import and config-export commands in Drush 8 now support a new feature that make this easy.  The --skip-modules flag can be provided at either import or export time to specify the modules that should be ignored by the current operation. Using skip modules with config-import will prevent any module listed from being enabled or disabled during the import operation, regardless of any information about that module that may exist in the imported configuration. Similarly, using skip modules in config-export will cause the listed modules to keep whatever value they had in the existing export file, rather than taking on the current enabled or disabled state from the Drupal site.

To make this happen automatically, you can set a list of development modules to ignore during import and export via command-specific options in your drushrc.php file, as shown in the example below:

$command_specific['config-export']['skip-modules'] = array('devel');
$command_specific['config-import']['skip-modules'] = array(‘devel');

The best place to put this drushrc.php file is in a folder named drush just inside your Drupal root. This will ensure that all Drush operations that target this site will use these options, wherever they originate. Once you have set up your development modules to be ignored during config import and config export, you may use drush pm-enable to turn on your development modules in your development environment just once, and they will not be disabled again the next time you import your configuration files. You will still need a solution for enabling or disabling modules when you move the database between environments, such as the drush sync-enable example previously mentioned.

If you have other configuration values that you would like to vary by environment, you should use Drupal 8’s built-in configuration override system, which allows you to set specific configuration values either in your site’s settings.php file, or via configuration override hooks in a custom module. Instructions on how to do these things can be found in the configuration override system documentation.

Customizing each of your site’s environments is an important step in keeping your development workflow smooth and efficient. Now you have the tools you need to do it in Drupal 8 as well.