Single item imports are sometimes blocked by configurations that have nothing to do with the import configuration.
Sometimes a crucial configuration is blocked by something totally irrelevant like a module that exists in the source site that does not exist in the destination but which doesn't affect the configuration import at all.
Case in point: https://www.drupal.org/project/drupal/issues/3335049 💬 Configuration core.entity_view_display.paragraph.nested.default depends on the field.field.paragraph.nested.layout_builder__layout configuration that will not exist after import. Fixed
I am trying to import a view. Both the source site and the destination site are practically identical, and both have a content type that uses layout builder for the layout. The view base table is groups_field_data joined with the user table. It has nothing to do with layout builder, which we only use for nodes, yet the import is blocked because it says a configuration doesn't exist in the destination when, in fact, in this case, it actually does exist.
core.entity_view_display.paragraph.nested.default depends on the field.field.paragraph.nested.layout_builder__layout configuration that will not exist after import.
In searching for a solution to this, the only one I've found is using drush to delete the configuration from the config table. In some cases, this would make sense. In many others, it is crazy. In my case, the core.entity_view_display.paragraph.nested.default does exist, just not in the format that the configuration import expects (I reckon). Deleting this configuration will break my destination site's layout for the content type that uses layout builder. Not a good plan.
What is really needed is an override to the single item import system where you can manually enter the configuration(s) you wish the single item import to ignore.
Add a textfield in the "Advanced" section of the single item import tab. Allow users to enter, one per line, the configuration(s) that they wish the import to ignore. When the import runs, before it returns the:
Configuration --> configuration in question <-- depends on the --> parent config <-- configuration that will not exist after import
It will check the override textfield and ignore any configs listed.
Users do this, of course, at their own risk. But in the cases when you are sure all the program is doing is tying to protect you against data that doesn't exist, when you are SURE you don't need it to exist for the configuration to work (especially views!), this would relieve so much aggravation!
Closed: works as designed
10.1 ✨
Last updated
We try to keep the config consistent, ignoring dependencies will get us into a world of pain
I'll reply in the other issue later