Bootstrap Layouts 8.x-4.1 incompatible with Drupal 8.3.0

The 8.x-4.x branch will always be incompatible with 8.3.x. There is no way around this. You must use the 8.x-5.x branch for 8.3.0 or higher.

Not necessarily. The underlying layout identifiers (from this module) haven't changed between 8.x-4.x and 8.x-5.x, just the way they're implemented.

The only reason you're running into problems is because you're using code from branches that don't support 8.3.0 or higher (due to API changes).

You should be able to do something along the lines of:

1. Upgrade all code to the latest versions (core 8.3.0, panels 8.x-4.x, bootstrap_layouts 8.x-5.x).
2. Might need to rebuild cache here so the dependency on layout_plugin is removed from the above module's cached .info.yml in the database.
3. Uninstall the layout_plugin contrib module and then remove the files.
4. Enable the layout_discovery core module.
5. Run any updates.
6. Rebuild cache.

Then everything should work just fine.

Why are you uninstalling bootstrap_layouts and panels????

When I said update all the code, I literally meant just replace the actual files/code that currently exists. This doesn't require them to be uninstalled/reinstalled first. That will, as you pointed out, remove content/config.

Follow my steps in #4.

Yw!

Thanks for this thread, it got me well on the way to fixing panels + layout_plugin + bootstrap_layout problem w/ Drupal 8.3.0, but I ran into some issues.

Previous modules:

• - panels 3.x
• - bootstrap_layout 4.x
• - layout_plugin 1.x

This is what it took for me to update without losing any settings. Everything is executed from drupal's root:

# 1. download panels 4, then bootstrap_layouts 5. order matters
drush dl panels-8.x-4.0-alpha1 -y
drush dl bootstrap_layouts-8.x-5.x-dev -y

# 2. manual uninstall of layout_plugin - https://drupal.stackexchange.com/a/154888/25221
rm -rf modules/layout_plugin
rm -rf sites/default/files/php

# 3. remove bootstrap_layout services dependency on layout_discovery
mv modules/bootstrap_layouts/bootstrap_layouts.services.yml modules/bootstrap_layouts/bootstrap_layouts.services.yml.bak

# 4. enable layout_discovery
drush en layout_discovery -y

# 5. restore bootstrap_layout services
mv modules/bootstrap_layouts/bootstrap_layouts.services.yml.bak modules/bootstrap_layouts/bootstrap_layouts.services.yml

# 6. rebuild
drush updatedb && drush cr
# expect warning: The following module is missing from the file system: layout_plugin bootstrap.inc:240

# 7. fix database expecting layout_plugin module
drush dl layout_plugin -y
drush pm-uninstall layout_plugin -y
# expect warning: layout_plugin is already uninstalled.
rm -fr modules/layout_plugin

# 8. sanity check- should have no warnings related to bootstrap_layouts, layout_plugin, layout_discovery, nor panels
drush updatedb && drush cr

@daggerhart thanks for the step-by-step! I ran your commands mostly verbatim except I used panels-8.x-4.0-beta1 instead of panels-8.x-4.0-alpha1. I couldn't run step #4 "enable layout_discovery" without first uninstalling layout_plugin due to the following error:

Module layout_discovery doesn't meet the requirements to be enabled.
Layout Discovery cannot be installed because the Layout Plugin module is installed and incompatible.

Once I got past that, the rest of it worked pretty smoothly until I hit my homepage, which uses a "onecol" bootstrap layout. I get the following error:

Uncaught PHP Exception Drupal\\Component\\Plugin\\Exception\\PluginNotFoundException: "The "onecol" plugin does not exist." at C:\\Users\\USERNAME\\devdesktop\\example\\docroot\\core\\lib\\Drupal\\Component\\Plugin\\Discovery\\DiscoveryTrait.php line 52

I also get the same error when I try to edit the home page's panel page at http://example.dd/admin/structure/page_manager/manage/home.

Any idea why the "onecol" plugin wouldn't exist and how to get it back?

#10 is where it's at.

Thanks daggerhart!

Any idea why the "onecol" plugin wouldn't exist and how to get it back?

Because you're apparently also upgrading from bootstrap_layouts-8.x-3.x.

This layout was removed/converted to bs_1col in 8.x-4.0.

The last step should have ran the update hook and converted your layout instances for you.

If it didn't (maybe because schema is 84xx?), you might have to upgrade to bootstrap_layouts-8.x-4.1 first.

@markcarver I was updating from 8.x-4.1 to 8.x-5.x-dev like I mentioned in #2867380: Broken layouts after updating to 8.3 Core. My experience appears to be related to an existing issue with Panels 8.x-4.x-dev #2871018: Upgrading to 8.4 brakes layouts, but I haven't had any luck running drush cim or manually importing through the admin interface the changed configuration files from "layout: onecol" to "layout: layout_onecol". Getting a little desperate, I updated the config value in the database from "onecol" to "layout_onecol". That allowed me to access the home page again except it was returning a 404 Not Found. Going to the admin panel page settings, it deleted my "Home Page" Panels plugin from the Variants fieldset. Now when I go to add a new panel plugin to the page variant, I'm getting "The "" plugin does not exist.", which appears to be related to this issue #2761435: Layout select is missing and throw a missing plugin exception.

#10 was practiced and tweaked a dozen times, it is repeatable and not problematic.

The goal was to not lose any settings or data in existing panels. You can't uninstall layout_plugin w bootstrap_layout enabled. Can't uninstall bootstrap_layouts while they are in use in panels. There are bunch of other gotchas like those two in the process.

I also tested the process from #10 and it seems to work. No issues yet. Still, no fun in doing all those manual steps and it doesn't use composer.

I translated the steps from #10 for composer. Starting point is Drupal 8.2.7, DS 2.6, Bootstrap Layouts 4.1.

1. composer remove drupal/ds drupal/bootstrap_layouts
2. composer update drupal/core --with-dependencies
   Make sure Drupal core is updated to 8.3.1.
3. composer require drupal/ds:~3.0 drupal/bootstrap_layouts:~5.0
4. Add patch (attached) in composer.json.
5. composer update drupal/bootstrap_layouts
6. Deploy
7. drush updatedb -y && drush cr
8. Remove patch in composer.json.
9. composer update drupal/bootstrap_layouts
10. Deploy
11. drush updatedb -y && drush cr

The "drush updatedb -y && drush cr" can be replaced with your normal upgrade process which may include configuration import, just make sure to leave no traces of layout_plugin :).

What a stunt!!! And we've been told that minor versions of Drupal are backwards compatible and upgrades should run smoothly. So we should upgrade immediately just not to stay on unsupported versions. Yeah, right! With 8.3.0 you are forced to "upgrade" DS to a beta version, "upgrade" Bootstrap Layouts from a stable version to a DEV version, and trade Layout plugin ALPHA for Layout discovery which is an experimental module. Safe! Safe and sound!

@daggerhart
Thanks a thousand times! It saved me a lot of time. #10 works for me.
@mfernea

Safe! Safe and sound!

So true :)

And we've been told that minor versions of Drupal are backwards compatible and upgrades should run smoothly.

For stable code, sure, this is very true.

Everyone seems to keep forgetting that the layout_plugin contrib module only ever had dev/alpha releases and that the new layout_discovery core module is also still in experimental stages.

Don't blame those of us who are actually doing the work to try and get these new concepts out the door. It was your decision to use said experimental code in production sites. It is your responsibility of handling manual upgrades of experimental code, not ours (yet).

Ironically, I did make an easy upgrade path for the 8.x-3.x -> 8.x-4.x changes, even in experimental code because I do care.

However, this kind of change cannot be "upgraded" via code using a simple drush updb process. Nor is it simply a "single project upgrade".

The whole point of "layouts + 8.3.0" is centered around namespace and API changes.

That requires manual intervention to uninstall the old contrib module and enable the new core module.

This also requires to uninstall the old contrib modules that used the old APIs and install the new contrib modules that use the new APIs.

Then, on top of all that, you also have this project that provides layouts to said contrib modules which also has to be updated to the new APIs.

The process for how this should exactly happen differs drastically, the least of which, is based on how the site was built and with what external tools are being used to manage extensions.

With 8.3.0 you are forced to "upgrade" DS to a beta version, "upgrade" Bootstrap Layouts from a stable version to a DEV version, and trade Layout plugin ALPHA for Layout discovery which is an experimental module.

They're all, ultimately, experimental because they use experimental upstream APIs. However, that being said, a module that depends on experimental code can become "stable" because it the "stable" part pertains to just that project. The reason the 8.x-5.x branch in this project hasn't released a stable version is because, quite frankly, I haven't had the time to test everything and ensure that the new core APIs work like the previous contrib counterparts.

Instead of whining and complaining that open source doesn't live in the perfect world, how about you actually help us with these tasks so it doesn't just fall to a single individual to do all this that you get for free?

o_O

---

To summarize:

The concept of "layouts" has never been "stable".

It's experimental.

Whenever an API change happens, it requires a manual upgrade process for all code involved; that's just how "APIs" work.

It's no one person's "fault" for all this, expect maybe your own.

Hi @markcarver. I agree you're right in what you are saying and yes, those that used these modules maybe should have helped more. While I never thought that it's the contrib modules' mantainers fault for these issues, I still think that Core maintainers should have thought of a better solution.

A good solution would have protected contrib modules and the devs & site builders that are using them. Contrib maintainers should deserve a lot of respect from core. You are doing a lot of work and giving it for free. I totally agree with you. There's a risk of people loosing trust in contrib and it's not fair. Core whithout contrib...

I would also point out that Layout Plugin is 9th most popular Drupal 8 contrib module and Display Suite 22nd. And people didn't install any alpha module on purpose. They just installed Display Suite or Bootstrap Layouts or Panels. They may or may not noticed the alpha dependency. And for some, it's a very tough call to refrain from installing a very popular module with a stable release version just because it has an alpha dependency.

I also totally agree with webchick:

Well, I'm not sure "use this alpha that 15K other people, two major contributed projects, and several distributions are also using in production" vs. "use this alpha that has been refactored from the original and no one else has used in production yet" is the same level of risk, like, at all. :)

All the best for you! And I hope for better decissions for core in the future.

I still think that Core maintainers should have thought of a better solution.

They did. It's called "experimental modules". This concept, which is also experimental in and of itself, is the best of many different worlds.

A good solution would have protected contrib modules and the devs & site builders that are using them.

There is. It's called "documentation", which there is plenty of in a multitude of places.

Contrib maintainers should deserve a lot of respect from core.

You say this as if we didn't know this change was coming. We knew, because that was the plan from the very beginning, before DS/Panels even began porting to 8.x, more or less. It was brought up years ago at several DrupalCons and BoFs.

The fact that core introduced a new "experimental module" concept actually proves how much respect they have for contrib. This allows for contrib POC/popular modules to make their way into core more easily should the need arise (as was the case with layout_plugin).

I would also point out that Layout Plugin is 9th most popular Drupal 8 contrib module and Display Suite 22nd.

Not really a point, just a fact. And it's this way because people want (not need) the functionality. It was decided that an abstract API would created and yes, depended on, because we all needed real world use cases to figure out the bugs and desired functionality. That is the whole point of "experimental": to get people to use it (with the understanding that things may break).

They may or may not noticed the alpha dependency.

Any dev/site builder worth one's salt will pay attention to what is actually being installed on their site, installed as a dependency or not.

And for some, it's a very tough call to refrain from installing a very popular module with a stable release version just because it has an alpha dependency.

Which is why the responsibility falls to the dev/site builder. If they choose to install it, then they should be prepared for things to break down the road. No, it doesn't always happen, but this is simply a case where it did.

I also totally agree with webchick:

The comment (https://www.drupal.org/node/2811175#comment-11957675) you're referring to is taken completely out of context to just support your position. If you actually read further in that issue, you'll see that the contrib/core modules were only ever intended to support ds/panels. These contrib projects are the "authorities" (probably along with this one now) on what constitutes "stable".

It was known that the move from contrib to core would be "tough", but there is really no way around that.

I knew people would complain, which is why I provided the above "rough steps" because it's more of a something that has to be thought through and implemented manually per site, depending on how its built. There is no "one solution fits all" scenario here. This is why there are 3 different types of "steps" currently on this issue.

It's also why I closed several issues and pointed it here. To consolidate the information so people can see all solutions and figure it out for themselves.

What I (and I'm sure others) don't appreciate is generalizing comments that indirectly blame both core and contrib for this topic (which is what you did). It has been a well known, well documented, well discussed topic for years.

In a perfect world, yes, we would have added a complete module before letting contrib even think about relying/building on it. But that was the old way of doing things and why "new features" took 5+ years to make their way into core.

But this isn't a perfect world. It's open source. People in both core and contrib areas are working hard to continue adding new and exciting features that benefit us all.

Ok, thanks for the feedback!
All the best!

Hi Mark

I would like to share my Drupal 8.2.x to 8.3.x upgrade experience as it relates to Display Suite and Bootstrap Layouts.
I was having the same reported issues with trying to do an in place upgrade of Display Suite 8.2.6 to 8.3.0 and Bootstrap Layouts 8.4.1 to 8.5 after the Drupal upgrade to 8.3.2, (I was following the steps outlined in #4 above).
My resolution was as follows:
1. Login to the Drupal CMS UI and select Uninstall from Extend
2. Uninstall Bootstrap Layouts (8.4.1)
2. Uninstall Display Suite (8.2.6)
3. Uninstall Layout Plugin (8.1-alpha23)
4. Confirm all have been uninstalled from Extend list.
4. Clear all cache
5. Logout and stop the Website.
6. Remove the module sub-directories for the above modules under your site directory.
7. Start the Website and login to Drupal CMS UI.
8. Enable Layout Discovery.
9. Proceed to install Display Suite (8.3.0) and Bootstrap Layouts 8.5 from Extend/Install.
10. Proceed to reconfigure your Content Types.

Thanks.

Robert

Thanks a lot Mr.rdw99 it worked for me.

In my case, uninstalling modules wasn't an option that I could use on the website that I had to update.

Based on #10, I realized that renaming bootstrap_layouts.services.yml file does the trick. There's no need to delete the module to manually disable it like it's described on step 2.

This is the script I used to perform the update:

Note: I ran the script from sites/default folder

cd ../../

# Rename temporally bootstrap_layouts.services.yml
mv ./modules/bootstrap_layouts/bootstrap_layouts.services.yml ./modules/bootstrap_layouts/bootstrap_layouts.services.yml.bak

# Disable layout_plugin module and enable layout_discovery module

cd sites/default/
drush pmu layout_plugin -y
drush en layout_discovery -y

# Restore bootstrap_layouts.services.yml
mv ../../modules/bootstrap_layouts/bootstrap_layouts.services.yml.bak ../../modules/bootstrap_layouts/bootstrap_layouts.services.yml
drush cc module-list;

# Perform database updates
drush updb -y
drush cr

# Apply any entity updates available
drush entup -y
drush cr

# Sanity check to make sure no errors or failed updates are not being applied.
drush updb -y
drush cr

Thanks @daggerhart!