Configuration Split

Background

The Drupal 8+ configuration management works best when importing and exporting the whole set of the sites configuration. However, sometimes developers like to opt out of the robustness of CM and have a super-set of configuration active on their development machine and deploy only a subset. The canonical example for this is to have the devel module enabled or having a few block placements or views in the development environment and then not export them into the set of configuration to be deployed, yet still being able to share the development configuration with colleagues.

This module allows to define sets of configuration that will get exported to separate directories when exporting, and get merged together when importing. It is possible to define in settings.php which of these sets should be active and considered for the export and import.

Documentation

Video and Slides from the Drupalcon Vienna presentation.

Help to improve the online documentation.

Notice

The important part to remember is to use Drupal 8s configuration management the way it was intended to be used. This module does not interfere with the active configuration but instead filters on the import/export pipeline.
If you use this module you should have a staging environment where you can let the configuration management do its job and verify that everything is good for deployment.

How it works

When importing config, the configuration is read from the main sync directory and also from split directories. Drupal is presented with the unified configuration of the sync directory and the extra configuration defined in splits.
Importing and exporting works the same way as before, except some configuration is read from and written to different directories. Importing configuration still removes configuration not present in the files. Thus, the robustness and predictability of the configuration management remains.

Upgrade from version 1.x to 2.x

Be sure to run the update hooks so that the configuration is switched to use the new schema. As with any module update that changes configuration: do not forget to export the site configuration after the update hooks have run in your development environment.

Attention: 1.x depended on Config Filter, but 2.x uses the core API. If you have not explicitly required Config Filter before Composer will remove it when updating. But then you are left with a drupal module still being installed but no longer available in the code base.
In order to properly uninstall Config Filter you should explicitly require it and then uninstall it, and remove it from composer.json only in a later deployment.

Key difference: 1.x could only split the whole config files. 2.x can split individual keys by creating a "config patch" file. This is turned on by default and you can switch it back to the 1.x behaviour by configuring your split to "Do not patch dependents".