The service "plugin.manager.bootstrap_layouts" has a dependency on a non-existent service

This isn't due to the base theme.

You need to update the bootstrap_layouts module to the 8.x-5.x version as indicated on its project page.

Also, see #2867535: Bootstrap Layouts 8.x-4.1 incompatible with Drupal 8.3.0

The steps laid out in #2867535: Bootstrap Layouts 8.x-4.1 incompatible with Drupal 8.3.0 is the only way you can get the new version of bootstrap_layouts to work with core 8.3.0+

This is not yet fixed. Maybe we should close this as duplicated.

@mfernea, this isn't really related to that issue at all and it's not really a bug.

This is about upgrading to 8.3.0 and the very specific/manual steps required to upgrade to 8.3.0 which are laid out in #2867535: Bootstrap Layouts 8.x-4.1 incompatible with Drupal 8.3.0.

I am also stuck in this loop, I have tried the steps noted above but I get an error with Drush so I can not update the Database to switch the layout discovery plugin.

The website encountered an unexpected error. Please try again later.
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: The service "plugin.manager.bootstrap_layouts" has a dependency on a non-existent service "plugin.manager.core.layout". in Symfony\Component\DependencyInjection\Compiler\CheckExceptionOnInvalidReferenceBehaviorPass->processReferences() (line 58 of /var/www/drupal/vendor/symfony/dependency-injection/Compiler/CheckExceptionOnInvalidReferenceBehaviorPass.php).
Symfony\Component\DependencyInjection\Compiler\CheckExceptionOnInvalidReferenceBehaviorPass->processReferences(Array) (Line: 42)
Symfony\Component\DependencyInjection\Compiler\CheckExceptionOnInvalidReferenceBehaviorPass->processDefinition(Object) (Line: 36)
Symfony\Component\DependencyInjection\Compiler\CheckExceptionOnInvalidReferenceBehaviorPass->process(Object) (Line: 104)
Symfony\Component\DependencyInjection\Compiler\Compiler->compile(Object) (Line: 590)
Symfony\Component\DependencyInjection\ContainerBuilder->compile() (Line: 1284)
Drupal\Core\DrupalKernel->compileContainer() (Line: 873)
Drupal\Core\DrupalKernel->initializeContainer() (Line: 40)
Drupal\Core\Update\UpdateKernel->initializeContainer() (Line: 465)
Drupal\Core\DrupalKernel->boot() (Line: 62)
Drupal\Core\Update\UpdateKernel->handle(Object) (Line: 28)

I am running the latest versions of everything its just when I run the update.

drush updatedb -y && drush cr

I am thinking this may need to be some custom code to force it to make the switch in the database. I am playing with this as we speak so if any suggestions or pointer would be appricated.

I will post back with my findings..

I think I know the problem will provide feedback tomorrow.

@markcarver there is an issue with your code. Had the same problem with DS, alexpott fixed it.
See http://cgit.drupalcode.org/ds/commit/?h=8.x-3.x&id=d2b9dfe81d5393ed8fd6d...

Problem is that update.php triggers theme_registry_alter which tries to load the plugin manager that doens't exist yet (before upgrading)

Here's a patch.

One thing I'm wondering is how come there is not an update like

/**
 * Makes sure Layout Discovery is enabled on update, as 8003 could have failed to do so.
 */
function ds_update_8004() {
  if (!\Drupal::moduleHandler()->moduleExists('layout_discovery')) {
    \Drupal::service('module_installer')->install(['layout_discovery'], FALSE);
  }
}

To ensure that layout_discovery is installed - so moving from previous versions of bootstrap_layouts is as seamless as possible.

+++ b/bootstrap_layouts.module
@@ -15,6 +15,11 @@ use Drupal\Core\Template\Attribute;
+  // updating from 8.2.x to 8.3.x. If that is the case return an empty array.

Why is this returning an array from an alter hook? The parameter is passed by reference, no? Shouldn't it just simply return?

One thing I'm wondering is how come there is not an update

That fails when layout_plugin is installed: http://cgit.drupalcode.org/drupal/tree/core/modules/layout_discovery/lay...

Uninstalling layout_plugin also tends to be a manual process because of how other contrib projects require it as a dependency.

Depending on how one's site is configured and what tools are used, upgrading is inherently difficult and does not seem to be able to be automated via an update hook, especially in a 3rd tier project like this one (i.e. layout_discovery > ds > bootstrap_layouts).

The return array was a simple copy&paste error.

I tried the patch but it does not work for me :

Emplacement https://dev.site.com/admin/structure/types/manage/article/display?_wrapp...

Référent https://dev.site.com/admin/structure/types/manage/article/display

Message RuntimeException: The subform and parent form must contain the #parents property, which must be an array. Try calling this method from a #process callback instead. in Drupal\Core\Form\SubformState->getParents() (line 76 of /home/dev.site.com/public_html/web/core/lib/Drupal/Core/Form/SubformState.php).

Importance Erreur

@alexpott, I was about to commit the above patch, but when reading the issue title, it doesn't match this issue.

The OP indicates that the issue is with http://cgit.drupalcode.org/bootstrap_layouts/tree/bootstrap_layouts.serv... where it's attempting to inject plugin.manager.core.layout during the update process.

The theme registry stuff is rather superfluous in this case or, at the very least, could be considered as a separate issue.

I've left it in for now though, because I'm not entirely sure that it's unrelated.

---

@zenimagine, that is an entirely separate issue (#2868254: RuntimeException : The subform and parent form must contain the #parents property, which must be an array.) and not even related to this one.

"The theme registry stuff is rather superfluous in this case or, at the very least, could be considered as a separate issue."

It is not, running update.php triggers the maintenance theme which triggers the alter. Trust us (me and alex), you need that fix.

@markcarver this is why I was asking about why you are not ensuring that the module is installed? Ie something like

function ds_update_8004() {
  if (!\Drupal::moduleHandler()->moduleExists('layout_discovery')) {
    \Drupal::service('module_installer')->install(['layout_discovery'], FALSE);
  }
}

Because atm your code is using the service before you've ensured that.

tried the patch #19 and added alexpotts update like this..

function bootstrap_layouts_update_8403() {
  if (!\Drupal::moduleHandler()->moduleExists('layout_discovery')) {
    \Drupal::service('module_installer')->install(['layout_discovery'], FALSE);
  }
}

But its failing before this is run with the error.

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: The service "plugin.manager.bootstrap_layouts" has a dependency on a non-existent service "plugin.manager.core.layout". in Symfony\Component\DependencyInjection\Compiler\CheckExceptionOnInvalidReferenceBehaviorPass->processReferences() (line 58 of /var/www/drupal/vendor/symfony/dependency-injection/Compiler/CheckExceptionOnInvalidReferenceBehaviorPass.php).

As this error is breaking drush before the update in the installer I am left unable to run the update for the plugin manager to do the check.

Please read the thread carefully, you also need #17: https://www.drupal.org/files/issues/2872751-17.patch

@markcarver can you please fix this... I get questions every day in IRC because of this.

@markcarver this is why I was asking about why you are not ensuring that the module is installed? Ie something like

I already explained this in #16.

---

@markcarver can you please fix this... I get questions every day in IRC because of this.

I'm not entirely sure what should be "fixed" at the moment.

The following "error" has absolutely nothing to do with the theme registry alter or database updates:

The service "plugin.manager.bootstrap_layouts" has a dependency on a non-existent service "plugin.manager.core.layout".

This error is a result of services being rebuilt. This can occur during an update, yes, but is not directly related to it as I explained above and in #19.

Obviously, the prior patches and solutions provided have not "fixed" this error in any way as evidence by #22.

---

That being said, I'm still not convinced there is actually anything wrong here. Rather that some individuals simply do not understand how services/dependencies work in 8.x.

As I have stated many times before (in #2867535: Bootstrap Layouts 8.x-4.1 incompatible with Drupal 8.3.0), this is a rather complex "manual update" due to the contrib -> core API changes.

The exact "upgrade steps" greatly vary depending on the site build and tools used.

This error may be generated simply due to a missing and necessary "upgrade step".

Personally, I have not seen this error, but I suspect that is because I ensure the DB/config/installed modules are properly configured prior to running the site or any CLI commands that may fully bootstrap the site prior to the "upgrade".

There is a problem... I'll try to explain the scenario.

1) You're on drupal 8.2 with old ds and old bootstrap
2) You want to upgrade, so you do a composer update of drupal core, ds, bootstrap, ... (all at once)
3) You run update.php

==> BOOM

Why?

When accessing update.php, the maintenance theme gets loaded which trigger the theme registry which tries to run the following line
"$layouts = \Drupal::service('plugin.manager.core.layout')->getDefinitions();"

At this point nu updates have been fired yet so the new core layout module is not yet enabled, because the theme alter runs BEFORE the updates have a chance to install the core module.

If you don't believe me, recreate the above scenario...

Finally, yep I tried with the patch on #17 as well and got to the error.

The service "plugin.manager.bootstrap_layouts" has a dependency on a
non-existent service "plugin.manager.core.layout"

As the sites stuck with the new dependency on bootstrap layouts it breaks Drush so to get out of it I removed the boostrap_layouts out of the code base, then ran.

$ drush pmu layout_plugin -y
$ drush en layout_discovery -y

(Copied back boostrap_layouts)

$ drush updb

This restored the site.

# 26 worked for me.
Thanks!

Ditto. #26 worked for me, too. The key was removing bootstrap_layouts from the codebase first.

Also #26 worked for me! Thanks a lot, I was very worried as my site was unusable!!

I still don't believe what @aspilicious and @alexpott have suggested are the actual root causes for this very specific error (as evident by #22 and #26).

Personally, I think this is simply a deeper byproduct of the radical contrib -> core API changes that occured and just requires a little extra manual TLC (especially for a 3rd tier module like this one).

Regardless, I have gone ahead and committed their suggestions in hopes that it will at least help (in any small margin) to eliminate any technical aspect of the issue.

Whether it actually works 100% of the time and depending on the tools used and how the the site was built... is another story all together.