Hello,
I have a Drupal 8 development site with an error that gets me stuck with migrating content. So I am trying to export all my setting to a fresh site. I exported them via /admin/config/development/configuration/full/export
1. I did a fresh install of Drupal 8.0.5.
2. I migrated content (via UI /upgrade) from my Drupal 6 site.
3. I am trying to import my configurations (views, content types...) via /admin/config/development/configuration/single/import
4. I get the following error:
The configuration cannot be imported because it failed validation for the following reasons:
Configuration block.block.menu depends on the Amare theme that will not be installed after import.
Configuration block.block.menu_1 depends on the garland theme that will not be installed after import.
Configuration block.block.statistics depends on the garland theme that will not be installed after import.
Configuration block.block.user depends on the bluemarine theme that will not be installed after import.
Configuration block.block.user_1 depends on the bluemarine theme that will not be installed after import.
Configuration block.block.user_2 depends on the garland theme that will not be installed after import.
Configuration block.block.user_3 depends on the garland theme that will not be installed after import.
Configuration block.block.user_4 depends on the garland theme that will not be installed after import.
I am not importing any of these items (blocks). There are blocks in my config files that use these themes, but I am not importing them as I am using Single Item Import. There are no dependencies on these blocks in the config files I am trying to import. I also uncommented $config_directories['sync'] from my settings.php
e.g. Configuration type: Content type
uuid: 929c4a4b-eb8f-4396-9739-57c185d3bd39
langcode: de
status: true
dependencies:
module:
- menu_ui
third_party_settings:
menu_ui:
available_menus:
- main
parent: 'main:'
name: 'Time-sensitive content'
type: time_sensitive_content
description: ''
help: ''
new_revision: false
preview_mode: 1
display_submitted: false
Some solutions:
Leftover config objects (for example an uninstalled theme's leftover blocks, which jam the sync system) can be deleted a few ways. More options here and here . Drupal console or drush:
drupal config:delete 'the_config_to_delete'
drush config-delete [config_name]
Comments
Comment #2
quindio CreditAttribution: quindio commentedI 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,
Comment #3
rlblais CreditAttribution: rlblais as a volunteer commentedHi! 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
Comment #4
juliencarnot CreditAttribution: juliencarnot commentedI'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.
Comment #5
Wim LeersI've seen this happen too: config validation errors when importing a single piece of config… while those validation errors are for other config!
Comment #6
Wim LeersComment #7
dawehnerWell, 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.
Comment #8
Wim LeersHow 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?
Comment #9
juliencarnot CreditAttribution: juliencarnot commented@dawehner: thanks for the tip, I have to learn more about Features. However, its project page mentions this:
I would have assumed an extra view is a fairly independent piece of configuration (given two otherwise identical environments), but I might be wrong!
Comment #11
JGReidy CreditAttribution: JGReidy commentedAfter 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
Comment #12
micheljp CreditAttribution: micheljp commented@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.
Comment #13
xeM8VfDh CreditAttribution: xeM8VfDh commented+1 having this problem on D8.3.2
Comment #14
xeM8VfDh CreditAttribution: xeM8VfDh commentedRegarding #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...
Comment #15
xeM8VfDh CreditAttribution: xeM8VfDh commented@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:
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:
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
Comment #16
dkre CreditAttribution: dkre commentedI 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.
Comment #17
robpowellI 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.
Comment #18
xeM8VfDh CreditAttribution: xeM8VfDh commented@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.
Comment #19
PatrickMichael CreditAttribution: PatrickMichael commentedI 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.
Comment #20
robpowell@xeM8Vfh yea I agree, removing bad data is good.
Comment #22
Anonymous (not verified) CreditAttribution: Anonymous commentedI met the same problem - and used the trick #15 (the rows I had to removes in config tables where all about some bootstrap blocks stuffs)
Thanks to applying #15, the single import worked well !
Comment #23
xeM8VfDh CreditAttribution: xeM8VfDh commentedIts 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.
Comment #24
HongPong CreditAttribution: HongPong at kor group commentedIs there an easy way to delete zombie blocks from themes I'm not using?
Comment #25
xeM8VfDh CreditAttribution: xeM8VfDh commented@HongPong, I've detailed exactly that in #15
Comment #26
HongPong CreditAttribution: HongPong at kor group commentedxeM8VfDh 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.
Comment #27
HongPong CreditAttribution: HongPong at kor group commentedComment #29
bwoods CreditAttribution: bwoods as a volunteer commented#15 worked for me - Thanks for posting this!
Comment #31
Jon Pollard CreditAttribution: Jon Pollard commentedThank you @xeM8VfDh I deleted these lines in phpmyadmin and now I can import my content. Whooo! :o)
Comment #32
robertoperuzzoI had a similar issue importing a single configuration by web UI:
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.
Comment #33
rwilson0429 CreditAttribution: rwilson0429 commentedThanks @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');
Comment #34
Pasquallefrom #2953378: Improve error messages on config import when modules are missing from the file system
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.
Comment #35
xeM8VfDh CreditAttribution: xeM8VfDh commented@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.
Comment #36
PanchoI 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.
Comment #37
Pasqualleyes, exactly my experience also.
Tried to fix some config quickly, hit this bug, never looked at core config import again..
Comment #38
xeM8VfDh CreditAttribution: xeM8VfDh commentedyikes @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.
Comment #39
scottsawyerI 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:
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.
Comment #40
andrimont CreditAttribution: andrimont commented@scottsawyer I have the same issue after using layout builder too.
How is it possible to manage the two options that you suggest ?
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
Comment #41
scottsawyer@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.
Comment #42
andrimont CreditAttribution: andrimont commented@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.
Comment #44
Thomas Kaisuka CreditAttribution: Thomas Kaisuka as a volunteer commentedThis 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
Comment #45
ericyellin CreditAttribution: ericyellin commented#7 Did the trick!
Comment #46
Slown CreditAttribution: Slown commented#15 Did the trick too! Thank You very much.
Comment #47
pthornhi66 CreditAttribution: pthornhi66 commented#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?
Comment #48
xeM8VfDh CreditAttribution: xeM8VfDh commented@pthornhi66, yeah, sounds like sloppy cleanup somewhere
Comment #49
imclean CreditAttribution: imclean at Digital Ink commented@pthornhi66 did you uninstall the theme or just delete it?
Comment #51
bob.hinrichs CreditAttribution: bob.hinrichs commentedI 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.
Comment #52
Rob230 CreditAttribution: Rob230 commentedI 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.
Comment #53
xeM8VfDh CreditAttribution: xeM8VfDh commentedyup @Rob230, as noted in #15, thanks for confirming/sharing
Comment #55
froboyI 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.
Comment #59
larowlanOn 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).