Manage configuration items

Published at

April 13, 2020

Author

Erlend ter Maat

I love the way Drupal 8 offers on managing configuration - being able to store configuration settings, updated at admin pages, in yml files helps a lot. The bad news is that in practice the configuration management system is a little to rigorous in some cases. The good news is that Drupal core provides tools to fit the demands for configuration management in your development workflow.

Environment specific modules

The first way on which the basic configuration management method of Drupal needs a little push in the right direction is where you develop a web application on your local machine, and you deploy it to a production environment, or any other flow that consists of more then 1 stage of development.

During custom module development I always come to a point where I use one or two development modules, like Kint or Stage file proxy. You may switch the modules off at the production environment in the settings[.local].php, but the the modules are not intended to use at production sites. Without taking action your development modules end up in production via configuration files. In order to keep your production environment clean you would have to apply some kind of method to keep the modules out of the configuration.

Since version 8.8 Drupal provides a way to tell the configuration system which modules are to be ignored when exporting and importing configuration!

// @settings.local.php

/**
 * Exclude modules from configuration synchronisation.
 *
 * On config export sync, no config or dependent config of any excluded module
 * is exported. On config import sync, any config of any installed excluded
 * module is ignored. In the exported configuration, it will be as if the
 * excluded module had never been installed. When syncing configuration, if an
 * excluded module is already installed, it will not be uninstalled by the
 * configuration synchronisation, and dependent configuration will remain
 * intact. This affects only configuration synchronisation; single import and
 * export of configuration are not affected.
 *
 * Drupal does not validate or sanity check the list of excluded modules. For
 * instance, it is your own responsibility to never exclude required modules,
 * because it would mean that the exported configuration can not be imported
 * anymore.
 *
 * This is an advanced feature and using it means opting out of some of the
 * guarantees the configuration synchronisation provides. It is not recommended
 * to use this feature with modules that affect Drupal in a major way such as
 * the language or field module.
 */
$settings['config_exclude_modules'] = ['devel', 'kint'];

The other way around would also be possible: modules that only make sense on production environments, but not for local development. However, I would not recommend using this feature at the production settings.local.php. The module that does not make sense every time on local development may at some time be under construction itself. In that case the changes in configuration are easier to transfer to the production environment using the configuration manager, compared to a manual action after deployment. This is common for situations where the production environment requires a 3rd party software that it expects to find installed on the environment. Most of that modules provide a way to override the configuration at the local environment in this fashion:

// @settings.local.php

$config['varnish.settings']['enabled'] = FALSE;

Conclusion

With the ‘config_exclude_modules’ option Drupal offers great flexibility in using modules in any stage of web application development.