Discuss using Layout Builder to control full site layout and replace Block UI

So I think this issue must block a stable layout builder. Here’s why (wall of text incoming):

When the site builder builds a layout (either for an individual entity or, eventually, for an entity display), they choose a layout in a sidebar list like this:

If the site builder selects a "four column" layout followed by a "two column" layout and places blocks in that layout, they would rightly would expect this layout, as shown beautifully in the designs and Driesnote demos:

However, there’s a good chance they might get this instead:

This could be very frustrating for the user -- the site builder wants to get rid of the Search and Tools blocks that don't belong on their "Latest recipes" page, but they can't. They want the blue header to get lost, but they can't. They want to put a nice banner at the top above the title, but it ends up under the title, under the blue bar, to the right of the Tools block. They select four columns, but they get five.

• For individual entity layouts (e.g. landing pages) they see the results of their actions in context on the frontend (on the entity itself). In this case the frustration is mainly that they can't get rid of the "page chrome" that they really do not want for a landing page. So it doesn't meet what I'd consider the minimum requirements for landing page functionality to be stable.
• For entity layout defaults (entity displays), the problem might be even worse, because the site builder will build their layout on the backend in the admin theme, and it will look gorgeous. And then they will go to the frontend and the blue bar and sidebar they don't want are there. And then they go back to the backend and try to make them go away, but they can't. They double-check their selection for the number of columns, and they can't get it to work.

In order to understand why they get the second thing with the existing "page chrome" instead of the first thing that's shown in the Layout Builder comps, Driesnotes, etc., the site builder would need to understand Drupally concepts and internals -- the distinction between blocks placed with the block UI, and those placed inside the entity display. Especially with #2918500: Create a block which can render entity fields and #2922033: Use the Layout Builder for EntityViewDisplays, this distinction won’t make much sense to the user (and I contend that it might not make much sense from an architectural perspective, either).

Let's say that the user eventually does figure out that they have to go into the block UI and delete all the existing block instances in order to use the beautiful, user-friendly Layout Builder for the whole page, instead of the confusing, access-restricted, scary form that is the legacy Block UI. They then start building all the layouts on their site by shoehorning every page of their site into being either a customized entity landing page or a content type/entity default display. In order to use the nice UI, they make site building decisions that would take a lot of time to undo. They will run into some pretty steep limitations:

• They have no way to actually use the regions defined in their themes.
• They have no way to get a section like the typical sidebars that spans vertically along multiple sections.
• They will probably eventually run into something that isn't already exposed as a block or otherwise makes no sense as an entity or entity display in their sites' entity data model.
• Probably other things I haven't thought of.

So to address these issues, we'd need to decide what to do about Layout Builder vs. theme layouts as part of the stable release. This adds a lot more scope (scope that was very reasonably excluded from the alpha version, but I don't think can be excluded for a stable version):

• Does the Layout Builder have any awareness of the theme regions? How do we communicate that those regions aren't editable by the Layout Builder? Lots of design work needed around this I think.
• Otherwise, how do we use the Layout Builder to get something like the Bartik header, where there's a wrapper around three different "sections"? (Header, Primary Menu, Secondary Menu)
• If we do support Layout Builder for themes/"page chrome" alongside entity layouts, we then end up with what's essentially nested sections -- all the entity stuff is inside one block-like area of one section of the theme layout.
• Probably lots more questions.

Finally, building a layout is a time-consuming task. If I build a layout at one level (be it entity, entity default, or theme) and then realize that some or all of the blocks need to be placed at a different level, it's going to be a lot of work to redo it in a different context. I think Layout reuse is not ccurrently included in the current MVP scope, but it's going to be a big deal especially if we don't have the three different layout senarios working pretty smoothly and interchangeably with the Layout Builder UI.

(Fixing broken upload.)

I think most of #3 is addressed by the site builder setting the site up without sidebar blocks, which is perfectly within their purview to do. I emphatically do *not* agree that we need to solve the Panels Everywhere use case in core in order for users to benefit from the Panelizer and Page Manager use cases in their production sites.

Remember that for content authors, the current process for laying out a page in core is:

(aka, go ask a developer to make a template for you, and then ask a site builder to put the blocks in the right place.)

The process using contrib modules is only slightly less Matrix-y, and involves something like 5 different projects, configured precisely just so, navigating your way around completely obtuse terminology.

This module is already light-years beyond the current best layout-building usability that Drupal offers. We should not hold up a stable release of this functionality on fulfilling every possible use case under the banner Layouts. That's the joy and the beauty of 6-month release cycles. We can get the basics out, gather actual evidence on user pain points, and iterate from there, vs. trying to address it all up-front.

A "Panels Everywhere"-style Layout Builder sounds like a lovely addition in 8.7 or 8.8.

Discussed #3 and #4 on a call with the Layout team just now... conclusion was that we spin off an issue to ensure there's a visual affordance given to users to explain what parts of the page are/are not covered by Layout Builder, and some guidance on where to change the rest (i.e. pointer to Block UI).

Need an issue for this.

To clarify #6, there are three parts:

1. Having something very minimal that tells users what they can/should do WRT entity layouts vs. entity display defaults vs. block placement in the theme is a beta blocker, because without it non-"I've worked for Drupal shops for 10 years" site builders are fairly likely to make possibly regrettable site building decisions, which also affects their stored data relating to entities, entity displays, and per-theme block instances. Up to initiative designers and the UX team what the scope of this tiny MVP is. (Compare #2934885: Document the difference between File, Image, and Media fields, which is a paragraph of help text addressing massive UX issues just enough for Media's version of "beta UI" (i.e. shown to normal site builders so they have a chance to make good site building decisions for things that affect their site data).
    
2. Having a feature-complete version of the affordance design that communicates all this to the user is likely a stable blocker, but does not need to block beta.
    
3. Actual implementation of using Layout Builder for "page chrome"/themes is not a stable blocker, but is a high-priority feature for subsequent releases.

Ok, spun off #2935779: Come up with an affordance for what parts of the page are/are not affected by Layout Builder for the first/second thing.

As someone who uses Drupal to provide sites as a service (with 1,000+ active sites using our distribution) where the content author is also doing all site and layout building, the lack of a full page layout builder just puts us more in the position of porting our D7 layout builder or not moving to D8 at all.

It seems odd and un-ux-y to require the site builders to use multiple and conflicting tools to make simple page layout decisions.

Thanks xim for detailing why this issue is important and should be considered a high priority.

Know I'm coming a bit late onto this, but...

I've been using Panels Everywhere in D7 to fully control the layouts on my sites, using custom themes.

Right now, in D8, I have test builds up in 8.5 using Page Manager, Panels and Panels Everywhere P.O.C., and it's workable. One of the advantages of this method is the ability to set up rather complex contexts for display rendering, as well as having most controls in a GUI that's relatively user-friendly.

I'm more design/UX/IA/front-end, but can offer help. The main objective I'm looking at is a supported, extensible system that offers a number of layout and design possibilities. It could be a major selling point, and an inroad for Drupal into more design-centered organizations who now view it more of an enterprise-focused application framework.

Re-roll of #14

re #22
Added to summary

Test current patch

Go to /page-layout/bartik to test it out.
Unless you add the "Tabs" block you won't see the buttons (lol)
So you can go to /page-layout/bartik/save if you want to save.

from #2

re: #3

For entity layout defaults (entity displays), the problem might be even worse, because the site builder will build their layout on the backend in the admin theme, and it will look gorgeous.

I am not sure when this changed but currently layout defaults used the default front-end theme.

They have no way to actually use the regions defined in their themes.

Using the layout Builder with the idea of regions doesn't seem make sense.
I think taking over the whole page should be opt-in because all themes now are built around regions.

Themes can provide section and they can remove section, via a hook, so they can have complete control over what shows up in the sections available.

Because themes can also implement hook_plugin_filter_TYPE__CONSUMER_alter they could also make only certain sections available when controlling the site chrome.

Otherwise, how do we use the Layout Builder to get something like the Bartik header, where there's a wrapper around three different "sections"? (Header, Primary Menu, Secondary Menu)

This is basically what "sections" are in layout builder. A theme can easily create a "Header Section" that has regions for the Header, Primary Menu, and Secondary menu.
Using hook_plugin_filter_TYPE__CONSUMER_alter they could make this section only available for site chrome.

I think themes could also emulate the fixed region system we have now by simply making only making only 1 section available for adding when controlling the site chrome and not allowing adding that site 2x.

I think regarding the demos in the driesnotes

This could be very frustrating for the user -- the site builder wants to get rid of the Search and Tools blocks that don't belong on their "Latest recipes" page, but they can't. They want the blue header to get lost, but they can't.

Unless we have an option in the layout builder(except when controlling "site chrome") to "Take over whole page"(with better wording) we are still going to have this same problem. User would still have to go to another place to control what surrounds the current layout whether it is current block ui or a "site chrome" layout builder.

If we had "Take over whole page" option on the layout builder because the layout builder is currently using the default not admin them when the user checked this option we could reload the layout builder with the other blocks showing which would give a more accurate preview of what the page will look like with the layout.

Attempted reroll, but ended up rewriting the section storage logic because of all changes since last patch. I've noticed that the Save route has been deleted, as it's handled by an entity form, but in this case we don't have a entity form.
Not sure if we should add them back, or rework the logic of buildLayoutRoutes..

This should hopefully be similar in state as #20, except the save/discard routes that been removed.

Looking very promising, would be a very cool functionality. Initially, am able to edit the layout at /page-layout/bartik, but getting a 404 when trying to save - /page-layout/bartik/save

Sorry johndevman - somehow overlooked your comment already pointing out my observation that save routes are removed :facepalm: Will be eager to see this progressing and hopefully help out in reviewing functionality.

+1 on the "use Layout Builder for entire page layout" front.

It would be a huge feat to make the new feature reach into the legacy concepts and makes sense of it all. Maybe smaller steps could be done as part of the Admin UI revamp.

Using Layout Builder on the Block layout page would vastly improve the usability of placing Blocks into regions.

Currently, the Block layout page is text-driven to a large extent, you have to read and make sense of what you're reading, construct a visual in your mind to keep track of what you're aiming at, and still struggle with what things might end up looking.

Layout Builder is a great visual tool for a visual task. Using it on the Block layout page to rearrange Blocks within "visually correct" regions would make the process much more enjoyable.

It still wouldn't be a super customized "per page" approach, you would still see all of the enabled Blocks regardless of their Visibility settings, but having visual contrast with less scrolling (that Layout builder provides) would help a lot.

Not to mention that it would make much more sense to use the same (better) concept to solve similar problems across the system. Layout Builder UI is easy to learn, and naming things appropriately (from the users perspective) could cut down on the time/effort users need to learn how to achieve various tasks.

Specifically, the Block layout could be named Page layout and the entity Manage display could be Content layout. That type of wording and a good UI placement would signal to the user that these are the tools that control the layout, they don't have to dig anywhere else and worry they misunderstood or missed anything. It wouldn't be hard to accept that there are two places where the layout is controlled, through two levels, Page and Content are easy to understand to the majority of users (needs testing lol) if the entire concept is clarified and simplified for the user.

A lot could also be improved in terms of the admin area hierarchy/placement to make it more user-centric instead of Drupal-centric but that may be out of scope here.

In conclusion, it may be that implementing the Layout Builder on Block layout page might give the highest benefit-cost ratio when it comes to the "Layout Builder for page chrome" discussion.

Not working on this any longer. It was discussed in the Layout Builder meeting that this should probably be done in contrib. first.

See #3050243: [Layout Initiative meeting] 2019/4/30.

As a contrib module solution, Page Manager now has the Layout Builder variant type. Panels Everywhere is close to being able to use it, but still has a few issues as discussed here: #3143487: Not compatible with "Layout Builder" variant as site template (Workaround found)

Here are some mockups that were user tested about two years ago. https://drive.google.com/drive/folders/1DD1Rdxj7jP-qu0lH4dXDYF7orG4G_pg1

The mockups introduce something called Layout Mode available on any page. If the page is also a content page with Layout Builder enabled, then you see what is in mockup 1 - Enter Layout Mode. This allows you to select which region to edit. Mockup 2 - Global Region - Notice shows a notice to users which no longer appears for that user after the first time they select Continue. The other mockups drill in to layout editing in those regions.

I think that the first priority is to discuss:

1. Layout Mode (which ideally would eventually be Edit Mode, combining Layout Builder and Inline Editing)
2. If layout editing by region is the path we'd still like to take. (This would mean that there is still no ability to drag a block from one region in to another.)

I see a lot of possibilities for this. However, one of the first things that came to mind for me was "how would workflows integrate with this?".

For us, we would probably want it to be possible for different parts of the page to have different states - like, changes to the global header are in draft, but the main content area changes are ready to publish.

Right now we have separate content types for our main content area, our sidebar, and our footer. Each is edited separately, and therefore each is able to have its own workflow state. We "assemble" the page for viewers based on what's in the published state.

The second thing that came to mind was "could you nest layouts with this somehow?" but maybe that's a bigger issue.

We discussed this issue at #3211757: Drupal Usability Meeting 2021-05-14. @DyanneNova showed us the mockups linked in #39. Specifically, we talked about the notification when the site admin starts to edit the "global" part of the page:

Header is a global region. Any layout changes here will be reflected throughout the site.

in an alert/modal window, with a button to dismiss the message.

Personally, I have three requests. I mentioned the first two during the meeting.

1. Give the user the option of whether to keep getting the warning.
2. Have a persistent indication of whether the "global" context is being edited.
3. Warn again when the user is ready to save.

For (1), the initial suggestion was that each user would see the warning just once. I would like to let the user decide whether to be reminded. We could have two buttons, with more polite versions of "Continue and keep reminding me" and "Continue and never bother me again!". Or we could have a "Continue" button and a checkbox. I am usually not a fan of this pattern, since it involves two clicks instead of one. In this case, the extra click is only required once, when the user wants to say "Go away and do not come back".

For (2), the mockups all show "Layout Mode" in the upper left corner of the screen: white text on a blue background. The last page of the mockups shows the different regions with transparent, colored overlays: blue for the content region and yellow for the header and footer. Why not have "Layout Mode" switch to a yellow background when editing the header or footer ("global" regions)? Maybe blue text on a yellow background would provide good contrast. I am not sure what sort of persistent indicator would work for non-visual users.

For (3), I am not suggesting another popup window that has to be dismissed. Just some additional text to remind the user what the current context is, similar to what we have in views: "Apply (this display)" or "Apply (all displays)". For Layout Builder, we might have three options:

• Save (this content)
• Save (this content type)
• Save (entire site)

Just spent 20 minutes trying unsuccessfully to find this, adding some extra words to the title.

I see a lot of possibilities for this. However, one of the first things that came to mind for me was "how would workflows integrate with this?".

I see workflows as an issue for per-entity layouts, which is already in core, so not in scope here. This is only about expanding the core feature to permanent blocks that are only affected by workflow if you have theme-placed blocks (usually always visible) manually configured to disappear on certain workflow states. Maybe worth discussing in a separate issue since it's already in core? I'd encourage you to test per-entity Layouts with Layout Builder enabled with your workflows, and see if there's a feature gap to file as an issue. There might also be something already in the queue too other than this issue for it. Thanks!

Edit: There is an aspect in your post that's how to make block configuration for these blocks based on individual entity or entity types exposed to the user, but also a separate issue I think.

Updating the title to be clearer.

I am looking for something like this as well. I recently built two sites with WordPress (not my call 🤷🏻‍♂️) after not touching the CMS in 5+ years and made use of their new Full Site Editor experience. It was a bit frustrating at first but worked. The idea of a "block theme" combined with template parts, which I would equate to theme regions in Drupal, but also template blocks seems like could be possibly done. It would probably require nesting of sections I guess? There are several other issues open related to section nesting/dynamic layout regions...

This never happened, but it's being implemented as part of experience builder.

I opened #3521172: Figure out what to do with block UI/regions in core in relation to experience builder for reconciling that with core.

Postponing on those efforts, when they're a bit more fleshed out, we could mark this as outdated.