Update documentation to include config directory settings

Created on 11 May 2019, over 5 years ago

Updated 4 January 2024, 11 months ago

I'm wondering if someone can clarify when this module should be used. I haven't had any success using it and I wonder if I'm just misinterpreting what the purpose is.

Here is my situation:

On production, the client has full control over webforms. They can create, edit and delete them as they please. However, all of these actions cause config to be overridden/created on production. This means that whenever I deploy to production, I have to first pull the production database and export any webform config, and commit it. If I don't do that, I will wipe out the changes to webforms the client has made when I import config on production. In an ideal situation, changes to webforms would not be tracked in config at all. This is what I thought this module was for, but I've found it does nothing to prevent any of this. In fact I haven't noticed that it does anything at all.

I've configured the "Configuration entity names to ignore" field like this:

webform.*
webform.webform.*

If this is not the purpose of the module, I'll uninstall it. I've actually found this module which appears to do exactly what I want. https://www.drupal.org/project/webform_config_ignore → I'll give it a try, but I'd rather use config_ignore because theoretically I could ignore config from webform as well as other modules.

Thanks for any help.

💬 Support request

Status

Closed: outdated

Version

2.1

Component

Documentation

Created by

🇺🇸United States maskedjellybean Portland, OR

Live updates comments and jobs are added and updated live.

Incomplete comments

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment 11 months ago →
🇨🇭Switzerland bircher 🇨🇿
This issue is being closed because Config Ignore 2.x is deprecated.

The new 3,x version has been re-written from the ground up and works in a totally different way, yet it provides the same backwards compatible functionality. All the 2.x tests pass in 3.x and the 3.x codebase is easier to maintain.
Users of 2.x are strongly encouraged to upgrade to 3.x, as there is a very simple update path.

So likely this issue is no longer relevant. If you think that this issue still applies please open it again and target the new branch. All issues on the 2.x branch were closed in bulk.

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024