Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.This pertains to 8.x-2.x branch with config_filter.
Motivation:
This module is often times used in combination with a configuration strategy where most config is managed via code, however, some config changes need to be made on the live site. With large platform deployments (100s - 1000s of sites) it is not possible to know what config is being generated (properly) on each individual site. Stronger use of wildcards with config ignore would help decrease the potential for error.
Problem:
We want to allow for site owners to create custom contact forms on the live site that don't get blown away on deployment. However, when creating a custom contact form a whole host of config files will be created that would be difficult to account for with the current (*) strategy.
For instance, when creating a contact form called "custom_contact_form" with one field you can get config that would need to be ignored that looks like this:
core.entity_form_display.contact_message.custom_contact_form.default
core.entity_view_display.contact_message.custom_contact_form.default
field.field.contact_message.custom_contact_form.field_custom_contact_form_test
field.storage.contact_message.field_custom_contact_form_test
contact.form.custom_contact_form
Using the existing * logic you would have to:
core.entity_form_display.contact_message.custom_contact_form*
ore.entity_view_display.contact_message.custom_contact_form*
field.field.contact_message.custom_contact_form*
field.storage.contact_message.field_custom_contact_form*
contact.form.custom_contact_form
Unless you catch all of these patterns, a config could be missed and accidentally deleted/changed.
Solution:
Add better wildcard handling which allows for more advanced filtering. I created a patch which uses the php function fnmatch. With this you can create one wildcard which states:
*custom_contact_form*
Anything the site owner prepends with "custom_contact_form" will automatically get ignored. (like custom_contact_form1, custom_contact_form2).
As an added bonus there are additional wildcards which are available to use.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | more_advanced_wildcards-2863446-10.patch | 4.84 KB | tlyngej |
| |||
| #8 | more_advanced_wildcards-2863446-8.patch | 2.8 KB | tlyngej |
| |||
| #4 | more_advanced_wildcards-2863446-2.patch | 2.83 KB | arknoll |
Comments
Comment #2
arknoll CreditAttribution: arknoll commentedComment #3
arknoll CreditAttribution: arknoll commentedComment #4
arknoll CreditAttribution: arknoll commentedComment #5
tlyngej CreditAttribution: tlyngej at Annertech commentedHi @arknoll.
First of all, thanks for a very nice issue description. A text book example. Kudos for that.
Second, I've never seen the
fnmatchfunction before. Not that I'm aware of anyway. What a lovely function. And using it seems completely backward compatible.I'll test it later and get it committed if all goes well.
Comment #6
tlyngej CreditAttribution: tlyngej at Annertech commentedRunning tests
Comment #8
tlyngej CreditAttribution: tlyngej at Annertech commentedPatch didn't apply, for what ever reason.
Trying a re-roll.
Comment #9
arknoll CreditAttribution: arknoll commentedThe test is running against the 1.x branch. The 2.x branch needs to be promoted in order to get testing working.
nvmd. Looks like it applies on 1.x as well.
Comment #10
tlyngej CreditAttribution: tlyngej at Annertech commentedBah, I didn't realize that the patch was for 2.x, despite the bold text yelling at me at the very top of the issue description.
Anywho, I'll need it for 1.x anyway.
So, here is one with a test as well, for 1.x and I'll get the 2.x in after that.
Comment #12
tlyngej CreditAttribution: tlyngej at Annertech commentedComment #14
lindsay.wils CreditAttribution: lindsay.wils commented@arknoll Have you successfully got this module working to have contact forms be created on a live server and not be overwritten on a push that runs drush cim? I cannot get this happening. Not sure if it is my setup, but even with the wildcards in place, any changes on the server are being removed when i push, the ignore list seems to not be in effect.
// Ignore all forms
contact.form*
// Ignore all fields and display settings
*contact_message*
Drupal version 8.2.6
Drush 8.1.11 on local, 8.1.3 on server.
Hosting Pantheon
If a new field or form is added on the live site, the related config does not exist when a drush cim is called, therefore deleting any changes. Should this module only work for ignoring config files that already exist? Or should it also ignore any deletions that do not exist that mach the ignore strings?
Example.
- Form is created on server called New Form
- A push is made and drush cim is run
- contact.form.new_form.yml does not exist
- normal process is to remove New Form from the database as there is no config file for it
- If a matching ignore string exists, should this deletion be ignored, or would it only ignore updates to the config when the yml already exists?
Just trying to work out if the issue is with my setup/drush version or something, or if I am just not using the module as its meant to work.
Any help much appreciated. Thanks.
Comment #15
tlyngej CreditAttribution: tlyngej at Annertech commentedHi @lindsaywilson23.
First of all, what version of Config Ignore are you using?
Version 1 only supports updated config, config marked with create, delete or rename will still get run.
If you are using version 2 you'll need Drush version 8.1.10 or above which does not seem to be the case on the server.
Comment #16
lindsay.wils CreditAttribution: lindsay.wils commentedThanks for the response. I am using version 2 on config_ignore. But yes, seems it could be a drush issue, ill look into upgrading this then will update you with the results. thanks for pointing that out!