Needs work
Project:
Config Ignore
Version:
8.x-3.x-dev
Component:
Documentation
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
26 Feb 2026 at 14:57 UTC
Updated:
24 Apr 2026 at 13:41 UTC
Jump to comment: Most recent
Comments
Comment #2
mxr576Okay, one more, in which circumstances somebody would ignore export of a deleted configuration in active configuration?
For example, when I uninstall my module, I would like to get rid of the configs provided by the module, but this could prevent them.
Comment #5
nickolajImproved the advanced mode form descriptions to clarify what each field (Create/Update/Delete under Import/Export) does. Added fieldset-level descriptions for Import and Export, renamed field titles from generic "Create"/"Update"/"Delete" to "Ignore create on import" etc., and rewrote all field descriptions to clearly explain the behavior.
Comment #6
mxr576Better descriptions definitely helps, and maybe examples would be useful as well.
Meanwhile I think I solved the riddle, both configs are useful for ignoring dynamically created config entities, such as blocks. So users can create blocks without being them exported and can remove blocks without being the removal exported (which is still an interesting concept for me, because I cannot imagine that someone would need this either in Production or in local dev).
Comment #7
bircherTo some degree the import/export exists for symmetry.
Most people seem to only use the simple settings and then the patterns are just ignored in all cases. But sometimes this is not ideal, so the advanced mode allows for a lot of nuance, and of course it allows you to configure things that may not really make any sense.
The distinction between create and delete allows you to for example to not delete webforms created on prod only but add new ones with a config sync.
And as comment on the MR, if someone finds the updated descriptions more useful or if someone has other/more suggestions I am happy to accept them. We should just make sure that the from is still usable, so maybe we can also update the readme a bit.
Long term I would like to also have a nice documentation on drupal.org but that is for another issue.
Comment #8
mxr576I think the MR with the improved description would already help, as I said, maybe with one example in the description could make them even more insightful.
Comment #9
bircherI merged the current improvements, but I am leaving the issue open for a moment in case we want to further improve it or add to the readme too.