Tried with multiple views many times
Configuration block.block.bootstrap_mytheme_account_menu depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_branding depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_breadcrumbs depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_content depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_footer depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_help depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_local_actions depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_local_tasks depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_login depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_main_menu depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_messages depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_page_title depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_powered depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_search depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_tools depends on the bootstrap_mytheme theme that will not be installed after import.
Comment | File | Size | Author |
---|---|---|---|
#21 | Screenshot_1.png | 51.46 KB | giorgio79 |
Comments
Comment #2
AlexBorsody CreditAttribution: AlexBorsody commentedComment #3
alexpottWas the bootstrap_mytheme installed on the target site? If it is not then this is the expected behaviour. How was the theme uninstalled - when it was uninstalled it should have removed the blocks.
Comment #4
AlexBorsody CreditAttribution: AlexBorsody commentedYes the them is on both sites it is the same site no change. Was just two different time stamps a few hours later, I made some changes to a view, then wanted to import it into the same site on the test server, the site is identical except for a view. And this happens with every attempted import like this. It's hosted on Pantheon.
Comment #5
amedjones CreditAttribution: amedjones as a volunteer commentedHi
My workaround for the above is to simply export to the tar.gz then extract it and copy the view.xx.yml files or any other yml config file you need. Once complete, compress them to .tar format and simply import into your server
Comment #7
Wim LeersComment #8
freelockHi,
I'm running into something like this on a few different sites. In my case, I think the configurations blocking a config import are entirely extraneous, but I'm not completely sure of the cause.
What we're getting are about 20 messages along the lines of:
Configuration block.block.demo_bootstrap_user_9 depends
on the demo_bootstrap theme that will not be installed
after import.
Configuration block.block.menu depends on the class="placeholder">childrens theme that will not be installed after import.
Configuration block.block.menu_1 depends on the class="placeholder">childrens theme that will not be installed after import.
What I'm seeing with all of these messages is that the referenced themes do not exist. They might have existed at one point -- developers trying out different themes, or starting with a theme on one site and then changing it to a new name -- one thing or another, but the key issue is that the theme name is old/stale. And these configurations do seem to re-appear for some reason.
Some of the configurations have the theme name in the name of the configuration. Others have a "theme: " entry at the top level of the yaml as well as listed as a dependencies.theme value. So far deleting all these configurations and importing the config seems to clean these up -- but we have had them somehow re-appear a couple times...
One thing I notice: aside from an actual config for the missing theme, the config-import is complaining about two kinds of blocks specifically: block.block.menu*.yml, block.block.user*.yml. Neither of these are in my active theme! (Not sure if this is because we have them hidden, or because this is some legacy config that is no longer used).
Theories:
- Block configuration migrated from D6/D7 (some of the theme names I've deleted only existed on the original D6 site)
- Change to name of config that controls block placement, and config not properly deleted during a core update
- Block configs not properly removed when theme is uninstalled
Comment #16
pameeela CreditAttribution: pameeela commentedThanks for reporting this issue. We rely on issue reports like this one to resolve bugs and improve Drupal core.
As part of the Bug Smash Initiative, we are triaging issues that are marked "Postponed (maintainer needs more info)".
Since there were no specific steps to reproduce the issue provided since the issue was postponed, I'm marking the issue "Closed (cannot reproduce)". If anyone can provide complete steps to reproduce the issue (starting from "Install Drupal core"), document those steps in the issue summary and set the issue status back to "Active".
Thanks!
Comment #17
freelockHi,
We've hit this on a bunch of sites, but I'm not sure it's worth fixing, so much as documenting how to resolve.
I have not spent time to build a test case to reproduce, but I'm pretty sure the steps would be along these lines:
1. Install a Drupal 7 site and a contributed theme
2. Place some blocks on that theme, and then switch back to a different theme without uninstalling the first contributed theme.
3. Upgrade the site to Drupal 8.
4. Create another copy of the Drupal 8 site.
5. Make some config changes and export the config.
6. Move the exported config to the other site copy and attempt to import.
This is where you hit the bug -- that there are config entities in the system for blocks placed in a theme that does not exist -- but you don't hit this bug until you attempt to import a configuration (e.g. with `drush cim`) with some changes. At that point something finally validates the configuration being imported, and these legacy items block the configuration from getting imported at all.
The workaround is easy -- delete all the configuration files that have the missing field as part of the name, and then you can import.
Cheers,
John
Comment #18
giorgio79 CreditAttribution: giorgio79 commentedI am facing the same issue. Where do you delete the configuraiton files for these blocks? I grepped my drupal folder, but no luck. I noticed d8 upgrade is database driven, so maybe somewhere in there?
Comment #19
giorgio79 CreditAttribution: giorgio79 commentedComment #20
giorgio79 CreditAttribution: giorgio79 commented@freelock
I found a /core/config/install/core.extension.yml, but it is empty...
Comment #21
giorgio79 CreditAttribution: giorgio79 commentedPS I did find entries for these in the config MYSQL table!
Comment #22
giorgio79 CreditAttribution: giorgio79 commentedI was able to delete these config items with
drush config-delete ....
thanks to #2764325: Configuration objects (system.menu.devel) provided by devel already exist in active configuration
Comment #23
LendudeReading the comments, this reads as if the configuration system is doing what it should. You have invalid config and it's being blocked.
So getting into this state (just from reading the comments), only happens when config is being generated by something like a migration. So should this be a bug for the migration system, that it should validate the generated config? Sounds like a dependency nightmare to me, but ¯\_(ツ)_/¯
Or can we close this as working as designed? The config system seems to be doing its job.
No idea, but is there some way to resolve/move this issue forward?
Comment #24
freelockTo delete configurations, the process I use involves drush -- and you need to know where your configuration sync directory is. That is set in the settings.php at install time to a directory in sites/default/files -- which is a bad idea, one of the first things you should do is change this to some directory you can commit. In new sites we typically put it right next to "web", outside the document root.
Then, when you use `drush config:export` it will export all the configuration to this directory, where you can delete the individual files associated with the non-existent theme, and then finally, you can re-import the configuration with `drush config:import`.