How to exclude configuration [#2883110]

I need the ability for editors to update Webforms but since Webforms are in configuration the changes may get overridden.

My Setup

I have 3 configuration splits set up on my site: dev, staging, and prod. On dev I have UI modules, stage file proxy, and devel blacklisted. On staging I have stage file proxy blacklisted. On prod I don't have anything at the moment.

What I tried

I tried the same thing mentioned in this blog.

I installed the Config Ignore module and added the following to the settings:

webform.webform.*
~webform.webform.contact

Then I created another config split called Ignore (with no folder) and added the following to the Graylist:

webform.webform.*

If I do the following steps I still have the issue:

1. Run drush csim -y

2. Make change to webform

3. Run drush csim -y. Now the changes from step 2 are gone.

The only way to prevent this to run configuration split export after the form has been edited which won't happen because they are content editors. Any suggestions on how to handle this?

Comments

Comment #1

1 June 2017 at 17:24

albertski created an issue. See original summary.

Comment #2

geertvd CreditAttribution: geertvd at Geert van Dort commented 1 June 2017 at 17:54

The trick with config_split would just prevent the config from being exported to files. Is that still happening?
Sounds more like a config_ignore problem TBH, which version of config_ignore are you using?

Comment #3

albertski CreditAttribution: albertski at Xeno Media, Inc. commented 1 June 2017 at 18:12

I don't see config being exported. I am using config split 2.0. Could it be that Config Ignore module works with drush cim only but not drush csim?

Comment #4

geertvd CreditAttribution: geertvd at Geert van Dort commented 2 June 2017 at 09:07

Just tested this and I had the same problem when having multiple config_split entities.
I was able to fix this by adding a negative weight to my "ignored_config" config_split entity. Can you give that a try?

Comment #5

albertski CreditAttribution: albertski at Xeno Media, Inc. commented 2 June 2017 at 16:36

@geertvd Thanks for the quick response. Yes changing the weight to negative on the Ignore split, did now fix the issue.

Comment #6

albertski CreditAttribution: albertski at Xeno Media, Inc. commented 2 June 2017 at 16:41

FYI I tested two ways that work:

1. @geertvd steps from his blog post.

With this method, I can run drush scim -y and drush scex -y.

2. Using steps from this post.

With this method, I have drush csex -y ignore before running drush scim -y

Comment #7

albertski CreditAttribution: albertski at Xeno Media, Inc. commented 2 June 2017 at 16:41

Status:

Active

» Fixed

Comment #8

geertvd CreditAttribution: geertvd at Geert van Dort commented 3 June 2017 at 11:04

2. Using steps from this post.

With this method, I have drush csex -y ignore before running drush scim -y

That's an interesting approach but I prefer not to have to change my deploy flow for such things.

Also if anyone's interested the reason this issue came was because both config_ignore and config_split create config_filters, these filters are applied by there weight. So this was going on:

config_ignore filter was applied (this takes the active config for the configured config names)
config_split:ignored_config filter was applied (this takes the config which was previously exported to the database, thus overriding config_ignore).

Changing the weight to -10 changes the order so:

config_split:ignored_config filter was applied (we take the config which was previously exported to the database)
config_ignore filter was applied (we take the active config and override the config_split:ignored_config filter)

This makes me wonder whether config_ignore's config split instance should not receive a higher weight by default.

Edit: Created a follow up ticket for that last thought #2883601: Set a higher weight to the configFilter instance to avoid other configFilter instances from overriding config_ignore

Comment #9

bircher

🇨🇿

CreditAttribution: bircher as a volunteer and at Nuvole commented 6 June 2017 at 06:40

Yes the analysis of what is going on is spot on and I agree with making the weight of the config_ignore filter higher.

I prefer not to have to change my deploy flow for such things.

Well, you allow configuration changes on production, you have to account for that in one way or another.
My preferred way is to have all the config in git and add a drush csex production_changes -y to my deploy workflow. For people who don't like this step there is config_ignore.