tl;dr: Something like Configuration Split... but in core.


Drupal 8's core configuration management allows me to export all configuration (or single files) and import all configuration (or single files), which is great. But one use case I run into quite often relates to how I develop Drupal sites.

I often have at least a local development environment in addition to production.

And sometimes I have a local, dev, stage, and production environment (4 total) that I manage.

The main problem I've encountered relates to my ability to have certain modules enabled in production, and other ones in other environments. As a simple use case:

  • Production uses Google Analytics
  • Local disables Google Analytics
  • Local enables Devel and XHProf for debugging, and I configure them specially for local

With Core CMI alone and a full export of configuration, it's impossible for me to export all my local configuration then deploy it to production, without manually deleting some files and editing a file like core.extension.yml to remove those local-development-only modules.

In the contrib space, the best solution to this problem that still allows a full, not --partial, configuration export/import, is to install and use the Configuration Split module.

As a user story:

As a Drupal developer, I want to have certain modules and related configuration differ between multiple instances of a single Drupal site, so I don't have to have all the exact same configuration in all my environments.

Proposed resolution

Have something like Configuration Split as part of core CMI.

Basically, give me the ability to have a 'split' of my configuration for each environment, and in each split, give me the ability to manage a list of installed modules and configuration that should only be used in that environment.

So when I export configuration locally, it preserves the configuration for Devel and XHProf, and also indicates I have the Google Analytics module disabled. But when I deploy the configuration to production, it knows that Google Analytics needs to be enabled but doesn't care about Devel and XHProf.

Remaining tasks

  • Figure out the best solution to this problem.
  • Do some coding magic.
  • Make this problem solvable in core.

User interface changes


API changes


Data model changes



geerlingguy created an issue. See original summary.

cilefen’s picture

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

moshe weitzman’s picture

My first thought is that Contrib has not really solved this robustly yet. I think we should keep experimenting in Contrib and then move to core? Note that Drush and config_split are actively working on this so it shouldn't be too much longer until we have a better solution.

geerlingguy’s picture

@moshe - Indeed, this definitely needs to simmer a bit longer before anything is fully pulled into core. It's taken over a year just to get to a point where three or four main CM techniques are being adopted; I remember last time I looked outside what I was familiar with, there were probably 12 or so different tools and techniques people were using to hack around this problem!

To add to the mix, I identified the four features I really want out of CM:

  1. As easy (or almost as easy) as plain old drush cex -y to export and drush cim -y to import.
  2. Allows a full config export/import (so you don't have to use update hooks to do things like enable modules, delete fields, etc.).
  3. Allows environment-specific configuration and modules (so you don't have to have some sort of build system to tweak things post-config-import—Drupal should manage its own config).
  4. Allows certain configurations to be ignored/not overwritten on production (so content admins could, for example, manage Webforms or Contact Forms on prod, but not have to have a developer pull the database back and re-export config just to account for a new form).

(From Adding Configuration Split to a Drupal site using BLT and Acquia Cloud.)

Config Split hits 1, 2, and 3, but #4 is still a gaping hole, and a major turnoff to a lot of Drupal traditionalists who aren't used to giving up control over some things in Prod.

scott_euser’s picture

In the case of 4) we have been using drush cmi tools from PreviousNext to allow webform, contact forms, etc to be considered as client content and not part of the export / import.

The same config-ignore has helped us solve 1, 2, and 3 combined with - -skip-modules on export; however it doesn't allow a development setup to be shared between multiple local copies (without repeating steps) like config split does.

marcaddeo’s picture

@geerlingguy, the author of this article seems to have a solution for your 4th point of allowing administrators to use webforms.

They've created an "Excluded" split that ignores webform configuration and gets exported on production deploy, and then the configuration is reimported to ensure the webform configuration is not blown away. At least that's my understanding after reading the article, haven't actually tried that setup.

geerlingguy’s picture

@marcaddeo - It seems another option is to use Config Ignore, which may or may not be a cleaner approach than creating an 'exclude' config split and managing it in the deploy process.

Grayside’s picture

Doesn't this imply a first step of making core somehow environment-aware? Configuration isn't the only thing this applies to, for example, Environment Indicator.

hanoii’s picture

I am also very the use case of 4th, that can be useful for many, many things. Email template configurations, web services switches (live/test), etc.

I am familiar with both config_split and config_ignore but those works on the whole settings file, not specific entries. I wonder if that's currently covered by any alternative.

I was thinking of doing an additional contrib as something like config_content.. I haven't think this through properly but the rough of it would be to map a specific config entry (not file, a single config element) to some content so that's dependent on the content of each environment. Modules have the option to override config ( - Providing overrides from modules).

bircher’s picture

hi hanoii, in fact I worked on a proof of concept for such a module a while ago. But we didn't end up needing anything more than setting.php and were fine without a UI for it. when using the override system in modules you have to be careful to make sure it will work also on multilingual sites.
Also to make a good and useful UI for it will be a challenge; especially if you want something generic and at the same time more than essentially pasting what you would put in setting.php in a text area. For roles I made Config Role Split and I am not happy yet with the ui. but you would be interested we could collaborate and make a module together for individual overrides, pm me in case.

hanoii’s picture

Hi @bircher, I am interested although time-wise not great.. will PM. I wonder though as you probably know this answer super quickly..., isn't is possible to simply ignore one config key (as opposed to the whole file) with config_split or config_filter.

Like say I want to ignore


on import from user.mail.yml but not the others, woudn't that help considerably for this use case?

We could have a field to type these manually con config_split.

bircher’s picture

@hanoii, for ignoring individual configuration keys please look at and review #2896753: Add possibility to ignore only certain keys and not the whole coniguration entity..

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.