Drupal configuration workflows is powerful and extensible, but sometimes you need some extra help. Configuration in Drupal can be difficult to understand and often fraught with difficulties. The core configuration system is pretty robust and simple to understand, but when you add in things like overriding config in settings files, config split or config ignores things get more complicated. You can easily get tied up in configuration ignore rules, or shoot yourself in the foot without even realising it.
Thankfully, there are a 4 modules to help you work with managing configuration, in different ways.
Config Override Warn
In Drupal, it is possible to override the configuration in the settings.php file by using the $config variable. Setting it here will allow Drupal to merge it into your active configuration upstream. For example, common use of this in development environments is to turn off the CSS preprocessing on a site in the settings.php file, which is done by adding the following line.
$config['system.performance']['css']['preprocess'] = FALSE;
With this change in place, your CSS will not be preprocessed, which is great for speeding up local development.
The difficulty here is that any configuration setting you change either through importing configuration or via the Drupal interface will not be changed. How many times have you saved a form only to find the form save did nothing because you had forgotten you added an override? Configuration override warn solves this problem.
This is a very simple one that looks to see if any of the configurations on the form you are looking at has been overridden. If it has, then it will print a large banner at the top of the page to tell you about this.
Here is the performance form in Drupal, but with the configuration override warn module installed it shows me I have the CSS preprocess set to false so changing this value in the form will do nothing.
I installed this purely out of interest, but it soon proved very useful and saved me quite a bit of headaches. It is now a pretty standard part of my Drupal dev work.
Webform Config Ignore
Webform is a powerful module that has lots of functionality and integrates with Drupal to create fully featured forms. These forms can be exported to configuration and deployed like any other configuration. The problem here is that the Webforms are in a middle ground between configuration and content. As they can be exported and imported through configuration synchronisation they can be treated as site configuration. Because your users can alter or create Webforms any import or export process needs to take that into account.
For example, let's say that you deploy a site to production that contains the Webform module and a configuration import/export process. All will be well until your users create or change the Webforms on the site. At which point you need to export and commit that configuration or it will be simply deleted in favour of the previously committed version. Your users will probably be quite annoyed by their Webforms being reset every time you deploy any changes to the site.
The solution to this is to either keep on top of these changes or to simply ignore them. The configuration ignore module can be set up in a way that ignores all user alterable Webform related content, which means you can import and export without removing changes your users have made to Webforms.
Whilst it is perfectly possible to use the configuration ignore module to filter out your Webform configuration from your Drupal site the Webform Config Ignore module does this without you having to worry about it. This simple module vastly simplifies your configuration ignore settings and makes it difficult to override your Webform configurations unless you really want to. It has no forms or interface to speak of, it's only function is to tell the configuration ignore module that Webform configuration is to be ignored.
If you really want to allow Webforms to be imported you can set the Webform_config_ignore_disabled setting in your settings.php file.
$settings['webform_config_ignore_disabled'] = TRUE;
With this in place, when you run configuration import then any changes made to Webform configurations will be applied to your site. I would still opt to import special Webform configurations through update hooks, but if you want a unilateral import of all Webforms then this is a good option.
Configuration Update Manager
When I first saw the configuration update manager module I wasn't too sure about what it did. However, it provides a crucial missing link between your current configuration and the configuration provided by third party modules and install profiles.
Let's say you have a Drupal site setup with some modules might have installed their own configuration during setup. It's quite common for modules to include some minor configuration on your site so they can function correctly. Sometimes this might be in the form of a View, or some path auto configuration. Modules might install any type of configuration is compatible with your system.
When the modules you have installed update they will often include update hooks in order to update any configuration changes. This is the reason why it is important to export your configuration after updating modules as there might be configuration changes are required for the site to function correctly. This doesn't always happen though as it is impossible for Drupal to automatically update configuration you have altered. If you have changed or added configuration items to an existing configuration entity then Drupal will either remove them or fail to integrate it's changes into the changed configuration.
Through the use of the configuration update manager you can inspect the differences between your current site configuration and what exists in your Drupal code base.
The following screenshot shows the changed configuration items that have been altered on a test Drupal site. Even with minimal alterations the configuration supplied with the core system and modules can deviate from your installed configuration. It will also show you new configuration items added to the system so you can optionally install new configuration items that weren't previously available.
Whilst not always useful, the information it shows you is invaluable as it allows you to integrate any changes made to your configuration upstream you wouldn't otherwise know about.
This module also solves a small problem I have encountered during developing Drupal migration. As Drupal migration is mostly stored in configuration if you change the configuration in your module you need to uninstall and re-install the module to import those changes. Using configuration update manager allows you to import those items without having to reset the entire module.
Configuration Development
I briefly touched on including configuration in your modules in the previous section on the configuration update module, but this is a really useful way of ensuring your modules install with their needed components. You should always try to build entities, fields and other components of your site with their re-use in mind. This means naming things in a generic way, but also by including configuration in the module itself so if you need to install the module on another site you can just include the module and it will configure itself.
Whilst the idea of this is pretty simple (and is well described in the Drupal documentation) the main difficulty is in building modules that contain the configuration you need, which is where the configuration development module comes in. This module is designed to aid in the inclusion of configuration files in your modules and ultimately allow them to be self-configuring.
The interface the module comes with is pretty simple. There are two text areas that you plug your configuration items into, giving you the ability to automatically export or import the configuration you need directly within the module itself. This means you can tweak that View or path auto setting in your Drupal site and have the configuration automatically exported straight away. This will save time and effort when setting up your custom module configuration.
Once you have added settings to this form you don't need to action the import or export, the configuration items are synchronised at the start of every page load. This isn't something you would install on a production site, but it does make quick work of packaging together modules into re-usable components.
Note, if you are building an install profile then you can also use the Config Profile module. This module will copy the configuration you export into your designated install profile directory, making multi-site install and distributions much easier to manage.
Of course, these modules will only aid in the configuration management of your sites. Ultimately, any difficulties you face in configuration management are usually created by setting things up incorrectly in Drupal. If you start out on the wrong path with configuration management it can be hard to bring the site back into working order. This is especially the case if you run Drupal multi-site as a single configuration resource can interact with multiple sites.
I have previously talked in detail about how to get started with Drupal configuration setups, but if you want some help then please get in touch.