Configuration Management is improved in the next Drupal version

Nuvole offers a training at DrupalCon Amsterdam: "Drupal 8 Migration as a process" - register until October 27.

There are a few significant changes that landed in Drupal 8.8 with respect to configuration management:

The sync directory is defined in $settings and not $config_directories

The first one concerns everybody using Drupal 8 and especially going forward Drupal 9.
So far the config directory was set up with in settings.php with the variable $config_directories. This variable was an array for historical reasons when both the active configuration and the sync configuration were stored in files. But since Drupal 8.0.0 that was not the case any more, yet the array remained. Drupal only ever used one key, but developers saw an array and naturally assumed that there should be more than one key.

In the effort to avoid confusion and to streamline the configuration management we have now corrected this and added the config directory to the settings variable as $settings['config_sync_directory']. If for some reason someone still wants to have a workflow with multiple sync directories then that can still be achieved with a small amount of code since setting.php is a php file and the settings can be set conditionally. In my opinion though one sync directory is sufficient for the vast majority of workflows and this change will help to not confuse developers.

Event is dispatched before configuration import and export to transform the configuration

For me this is the biggest achievement for CMI 2. This allows contrib and custom modules to interact with the configuration synchronization in a very straight forward way. It is Config Filter in core but better, it is what I have been talking about at many Drupal events and finally it is in Drupal core, stable and available to everyone.
There is already a patch for Config Filter 2.x to be the bridge between modules depending on Config Filter and the new core API. Config Filter 2.x will be api compatible with Config Filter 1.x but instead of decorating the sync storage it will apply the filter plugins to the new core API.
In addition there is an issue for Config Distro on the way to model its API after the new event driven core API.

Modules can be excluded from the configuration synchronization

The latest major achievement which will be celebrated by many will be that it is finally possible to have devel installed on the development environment and not having to worry about it being deployed. This feature is already available in contrib since December 2017 with the contrib module Config Exclude. It uses Config Filter and is a relatively simple module with just one configuration option. This is why it was a good candidate to add to core as a proof that the new API works. The contrib module and the new core feature (yes you don't need to install a module it just works) both use the same setting:
$settings['config_exclude_modules'] = ['devel', 'stage_file_proxy'];
They work both alongside together so if you want to use this feature you don't have to wait for 8.8, you can use it on 8.6 and then when you upgrade to 8.8 you can simply uninstall Config Exclude and it just continues to work.

There has been some confusion about this feature and how it can be dangerous.
The excluded modules, (ie the modules listed in the settings array) are removed from core.extension.yml and all the config depending on them is not exported. When importing the configuration and the module is installed already the configuration from the site is added to the configuration to import just before validating the configuration for the import. That means that devel will not be uninstalled when you import the configuation that doesn't have devel in it. But it also means that the configuration that you exported is no longer the configuration you had when you devloped your site and if you exclude modules that are central to the site such as required modules such as system or user or modules that change a lot of configuration such as language or field then the configuration can not be imported on the target site any more. Your site will not break, but you can not deploy the new configuration.

The CMI 2.0 Session at DrupalCon Amsterdam will contain more about all of the above and what else is planned to come.

Tags: Drupal 8Drupal PlanetDrupalCon