Ignore for language collections

Created on 15 February 2020, almost 5 years ago
Updated 18 January 2024, 10 months ago

Problem/Motivation

Such as the shown in images.
I had ignore the field.field.node.news.field_detail1, but when i run drush cim, the language translation still import.

Reproduct steps

1. Prepare a site.
2. Create a Content Type.
3. Create some fields for Content Type.
4. Translation for fields.
5. Run drush-config-export.
6. Ignore fields by config_ignore module.
7. Delete the Content Type on site (not delete the configuration files).
8. Run drush-config-import.
9. Default configurations ignored, it's right. But the translation configurations not have ignored.

Reason

From this issue comment by alexpott: https://www.drupal.org/project/drupal/issues/2262861#comment-8772867

I found has different ways for retrieve config data from Default Collection and Language Collection.

For default collection, the names from $source_data and $target_data formatted by ConfigDependencyManager, they're right.

For language collections, the names from $source_name and $target_name, they're error.

Flow Chart

Later, I sorted out their logic, as follow. Maybe my understanding inaccurate, please point out if there are error.

the detail1 DATA or detail1 NAME is need to ignore.

Default collection flow chart:

Language collection flow chart:

Solution

From my understanding, i think it's a config_ignore issue, not a core issue.
filterListAll() not have filter for $data.
So created a patch to change the function filterListAll() in IgnoreFilter class.

🐛 Bug report
Status

Fixed

Version

2.2

Component

Code

Created by

🇨🇳China Oscaner

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.

  • Status changed to Fixed 11 months ago
  • 🇨🇭Switzerland bircher 🇨🇿

    actually.. giving credit here... this issue summary is stellar.

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

Production build 0.71.5 2024