Single item import fails with validation errors from other config

I have 2 copies of the same site and I have made changes on my "d8devel" site and I did
an export. I do an import into my second site "drupal8" to copy the changes I have added

When I click on the "import all" I get similar errors:

The configuration cannot be imported because it failed validation for the following reasons:
Configuration block.block.block_19 depends on the cube theme that will not be installed after import.
Configuration block.block.block_20 depends on the cube theme that will not be installed after import.
Configuration block.block.block_21 depends on the cube theme that will not be installed after import.
Configuration block.block.block_22 depends on the cube theme that will not be installed after import.
Configuration block.block.block_23 depends on the cube theme that will not be installed after import.
Configuration block.block.block_24 depends on the cube theme that will not be installed after import.
Configuration block.block.block_25 depends on the cube theme that will not be installed after import.
Configuration block.block.block_26 depends on the cube theme that will not be installed after import.
Configuration block.block.block_38 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_39 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_40 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_41 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_42 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_43 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_44 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_45 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_46 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_47 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_48 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_49 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_50 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_51 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_52 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_53 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_54 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_55 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_56 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_57 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_58 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_59 depends on the emergency theme that will not be installed after import.
Configuration block.block.block_79 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_80 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_81 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_82 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_83 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_84 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_85 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_86 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_87 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_88 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_89 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_90 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_91 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_92 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_93 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_94 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_95 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_96 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_97 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.block_98 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.menu_1 depends on the cube theme that will not be installed after import.
Configuration block.block.search_1 depends on the emergency theme that will not be installed after import.
Configuration block.block.system depends on the garland theme that will not be installed after import.
Configuration block.block.user depends on the garland theme that will not be installed after import.
Configuration block.block.user_1 depends on the garland theme that will not be installed after import.

If anyone knows why, please let me know?

I was trying to not to do a copy of the DB but it seems that is the only way to show changes
from devel site to production.

Thanks,

Hi! I had this same issue on Drupal 8.1.7, except I am migrating from a Drupal 7 site instead of Drupal 6. I have been banging my head against a wall.

Here's my workaround: I went into the database config tables, and I deleted all the configs for blocks that were giving me problems. Then, I was able to import my view!

Background:
I spent days going through the php files in core, trying to figure out why the single import was giving me an error for blocks and themes, when I just wanted to import a view I had already created in another D8 site I'd started. My attempts to import a block were not successful either, and I wasn't able to zip up the view as a tar file and import it that way. What I did learn, however, is that an empty view or block with no fields *would* import to an empty Drupal 8 site which I had not migrated any content to. That's not very useful, but I got an idea.

The block configs that were throwing errors were all for themes that I don't have on the site (because themes, as you know, don't have a migration path to Drupal 8). I did not get errors for the Bartik or Seven blocks. So I deleted the config for those blocks which were giving me errors.

And deleting the config didn't seem to affect the blocks I have active on my Drupal 8 site. They are still there and appear to be working fine. Nonetheless, if you try this solution, please make sure it is on a copy of your site/database that could be scrapped.

Unfortunately, I still don't know why the view I want to import wasn't validating to begin with, so I consider this is just a workaround. I hope we get a real solution soon.

Best of luck,
Lauren

I'm affected by this too, with Drupal 8.2.1. As in #2, importing a view config from a dev environment which was based on a recent dump of the prod environment results in errors related to a theme I can't even find in either environment.

I've seen this happen too: config validation errors when importing a single piece of config… while those validation errors are for other config!

Well, I'd say the problem is simple. A single piece of independent configuration is really an edge case. Instead there is config gigantic configuration dependency tree. Maybe we should discourage people from using single export/imports. Its just not working nicely.

With modules like features (and some of its companions) you can extract a subtree of configuration, which would allow you to import again.

How are people then supposed to do development of new modules? I used the single import functionality extensively while developing a module, and figuring out the config schema.

Why can't the errors just be filtered down to those for the affected config?

@dawehner: thanks for the tip, I have to learn more about Features. However, its project page mentions this:

If you simply need to export and deploy simple site configuration, the D8 configuration management system should be used instead of Features.

I would have assumed an extra view is a fairly independent piece of configuration (given two otherwise identical environments), but I might be wrong!

After migrating from Drupal 6 to Drupal 8, I had blocks that depended on themes that were missing, and these prevented import of configurations. I found an 'easy' workaround. I made fake versions of the themes, enabled the themes, then disabled them. All the problem blocks went away after the disable.

Example fake theme called agony:
/themes/agony/agony.info.yml

You create the directory and the .yml file using the machine name of the theme. Inside the .yml file is this:

name: agony
description: agony - A legacy theme for Drupal 8.
type: theme
core: 8.x

@JGreidy when you say that you 'enabled' the themes do you mean, you installed them and set them as default? I tried creating an empty theme matching the machine name of the theme and this didn't work. I tried drush cim both when the theme was installed and uninstalled.

+1 having this problem on D8.3.2

Regarding #7, this is not an edge case. If dev and test are the same, then I add a new field to a content type on dev, export config to dev file system (using terminus/drush), deploy to test, then try to import the deployed config from the test file system, the system only presents the config changes related to that specific field addition. So, they are "single" imports. This has become a serious thorn to grapple with. I wonder if the fix in https://www.drupal.org/node/2825394 can be pushed to a release...

@rlblais, I'd kiss your shoes if I knew where to find you!

The past two days have been hell as I've been grappling with this problem! From my experience, this is not a drupal bug, but rather a terrible symptom of migrating old sites into D8. In my case, I migrated data from a D6 site to D8 almost a year ago. Hopefully the migration tools/process has improved drastically, because this is just another item on the long list of problems that stemmed from my migration. In hindsight, I'm advising any Drupal devs I know to rebuild on D8 instead of trying to migrate.

Basically, the problem is this. When I migrated data from my D6 site, it imported a bunch of block configurations for blocks/themes that don't exist on my new site. When my config imports were failing, my error was:

    The configuration cannot be imported because it failed validation for the following reasons:
    Configuration block.block.system depends on the garland theme that will not be installed after import.
    Configuration block.block.system_1 depends on the bluemarine theme that will not be installed after import.
    Configuration block.block.system_2 depends on the minnelli theme that will not be installed after import.
    Configuration block.block.system_3 depends on the pushbutton theme that will not be installed after import.
    Configuration block.block.system_4 depends on the clean theme that will not be installed after import.
    Configuration block.block.user depends on the garland theme that will not be installed after import.
    Configuration block.block.user_1 depends on the garland theme that will not be installed after import.
    Configuration block.block.user_2 depends on the ucbflex theme that will not be installed after import.
    Configuration block.block.user_3 depends on the bluemarine theme that will not be installed after import.
    Configuration block.block.user_4 depends on the chameleon theme that will not be installed after import.
    Configuration block.block.user_5 depends on the minnelli theme that will not be installed after import.
    Configuration block.block.user_6 depends on the pushbutton theme that will not be installed after import.
    Configuration block.block.user_7 depends on the clean theme that will not be installed after import.

None of these blocks exist on my new site. I resolved this error by logging into the mysql database for my dev site and, as @rlblais suggested, deleting all of these garbage blocks with the following command:

DELETE FROM
	config
WHERE
	name
IN (
	'block.block.system',
	'block.block.system_1',
	'block.block.system_2',
	'block.block.system_3',
	'block.block.system_4',
	'block.block.user',
	'block.block.user_1',
	'block.block.user_2',
	'block.block.user_3',
	'block.block.user_4',
	'block.block.user_5',
	'block.block.user_6',
	'block.block.user_7'
);

Then I re-exported my Dev config to the Dev file system to reflect these changes with drush cex -y. Then I deployed the changes to Test and was finally able to run the imports.

I can't say for certain until more time has passed, but the fix above appears to not only have fixed my import problem, but also to have fixed a lot of other "weirdness" I've been experiencing with my D8 environments, deployment procedure, and caching. It at least seems to me that those phantom configs for non-existent blocks were causing lots of curious behavioral quarks. I could be wrong, but this is my current interpretation as lots of the regular weirdness I've been working around (while scratching my head a bit, as they weren't blocking/breaking issues, just strange one-off behavior every now and then) seems to have vanished.

Just one example of vanishing weirdness: https://www.drupal.org/node/2877417#comment-12087220

I agree with #14's sentiments, this isn't an edge case.

I've just tried to import and config a slick carousel configset from a production site to a new site and get various block config errors from a theme which was switched out early in development. I'm not developing anything, I'm just trying to copy and paste some time consuming configurations. The production site is still on 8.2.7, the new site is 8.3.3.

I thought this was one of the ideas behind the configuration sync feature. This has been one of my favourite improvements with D8 and seemed like a good move forward. It'd be a shame to have it reduced to backup and restore.

I followed #3 & #15. I was trying to import a view and was getting error messages that it failed validation off of blocks that don't exist for a theme that doesn't exist.

Is this something we can fix? If I was going to try to summarize the problem I would say that single imports incorrectly trigger the whole config tree validation. A possible solution would be to circumvent the config val and only val for what is being import. To be clear, I don't how to do any of this just spit balling.

@robpowell, I generally agree with the argument that a full config tree validation should not be triggered by these single imports. That being said, if your database includes configurations for blocks that don't exist on your site (as mine did, due to data migration from a D6 site), that means you have bad data in your database. While not triggering a full config tree validation might allow you to get around this issue, I personally think the better solution is for you to purge the bad configs related to non-existant blocks/themes from your database. Not only will it resolve this issue for you, but it will stabilize your data. And, as I suggested in #15, it could solve a lot of weirdness that you may or may not be experiencing completely unrelated to this subject. I am still convinced that my config cleanup in #15 resolved multiple weird problems on my site.

I had a similar problem importing a view via single item import on D8.3.5. When the site was first built Adaptive theme was used, then converted to Bootstrap. The import failed due to at_core.settings still being in the config table, despite the theme, sub theme and AT modules having been uninstalled. Removing at_core.settings from the config table solved the issue.

@xeM8Vfh yea I agree, removing bad data is good.

Its not specifically related to this issue, but I just wanted to provide a heads up on more D6 to D8 migration issues I found that are similarly related to bad configs being migrated: https://www.drupal.org/node/2915879#comment-12312094

Just hoping to document these migration issues as much as possible in the hopes of helping others out who will undoubtedly run into similar issues.

Is there an easy way to delete zombie blocks from themes I'm not using?

@HongPong, I've detailed exactly that in #15

xeM8VfDh thank you I did it thru a SQL editor but there ought to be a simple option for folks, that's what I mean. appreciate the quick answer.

#15 worked for me - Thanks for posting this!

Thank you @xeM8VfDh I deleted these lines in phpmyadmin and now I can import my content. Whooo! :o)

I had a similar issue importing a single configuration by web UI:

Configuration core.entity_form_display.node.profile_originale.default depends on configuration (field.field.node.profile_originale.comment_node_profile_originale, field.field.node.profile_originale.field_email, field.field.node.profile_originale.field_fax, field.field.node.profile_originale.field_foto, field.field.node.profile_originale.field_hardware, field.field.node.profile_originale.field_homepage, field.field.node.profile_originale.field_idsocio, field.field.node.profile_originale.field_idvariaz, field.field.node.profile_originale.field_indirizzo, field.field.node.profile_originale.field_lingue_conosciute, field.field.node.profile_originale.field_localita, field.field.node.profile_originale.field_luogo_nascita, field.field.node.profile_originale.field_nazione, field.field.node.profile_originale.field_nome, field.field.node.profile_originale.field_note_amministrative, field.field.node.profile_originale.field_note_professionali, field.field.node.profile_originale.field_note_rec, field.field.node.profile_originale.field_owner, field.field.node.profile_originale.field_p_iva, field.field.node.profile_originale.field_posiz_prof, field.field.node.profile_originale.field_privacy, field.field.node.profile_originale.field_privacy_info, field.field.node.profile_originale.field_qualifica, field.field.node.profile_originale.field_qualifiche, field.field.node.profile_originale.field_regioni_province, field.field.node.profile_originale.field_sezioni_aiti, field.field.node.profile_originale.field_software, field.field.node.profile_originale.field_specializzazioni, field.field.node.profile_originale.field_telefono, field.field.node.profile_originale.field_telefono_cellulare, field.field.node.profile_originale.field_telefono_ufficio, field.field.node.profile_originale.field_tessera, field.field.node.profile_originale.field_tipo_socio, field.field.node.profile_originale.field_titoli_di_studio, field.field.node.profile_originale.field_titoli_studio, field.field.node.profile_originale.field_visibile) that will not exist after import.

Following what @xeM8VfDh said at comment #15, I delete the core.entity_form_display.node.profile_originale.default row from database

DELETE FROM config WHERE name = 'core.entity_form_display.node.profile_originale.default'

and than I was able to import my configuration.

Thanks @xeM8VfDh.

Thanks @xeM8VfDh. #15 worked for me doing a Single Item configuration import. In my case I ran the following delete statement in MYSQL:
DELETE FROM config WHERE name IN ('bootstrap_subtheme.settings');

from #2953378: Improve error messages on config import when modules are missing from the file system

importing/reverting config through the contrib Config Update Manager module is not blocked by this bug https://www.drupal.org/project/config_update

Some additional notes:
Deleting the "problematic" config should be possible with config_update module.
If the "problematic" config is from an existing but uninstalled module, then the config can be deleted with the Easy install module also.

@Pasqualle, the problems that I and a few other faced in regards to this issue were related to migrations from earlier versions of drupal. I can't speak for everyone in that camp, but can say that, in my case, the problematic configurations referenced block and modules that did not exist (were not installed) in my D8 environment. Consequently, it sounds like Easy Install wouldn't have helped me. Without testing, i can't say for sure that Configuration Update Manager (config_update) module would have resolved the issue, but maybe someone who newly discovers this issue can test those and report back. Thanks for the heads up.

I hit this DX bug several times when developing custom modules, and though it was easy to fix with the config editor, it was kind of annoying.

IMO, we should only block import for config items that introduce new validation errors. For preexisting inconsistencies in other config items only a warning should be emitted.

yes, exactly my experience also.
Tried to fix some config quickly, hit this bug, never looked at core config import again..

yikes @pasqualle. I can definitely understand your frustration, and see why one would abandon the config importer while developing modules. But, I've found it to be incredibly useful tool for managing config for an actual production site. One of the better features of D8, IMO.

I ran into this problem, I think my issue has to do with layout builder. I created several layouts in my theme, I am using those layouts in all of the configs that throw the errors.

When I export one of the configs, I see in the module: list, - theme_name, listed as a module. Well, it's not a module, it's a theme! The theme is installed, set as active / default ( for both admin and front-end ). But since the config is considering it a module, it obviously won't appear in the module list ( I guess the config importer checks when validating a config ).

I can see one of two options:

• Add a new entry in the config dependency for theme
• Deprecate allowing themes to provide layouts

I am creating an issue in Layout Builder, maybe they have thoughts on this.

EDIT: I can confirm this is also a problem when editing config via drush.

@scottsawyer I have the same issue after using layout builder too.

How is it possible to manage the two options that you suggest ?

• Add a new entry in the config dependency for theme
• Deprecate allowing themes to provide layouts

Great for creating an issue in Layout Builder. I just tart to use this Layout Builder and it looks promising.

BTW I tried to use this patch #75 here :
https://www.drupal.org/project/drupal/issues/2904550#comment-12986659

But no success…
Still

The configuration cannot be imported because it failed validation for the following reasons:
Configuration core.entity_view_display.node.article.default depends on the themag module that will not be installed after import.

@andrimont I solved the problem by creating a module and placing my layouts in there. Then I went to each entity display using a custom layout from the theme, and one by one, replacing each layout with the new one from the module. It was tedious, but it fixed the issue, I can now import config with no errors.

@scottsawyer, thank you for your answer.
Oups, so sorry… I never created any module.
Could you slightly detail the process making a custom layout from the theme ?

Update : I discovered that removing Panelizer got rid of the trouble.
As there is constant trouble with Panelizer in Drupal 8 I will only get along with Layout for now.

This worked for me;

drupal config:delete 'the_config_to_delete'
drush config-delete [config_name]

my issue was an error related to devel_node_access.settings

#7 Did the trick!

#15 Did the trick too! Thank You very much.

#15 did it for me. Thank you.

Had orphaned blocks from a deleted theme. Why were those hanging around. Sloppy clean-up from theme deletion?

@pthornhi66, yeah, sounds like sloppy cleanup somewhere

@pthornhi66 did you uninstall the theme or just delete it?

I had the same problem, there are records in the D7 site to be migrated, for themes that are unused, that have status=1, and are therefore migrated. However there are no such themes on the D8 site, and errors are thrown when you attempt certain migration tasks. There are several problems: 1) the importing of blocks that are not used on the site (disabled theme ought to have same effect as status=0 for the block, I'd say). 2) The migration tasks validating based on these "orphans" that got migrated.

I went into the D7 site and set the records for the blocks to status=0, which resolved the issue by causing them not to migrate. On D8, I also deleted the theme migration configurations, because these were migrating theme settings for switched-off themes, which caused similar validation errors.

I caused this to happen by importing a core.entity_view_display file which had a dependency on a field that didn't exist. It gave an error, but afterwards I was unable to do a single import of anything else, even unrelated things, because apparently it had still created that config in the database. The solution was to delete the problematic core.entity_view_display row from the config table in the database.

yup @Rob230, as noted in #15, thanks for confirming/sharing

I ran into this message on a module and the method above worked, but I wanted to dig a little more and figure out where the issue came from. It turned out the module that was throwing this error had it's PHP requirement bumped from 7.2 to 7.3 and this was how Drupal was telling me that I needed to update PHP—by saying that this module would be removed if I updated. So... as folks are debugging that's just one more thing to look out for.

On the basis of the comments here, this reads like a support request to me.

Drupal is rightly enforcing the integrity of your configuration, to prevent you from damaging your site further.

I think there are workarounds as seen above (e.g. making mock/stub themes, deleting the problematic items).