0

I am trying to use config_split so we can ignore/disable some modules/configurations on our dev environments, and we don't want them to carry over to our production environments.

I think I am setting things up wrong, as whenever I make config changes on my dev and push things up to production and import, it's overwriting the settings on production for modules we are ignoring in config_split. (For example, if I make a views change locally, and export the config). When I import that config change into prod, it also disables the modules (and removes their settings we provided) we have on production that aren't on the dev environments.

For example, we have Drupal Shield and Drupal Password Policy set on production, but we don't want to set it on development. We have the 'shield' and 'password_policy' module selected in the 'dev' configuration split we made, as well as the common 'devel' and 'admin_toolbar_extras' etc modules.

Now because we have them ignored, it ignores our settings in dev environments (if its disabled on our local dev, it stays disabled after import, visa versa), but once we push up to production and import config, it tries to disable shield and password_policy on production, and change all of our custom settings we have set for it.

Do we need to create a special 'prod' with the modules that only apply to production to prevent that from happening?

A little stuck on using it, and can't make heads or tails of the documentation.

Improve this question
1
  • There is a extra drush command you need to add to your deployments. It's documented in the module, but basically its a per-environment config import.
    – Ryan Hartman
    Commented Jul 23, 2021 at 15:02

1 Answer 1

Reset to default
1

For example, we have Drupal Shield and Drupal Password Policy set on production, but we don't want to set it on development. We have the 'shield' and 'password_policy' module selected in the 'dev' configuration split we made

This is your problem. This will enable the modules on Dev, not on PROD. You need to create a separate split for production, and add those modules. Then you will need to push your configuration. You will likely also need to manually enable the modules on PROD after pushing that split. Then it will not be overwritten on your next push.

I wrote this, it may help you out some: https://www.morpht.com/blog/drupal-8-configuration-part-4-extending-api-contributed-modules

Improve this answer
3
  • So the way our config works now, it's ignoring the modules on dev (whether they are installed or not), but disabling them on production. It was my understanding when a module is ignored in a config, it reads core.extension and removes the 1 flag on import. If it's not in the split, it uses whatever is in active default config which is to have the module enabled. Is that not actually how it works?
    – Ex0r
    Commented Jul 24, 2021 at 13:12
  • If you put a blacklist on a module enabled on DEV, it will only be enabled on DEV.
    – Jaypan
    Commented Jul 24, 2021 at 16:06
  • That makes sense. Thank you. I will get our prod config setup.
    – Ex0r
    Commented Jul 25, 2021 at 16:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.