Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.See #2924058-3: Discuss using Layout Builder to control full site layout and replace Block UI for the background of this request.
There was concern raised that site builders new to Drupal might not understand that when selecting a layout from Layout Builder, that this layout is only going to affect the "content" area of the page, not the "page" itself (as in the top-left of the browser chrome to bottom right). And furthermore, communicating how to affect the area of the page not affected by Layout Builder.
We need some updated mocks / designs / docs that help communicate this to site builders so that they don't make poor decisions and/or get frustrated/lost in the process of designing their site layouts.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | Screen Shot 2018-01-15 at 1.07.23 PM.png | 71.2 KB | webchick |
| #18 | Screen Shot 2018-01-15 at 1.07.38 PM.png | 73.01 KB | webchick |
| #14 | 2935779-layout-13.patch | 1.54 KB | tim.plunkett |
| #13 | Screen Shot 2018-01-15 at 11.31.44 AM.png | 512.49 KB | webchick |
| #11 | 2935779-11.patch | 3.43 KB | eclipsegc |
Comments
Comment #2
webchickWe should aim here to come up with both a longer-term solution, and also something that can minimally meet this requirement for beta. (Unless these are both the same thing, in which case, great.)
Comment #3
tim.plunkettIn order to even get the Layout Builder UI to work on the front end, you'd need to have clicked a checkbox on the Manage Display page
'#title' => t('Allow each @entity to have its layout customized.', ['@entity' => $entity_type->getSingularLabel()]),One possible short term solution for beta would be to put something in a
#descriptionfor that checkbox, explaining that the Block UI still controls the blocks outside the main content.Comment #4
xjmI would suggest making two issues, one issue solely focused on the beta MVP (we need something), and have a separate one for the final design. That way we can clearly identify when the beta requirements are met, and pursue the full design for stable. Tagging this one as the beta blocker for now.
Comment #5
wim leersComment #6
wim leersNaïve suggestion: Can't we use the same "highlighting of parts of the page" that Settings Tray uses while it's in edit mode?
Comment #7
webchickThat's what I was thinking too, yeah.
Comment #8
xjmYeah I also had that UI in my head. The one difference is that part of the need (from a release management perspective) is that we also need to hint at what parts need to add blocks in the block UI instead (in order to prevent hard-to-undo site building issues that result from having a new feature available that works really nicely but an undiscoverable one that you should use in other cases). It's different for ST (from the un-editable blocks, I mean) because ST has less impact on your site building decisions.
But the "where else?" could be something as minimal as a link and that would address that concern for me for beta at least.
Comment #9
dyannenovaI think for beta the description when enabling Layout Builder UI on an entity is helpful. I'm working on some mockups now for an affordance we could build out after beta.
Comment #10
tim.plunkettWe need actual text to put there. Any suggestions?
Comment #11
eclipsegc commentedOk, my take on this includes a hook_help, and a bit of description in the main text of the page. The "Manage layouts" sits inline, so we should fix that but... thoughts?
Eclipse
Comment #13
webchickWe (@tim.plunkett, @EclipseGc, and I) spoke at length about what to do with this situation.
It seems like the best place to focus energy on solving this is on the point of actual potential confusion, which will be the Layout Builder UI itself, rather than the overall help page, the site builder interface, etc.
So we talked about various places where this message could go, from a drupal_set_message() (not ideal, because it trains people to ignore these), toggling "Edit" mode on when in Layout mode (the subsequently exposed contextual links solves the "how do I edit THAT thing?" problem but also clutters up the page pretty badly), etc.
Where we landed was a hook_help() entry that appears anywhere the Layout Builder appears (meaning on the per-entity side as well as the entity display side), since that is an API designed for this problem of showing general information/help text contextually.
We debated the exact text back and forth, came up with something kinda "meh" and then @dead_arm swooped in and made it pretty great, which is:
(The "block administration page" in the last sentence appears as a link conditionally, if you have permissions to actually use the page.)
The end result looks like this:
Marking "needs work" so we can get a working patch. :)
Comment #14
tim.plunkettI think this is a good path forward for the MVP.
Comment #15
eclipsegc commentedSince this is a complete departure from my patch, I feel comfortable rtbcing it.
Eclipse
Comment #18
webchickOk, ran this through its paces, checking:
1) The error message shows as designed when user 1:
2) It shows as designed without the link when a user with administer layouts but NOT administer blocks perms:
Kris also demoed the route matching logic, and demonstrated that the help message showed up as intended on both the "node/1" version as well as the "all articles" and "all custom blocks" version of the Layout Builder.
Since this is using an existing API to solve the problem it was designed for, and since we don't freeze strings up until RC, AND since there's a 'use' statement conflict between this patch and the last functional blocker of the Layout Builder, I decided to err on the side of getting this in so it doesn't hold anything else up.
Once @DyanneNova has mocks ready for the "v2" of this, we can spin off a separate issue for that as a stable blocker.
Committed and pushed to 8.6.x and cherry-picked to 8.5.x. Thanks!
Comment #21
xjmI agree that this is totally sufficient for beta, thanks!
Do we have that followup issue for the "pretty"/polished design like ST's (or whatever implementation designers decide on)?
Comment #22
webchickNo, because IMO we'd want to start that one with the designs @DyanneNova alludes to in #9, but they are not yet available.
Comment #23
xjm@webchick, hm? This issue would be to create said designs. :)
Comment #24
xjmPosted: #2938182: Design intuitive affordances for Layout Builder (for illustrating which parts of the page are editable in a given context)
Comment #26
tim.plunkett