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:
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.
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.
TBD.
TBD.
TBD.
Comments
Comment #2
cilefen commentedComment #4
moshe weitzman commentedMy 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.
Comment #5
geerlingguy commented@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:
drush cex -yto export anddrush cim -yto import.(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.
Comment #6
scott_euser commentedIn 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.
Comment #7
marcaddeo commented@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.
Comment #8
geerlingguy commented@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.
Comment #9
Grayside commentedDoesn'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.
Comment #10
hanoiiI 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 (https://www.drupal.org/docs/8/api/configuration-api/configuration-overri... - Providing overrides from modules).
Comment #11
bircherhi 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.
Comment #12
hanoiiHi @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.
Comment #13
bircher@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..
Comment #16
bircherAdding the CMI 2.0 candidate tag
Comment #18
mpotter commentedThis is being implemented by #2991683: Move configuration transformation API in \Drupal\Core\Config namespace and #3028179: Config Environment module (original issue). A new branch of Config Split will be created and remain in contrib to use the new ConfigTransform API to handle the use-cases not covered by the Config Environment module. For #9, see #2501901: Allow configuring the environment via an environment variable.
These issues should cover items 1,2,3 from #5. For item 4, perhaps there should be a new issue to see if that can be implemented using the ConfigTransform API.
Please post any implementation-specific comments to the above issues and we can keep this issue open for other general comments on this topic not covered by the above initiatives.