Allow layout builder sections to be nested.

All of the accessibility work done so far has been on the assumption that there is a linear sequence of sections. All the indications I heard from the layout initiative team were that nested sections weren't part of the plan. Adding nested sections will complicate accessibility, to the extent that all bets are off for the accessibility plan so far.

Just passing along two workarounds available to the site-builder or themer now:

1. This one will not solve all use-cases, but, if placing custom or one-time-use inline blocks (or paragraphs), they can also be laid out with layout builder. So, a block laid out in two columns could be placed in my node within one of 2 columns. However, the two layouts would be happening at different routes, I believe.
2. Even though one of Layout Builder's great features is the ability to build a complex layout by stacking simple layout sections, the site-builder or themer could write a more complex layout to be used within layout builder.

I agree with @andrewmacpherson that this could cause accessibility problems. I think we should continue to improve the accessibility of current functionality before adding features that will make it more complicated.

The examples in the issue summary to don't seem like they need nested sections

placing an image and text in a 2 column grid (often called a media object)

This should just really use the media module. Then you could use the Layout Builder on the media display.

a grid of cards or photos

This could either be a View in a grid or a custom block that has references to media entities(that you could add directly when the media library is stable). You could use different view modes on the block type to allow different arrangement of the media entities on the block display.

Example use case I've run into: At the high level the page needed to support 2 columns: sidebar and main content. But, the content inside the main content "side" of the 2 column section needed to be able to be laid out with multicolumn subsections. I can't just define a custom layout b/c the main content side needs to be able to be customized and I don't want to lock the editor into a specific grid or masonry layout and I don't want to force them out of the Layout Builder UI to create something with a different contrib module. The current workaround is that we created a custom "sidebar" one column section layout but will be using CSS to force it to render to the side the rest of the sections under it.

For accessibility, it would be good to know the specifics for which pieces don't currently support a nested approach.

My envisionment of this would be similar to D7's Mini panels. Whereby you can create reusable pieces that can be placed into layouts and receive context from the layout driven entity.

Interestingly, here is a contrib module posted two days ago: https://www.drupal.org/project/mini_layouts

I think using module like Paragraph blocks: https://www.drupal.org/project/paragraph_blocks for using the Layout

Sections: each section can contain content arranged in a certain layout.
Example: 2 columns, 3 columns, etc.

Inside each section, you can display:
Fields from the content being displayed. Example: title, body, tags, etc.
Blocks which appear on the Structure > Block Layout page.Example:Page title, tabs, blocks from the custom block library, etc.

Here's more explanation: https://www.youtube.com/watch?v=73uepd9CLFI&feature=youtu.be

The mini_layouts project would solve this use case:

https://www.drupal.org/project/mini_layouts

@rlmumford this is awesome I'm going to check it out.

Actually, it might be surprisingly easy to do already.

I think we can define layout regions dynamically in the custom Layout's constructor, based off the Layout configuration, by modifying $plugin_definition. It seems to work. That way we can just plainly configure new layout regions and structures in our layout configuration. Sky is the limit. :)

I'm still playing with it, but it seems to work.

#3075939: Allow layouts to provide dynamic regions Guys, what do you think about this approach? It's much less invasive, and contrib modules could easily implement configurable sublayouts/subsections which would be simply a part of section's configuration.

Hello, I've started to implement nested layout on the project, right now the work still in progress and as a limitation, it supports only one level of nesting (but honestly that's enough) otherwise it requires huge refactoring of layouts module.

Implementation

In the core, we have two base models: Block and Layout.
Layouts contain blocks inside, it stores their Uuid, order, and configurations.
Block presents some real content, it can be entity, field or anything defined as Drupal's block.
In my implementation, I've added a new block type called LayoutBlock which supports both Layouts and Block inside. Improved default routes to support Block Uuid of source and destination blocks. Extended standard controllers and rendering and added an additional check for LayoutBlock and iterating through all children.

I'll try to move it to contrib module when I finish, right now I can share only screenshots.

@zviryatko that sounds exactly like the mini_layouts module.

@rlmumford, yes, implementation similar, but I want to achieve the possibility to moving components between different nested layouts on the same page, to make it easy and avoid opening many pages when you just need simple move block from one sub-section to another. Does mini_layouts allow to do it like in screenshot that I provided?

Wow, this would be really nice to have. Any update on this issue?

In fact it's much simpler and does not require new concepts:
1) ☑ Create a lb_block block type that is, well, LB enabled
2) ☑ Place a block of that type in any LB layout
3a) ☑ If it's a reusable block, we can edit it's layout on a separate page and are done
3b) ⚠️ If it's an inline block, we want to edit it's layout (probably on a separate page via target=_blank, as we die in panels for views for ages)

So it boils down to: Provide a link to edit an inline block's layout.

Hello everyone, :)

I'm currently working on this topic and would like to share with you my progress.
First off geek-merlin comment in #19 helped me alot.
But I wasn't pleased with the idea of "edit it's layout on a separate page" which is simply outdated and shouldn't be used in any way in 2020.
This should also be possible in the same block (in my case block content).

So my idea was (My code depends on "Block Content" entities but it also should be able to support other entities):

Please do remember, that this is code to prove that my idea actually works.
1. Do the tasks from 1) to 3a) from #19
2. Create a hook which preprocesses the element (in my case an inline block).

/**
 * @file
 * Contains hook.module.
 */

function hook_preprocess_block__inline_block__myaccordion(array &$variables) {
  $routeMatch = \Drupal::routeMatch();

  // \Drupal\layout_builder\Controller\LayoutBuilderController::layout
  $allowed_routes = [
    'layout_builder.move_block',
    'layout_builder.overrides.node.view',
  ];

  // Check if we are on the right route.
  if (!in_array($routeMatch->getRouteName(), $allowed_routes)) {
    return;
  }

  /** @var \Drupal\block_content\Entity\BlockContent $block_content */
  $block_content = \Drupal::entityTypeManager()->getStorage('block_content')->loadRevision($variables['configuration']['block_revision_id']);
  
  // Load the controller which handles the render.
  $layout_view = new \Drupal\layout_builder\Controller\LayoutBuilderController();

  // Get context.
  $entityContext = \Drupal\Core\Plugin\Context\EntityContext::fromEntity($block_content);

  /** @var \Drupal\layout_builder\SectionStorage\SectionStorageManager $sectionStorageManager */
  $sectionStorageManager = \Drupal::service('plugin.manager.layout_builder.section_storage');

  // Load the corresponding section storage.
  $sectionStorage = $sectionStorageManager->load('overrides', ['entity' => $entityContext]);

  // Render and override the elements.
  $variables['content'] = $layout_view->layout($sectionStorage);
}

3. Apply the patch 3053145-layout-builder-in-layout-builder.patch. It updates the layout builder html id attribute, so the right element gets replaced when adding new sections, blocks etc..

Until this point almost everything looks as expected and works really good.
The problem I face currently is that the initial loading of the nested element is empty (Provided by the hook).
But editing the nested element somehow updates the nested element with the previous edited stuff.
It would be really cool if someone who created or helped to create layout builder could explain how this one works.

Worth mentioning is that I commented out drupal/core/lib/Drupal/Core/Routing/AccessAwareRouter.php Line 115 - 122
as it throws an excess denied, even when I'm Super Admin.

Problems to solve before this can be used.

1. Initial loading of the nested element.
2. Access » Somehow I get access denied as Super Admin.
3. Submission of the nested element.

Greeting,
Eugene :)

A cheap and easy solution would be to allow nesting of view modes with layout builder.

Here is what we would need:

• Have a block type that simply renders the same entity, but in another view mode.
• Prevent recursion as in #2979184: Layout builder does not protect against recursion.
• Get rid of entity wrapper html for the inner view mode (not sure if this is needed).

I'm really looking forward to using this (even as a patch). Any luck on getting the open issues fixed?:

1. Initial loading of the nested element.
2. Access » Somehow I get access denied as Super Admin.
3. Submission of the nested element.

@Eugen Zerr #20: Cool that i could inspire you!
TBH i did not fully realize your workaround.

But here is what i thought when i looked into the source code last time:
- What we need is a "edit layout" contextual action
- What we do have is a "edit" contextual action

So we can look into how the "edit" contextual link and action is implemented. It combines
- editing the inline block
- updating the revision reference in the layout (because a layout always has to ref the latest revision, otherwise it coughs)

So what we have to do is, imitate everything that is done in "edit", and imitate it in "edit layout".
Feel free to PM me if you want to work on it and need more pointers.

I think the mini layouts module does the job.

What you need is the module LayoutComponents

This is an example of what you are able to do:

In this example you can see a parent section with 2 colums, in the first region are included 2 more sections with their regions and 1 more in the second region of parent section. Ofcourse without needs to generate any twig or modification by code because the module generate the structures dinamically dependly the configuration seted in each section.

pd: The sub section functionallity are under development but will be available very soon.

Almost 2 years further, is there by chance any update on this? Any way to fix this instead using another module like layoutcomponents?

Tagging for https://www.w3.org/WAI/WCAG20/Understanding/focus-order which is the most likely error which would be introduced by this feature.

Seems both the most promising modules:
- https://www.drupal.org/project/mini_layouts
- https://www.drupal.org/project/layoutcomponents
got abandoned, I see no new commits during the last 2 years and no support for Drupal 11.x

Maybe some alternatives appeared to allow inserting sections into sections or somehow group blocks in the region of the Layout Builder Section? For example, simply group two fields to display as one line, like this:

<div class="group--full-title">
  <div class="field--title">My title</div>
  <div class="field--title-suffix">with suffix</div>
</div>

As a Drupal 11 developer, i also face similar issue. And both suggested module do not supported. And don't want to deal with content blocks as some workarounds shows.

This is really fundumental basic thing when we think layout builder. But not sure why this not prioritized.. maybe whole layout builder get abandoned for sake of new experience builder thing..

Seems this is not possible from the technical side because of the limitation of the initial architecture of the Layout Builder components. So, the Drupal community rethought this approach from scratch and re-implemented it as Drupal Canvas https://www.drupal.org/project/canvas

Therefore, seems all new efforts will be invested into developing Drupal Canvas, instead of improving the Layout Builder ;(

Hi,

Canvas is not the only alternative.

There is also https://www.drupal.org/project/display_builder, related to https://www.drupal.org/project/ui_suite.

Disclaimer: I am involved in Display Builder development and UI Suite core team.

PS: Hi @murz, hope you enjoy the apron from Trivia night ;)

@emircan erkul Please read the issue priority guidelines before escalating: https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-...

On rare occasions, Drupal core product managers may identify an especially important feature request as critical. In most cases, only core committers should mark a feature request as critical, and it is ultimately up to the product managers to determine which feature requests are critical.