Change configuration directly on a Drupal 8 production site

Managing native configuration with Drupal 8 makes it very easy to make changes or additions to the configuration from a site instance (such as a development environment) to another site instance (the production environment). These configuration exports and imports of a site are made in one piece: that is, the entire configuration of a site, which is updated. Thus if configuration additions have been made to the production site, they will be overwritten at the next import of the configuration if these configurations are not present also on the source environment.

But there are valid use cases where certain configurations can and must be modified directly in production. Examples of immediate use are, for example, the creation of new Webform forms, or the creation or update of new Newsletters managed with the SimpleNews module. It is quite legitimate for a webmaster to modify or create new NewsLetters on the production site. It's almost like content, except that ... it's a configuration entity.

Let's discover how to manage these particular cases with the module Configuration split, module that will allow us to maintain an organized process to manage the evolution and maintenance of a site in production while allowing the modification of some configurations live.

Configuration of the module Configuration split

We will illustrate the configuration to be put in place to allow users to create new Simplenews Newsletters on the production site.

After installing the Configuration split module, we create a new parameter for this module. We assume that the Drupal 8 project is based on composer and that its synchronization folder is located on the ../config/sync path relative to the project docroot.

First we create a new ../config/excluded directory. This directory will host the YML files of the configurations that have been created in production.

Then we define a new Configurations split parameter.

We give it a name, tell it the configuration files storage directory created previously (../config/excluded), then the most important thing: we do not enable this configuration by leaving the Active option unchecked.

We continue the configuration, using the Conditional Split section.

Here we can select an existing configuration, or specify configurations using wildcard. Here we indicate to cut the configurations of all Simplenews newsletters, by means of simplenews.newsletter.* files. And we enable the Split only when different option, which allows us to keep identical configurations between environments in the main synchronization directory containing all site configuration files.

Then we can record, to get.

Note again the Inactive status of our configuration. It must remain so on all source environments other than production.

New process for importing the configuration

Once this configuration is created, we export it, and then commit it on our depot and then deploy it on all our environments, including production. For example like this, but of course this is to adapt to your current process.

dev > drush cex
dev > git add .
dev > git commit -m "config split excluded"
dev > git push

prod > git pull
prod > drush cim

Once this excluded configuration imported on the production site, we will activate it from the settings.php file by adding a configuration override, which will obviously only be present on the production environment.

And we get on our production site our Excluded configuration which is now activated.





And it's over, or almost. From now, it will be necessary before all import of configuration on the site in production, to launch beforehand an export of the configuration excluded by means of the command drush config-split export (or drush csex).

This command will detect if new configurations are present on the production site, or if existing ones have been modified, compared to the general configuration of the site, and if necessary will export these modified or added configurations in the directory ../config/excluded.

And the general configuration import command, drush cim, will gather both the configuration present in the main directory ../config/sync, and also the configuration present in the ../config/excluded directory.

The new process of updating and importing the configuration to the production environment can then look like this

prod> drush csex -y excluded
prod> drush cim -y

Or using a small shell script

#!/bin/bash
echo "-----------------------------------------------------------"
echo "Exporting excluded config"
drush csex -y excluded

echo "-----------------------------------------------------------"
echo "Importing configuration"
drush cim -y

From now on, you will be able to create and manage our Newsletters as simply as it was content, directly on the production site. Of course the same concept can apply to any configuration that you want to be able to manage in production: Webform forms for example, or the positioning of some blocks, etc. while maintaining a structured process for maintaining your site in production using Drupal 8 Configuration Management.

Thanks to Jon Minder for his article Advanced Drupal 8 Configuration Management (CMI) Workflows that helped me more, and of course the creator and maintainer of this module particularly useful.