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.

CommentFileSizeAuthor
#21 Screenshot_1.png51.46 KBgiorgio79
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

F.E.M created an issue. See original summary.

AlexBorsody’s picture

Title: Unable to Import Views Configuration block.block.bootstrap_fem_account_menu depends on the bootstrap_mytheme theme that will not be installed after import. » Unable to Import Views Configuration block.block.bootstrap_mytheme_account_menu depends on the bootstrap_mytheme theme that will not be installed after import.
alexpott’s picture

Component: views.module » configuration system
Status: Needs work » Postponed (maintainer needs more info)
Issue tags: +Configuration system

Was 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.

AlexBorsody’s picture

Yes 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.

amedjones’s picture

Hi
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

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Wim Leers’s picture

freelock’s picture

Hi,

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

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

pameeela’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)
Issue tags: +Bug Smash Initiative

Thanks 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!

freelock’s picture

Hi,

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

giorgio79’s picture

I 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?

The configuration cannot be imported because it failed validation for the following reasons:
Configuration acquia.settings depends on the acquia extension that will not be installed after import.
Configuration block.block.acquia_prosper_system_main depends on the acquia_prosper theme that will not be installed after import.
Configuration block.block.adaptivetheme_system_main depends on the adaptivetheme theme that will not be installed after import.
Configuration block.block.adaptivetheme_system_powered_by depends on the adaptivetheme theme that will not be installed after import.
Configuration block.block.adaptivetheme_user_login depends on the adaptivetheme theme that will not be installed after import.
Configuration block.block.corolla_block_2 depends on the corolla theme that will not be installed after import.
Configuration block.block.corolla_menu_menu_submit depends on the corolla theme that will not be installed after import.
Configuration block.block.corolla_menu_secondary_menu depends on the corolla theme that will not be installed after import.
Configuration block.block.corolla_system_main depends on the corolla theme that will not be installed after import.
Configuration block.block.dovetail_system_main depends on the dovetail theme that will not be installed after import.
Configuration block.block.dovetail_system_powered_by depends on the dovetail theme that will not be installed after import.
Configuration block.block.dovetail_user_login depends on the dovetail theme that will not be installed after import.
Configuration block.block.fusion_core_system_main depends on the fusion_core theme that will not be installed after import.
Configuration block.block.garland_system_main depends on the garland theme that will not be installed after import.
Configuration block.block.garland_system_powered_by depends on the garland theme that will not be installed after import.
Configuration block.block.garland_user_login depends on the garland theme that will not be installed after import.
Configuration block.block.marvin_user_login depends on the marvin theme that will not be installed after import.
Configuration block.block.nonzero_system_main depends on the nonzero theme that will not be installed after import.
Configuration block.block.nonzero_system_powered_by depends on the nonzero theme that will not be installed after import.
Configuration block.block.nonzero_user_login depends on the nonzero theme that will not be installed after import.
Configuration block.block.pushbutton_system_powered_by depends on the pushbutton theme that will not be installed after import.
Configuration block.block.pushbutton_user_login depends on the pushbutton theme that will not be installed after import.
Configuration block.block.zen_system_main depends on the zen theme that will not be installed after import.
Configuration block.block.zen_system_powered_by depends on the zen theme that will not be installed after import.
Configuration block.block.zen_user_login depends on the zen theme that will not be installed after import.
Configuration bootstrap.settings depends on the bootstrap extension that will not be installed after import.
Configuration corolla.settings depends on the corolla extension that will not be installed after import.
Configuration zen.settings depends on the zen extension that will not be installed after import.
giorgio79’s picture

Status: Closed (cannot reproduce) » Active
giorgio79’s picture

@freelock
I found a /core/config/install/core.extension.yml, but it is empty...

$ find . -name core.extension.yml
./core/config/install/core.extension.yml
module: {}
theme: {}
profile: ''
giorgio79’s picture

FileSize
51.46 KB

PS I did find entries for these in the config MYSQL table!
config table contents sql

giorgio79’s picture

I 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

Lendude’s picture

Reading 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?

freelock’s picture

To 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`.

Version: 9.1.x-dev » 9.3.x-dev

Drupal 9.1.10 (June 4, 2021) and Drupal 9.2.10 (November 24, 2021) were the last bugfix releases of those minor version series. Drupal 9 bug reports should be targeted for the 9.3.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.