Filter is not being loaded when using 'drush cim --source=<path>'

Created on 5 June 2017, about 7 years ago
Updated 4 January 2024, 6 months ago

First of all, I don't know if this is a config_filter or config_ignore issue, please let me know, I can move this issue to the correct place.

Problem/Motivation

The config filter is not being loaded when using the "--source=" parameter to the command "drush cim".

Steps to reproduce the issue:
- Save some config, could be via CMS/form or drush command.
- Add the config to the config_ignore list.
- Do not export the config (drush cex). This step is important to reproduce the issue.
- Run drush cim --source=<path to config/sync>

You will notice that the config management will suggest to you remove the config. This is a non expected behavior. The config should be ignored by config_ignore.

Now, try to run only drush cim, supposing that your "config/sync" path is defined on settings.php, you will notice that the config will be ignored. Expected behavior.

I think this is being caused by https://github.com/drush-ops/drush/blob/8.x/commands/core/config.drush.i...

When you use the "--source" drush param, drush loads directly the class "FileStorage", by passing the decorator defined on "config_filter.storage.sync" service.

πŸ“Œ Task
Status

Closed: outdated

Version

2.0

Component

Documentation

Created by

πŸ‡§πŸ‡·Brazil jribeiro Campinas - SΓ£o Paulo

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

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

  • πŸ‡¨πŸ‡­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.

Production build 0.69.0 2024