The Config Split module

Tags: Tech Blog Published:

Along with others in the Hydrant Dev team I attended the NWDUG unconference in Manchester earlier this month and a talk by @Paul_Gregory which addressed a subject I’ve asked myself the best way to solve when using Drupal 8 in a development, staging and live environment.

Being able to put Drupal’s configuration into version control is a feature I’d been looking forward to using as soon as it was announced it would be a major feature of Drupal 8. Compared to Drupal 7’s method of using features, it would be a major leap forward, and having now delivered a number of Drupal 8 projects, I can confirm that is certainly the case. Configuration synchronisation is now an instinctive part of my development workflow so the Configuration Split module (config split) is naturally of interest.

What problem does this solve?

Configuration synchronization includes everything that would be considered configuration, rather than content. At Hydrant, and probably for most Drupal developers, our environment will typically involve a development copy of the site on a developer's computer, a staging copy where changes made can be previewed by the client, and of course the live site. In some cases you might want to enable features for development, but not for staging or live.

Real world uses

The three examples in the talk at Drupal Unconference were ideal to describe this scenario. Two examples were modules, that you would only want to enable on the non-live site - Devel and Shield. Devel allows you to debug code, so this would only be on the development copy. Shield places basic authentication on the site for it to be viewed. This would only be on the staging site, to stop search engines crawling it.

The third example was connection details to a Solr instance, which would be different for each environment. This example can actually be answered easily, as it is possible to place the Solr variables in Drupal’s settings.local.php. This is the settings file which contains unique details per environment.

But what of the other two examples? The status of a module being active or inactive is not as simple, as this cannot be set in settings.local.php, and it also can involve additional config being added. So new configuration yaml files get created.

How does Config Split work?

This is where the Config Split module comes into use. It allows you to create folders to move environment specific configuration, such as the devel and shield settings. In short, it provides a solution for the problem, however, as the talk at Unconference showed, to achieve what would be considered a simple on or off setting is actually quite a complex and long winded process to set up and then use. If the amount of configuration and setup were reduced the module would become a more attractive option as part of a standard install. For large sites the setup could be worthwhile if you don’t have other deployment / server level options already in place.

In Summary

At Hydrant, we currently only seem to have the need for the devel module being enabled or disabled. The solution the config split module offers is currently the best out there, but as it’s effectively a single on/off checkbox in the administration, it would be really good to find a more straight forward alternative.

Talk to us

At Hydrant we are always happy to discuss your project, or technical challenge. 
Get in touch