Ignore configuration storage collections

LGTM!

Thanks for this patch! I also needed to figure out how to ignore translated configuration and #78 worked great. We are using 3.0-beta2.

Re-roll since another hook_update_N() got in already. I also adjusted the patch to respect previously configured settings instead of reseting them since now the update will get executed one more time for sites that had the previous patch.

Thank you for the patch!
It works for us so far.

The patch in #91 no longer applies to 3.x-dev and it's not an easy re-roll... the split of modes with Basic, Intermediate, and Advanced complicates this.

Yes the patch here needs to be re-worked. And I would argue the approach needs to be re-thought.

But if you look at the code in 3.x-rc1 you will see that it was refactored with this issue in mind.

To achieve the same purpose (ignoring config in certain collections), I think it would be easier to integrate them with the other patterns.

You know that now you can ignore patterns with their config name and optionally separated with a : also ignore just parts of it. If you leave the partial part out then it is essentially everything, or *.

I think we could do the same for collections. I don't know what the best separator would be. Let's assume for this argument that we settled on | as the separator, then imagine:
lang.de|config_name:some.part and if you omit the language part it is implied just * and if you want your config to be ignore just in the default collection you would write |config_name

So you could also ignore lang.*|* and ~lang.en|* which would mean ignore all languages except for English. This would just make it more difficult to then also ignore something but not everything in the english translations. But to be honest.. I think that is an edge case that we could be ok with. I don't think we need ~~ to exclude excludes... But we could in a different issue.

Made a quick patch for the RC version (without tests for now).

Hi
Yes the patch from #95 is precisely what I had in mind.

Tests should be pretty straightforward to write, one can just add more test cases to where all the other things are. They already have languages set up for this exact reason.

#95 Worked for me for 3.1 release.
Upgrading from 2.4 and after settings update it was pretty straightforward,

Thanks a lot!

Also confirming that #95 worked for me for 3.1 release.

As a note for others - you'll need to update your config_ignore.settings after applying the patch from #95.

Examples

• * (will ignore everything)
• ~webform.webform.contact (will force import for this configuration, even if ignored by a wildcard)
• user.mail:register_no_approval_required.body (will ignore the body of the no approval required email setting, but will not ignore other user.mail configuration.)
• language.*|* (will ignore all language collections)
• language.fr|* (will ignore all fr language collection)
• language.fr|field.field.* (will ignore all fr field translations)
• ~language.fr|field.field.media.file.field_media_file (will force import for certain field translation)

Changing the status of this issue to "Reviewed & tested by the community" per the Issue Status Field → documentation.

Before this can be committed someone needs to add a couple of test cases here:

https://git.drupalcode.org/project/config_ignore/-/blob/8.x-3.x/tests/sr...

It can be a simple configuration with a couple of the language examples.

Added tests to the patch

Hide all outdated patches and made a PR

The latest patch worked for me.

The latest patch worked for me too!

this works for me

@gmustapha not sure why you readded patch #79, but this is a patch for 2.x but we need a patch for 3.x already.
If you need a patch for the old version you can just use the older patch (#79).

I have a use case that the patches in #95 and #101 don't resolve.

For example, I'd like to ignore the site name in language collections.

I expected something like this to work:

- language.*|system.site:name (doesn't work)

FYI:

- language.*|system.site (works, but it ignores too much)
- language.*|system.site.* (doesn't work, though the help text added in #95 suggests it should)

Thank you everyone for contributing to this long standing issue!
I was never really happy with how it worked in 2.x, but I am very happy to see that the architecture of 3.x makes this much simpler and yet much more flexible to configure.

I added and changed some stuff based on the great work from patch in #101 and I added a test for #108 which passes so, if that doesn't work then we need to find a better test and fix it as a bug in the next release.

bircher → closed merge request !19

Automatically closed - issue fixed for 2 weeks with no activity.