Allow changing the layout of an existing section in Layout Builder UI

This was left out of Layout Builder on purpose because of the difficulties of providing a UI that is easy to understand. That doesn't mean we can't do it, just that it's hard!

For example, if you are moving from 2 columns to 3 columns, does it move all the blocks from col 2 into the new col 2 or col 3? (since it was on the "right" before).
And if you are moving from 3 columns to 2 columns, where do the extra column's blocks go?

Here's a proof-of-concept patch that implements changing layouts on existing sections. There's a lot of problems with it, but it's a start. :-)

Here's how it looks currently (using the Olivero theme, because layout_builder is hard to read in Bartik):

1. It adds a "Change layout" link to each section, that will show the list of layouts in the tray when clicked:

This link isn't ideal -- it's crammed next to the "Configure Section" link, so if this link stayed, it'd need to be visually separated, or turned into an icon or something.

Also, I had the thought that maybe instead of adding this link, a user could first click the "Configure Section" link and then there could be a "Change layout" link or button on that form? That might be more understandable for users because the layout settings are already on the configure layout form. I have mixed feelings, though.

There's probably a few other options for where to put the "entry point" to changing a section's layout that could be better.

2. After clicking the layout you want to change to, it shows a new form in the tray with the layout settings for the new layout, and a "Region mapping" section:

The region mapping is configuring which new region the components from the old region should go. Like with Panels in D7, if both layouts have a region with the same machine name, it uses that by default, otherwise it defaults the first region.

I'm planning to experiment with a visual version of this using Sortable, also similar to Panels in D7, however, this probably won't work so great in core, given the small width of the tray. It could however work well with this Panopoly patch that allows configuring an increased tray width: #3119481: Allow making the Layout Builder tray wider

3. After clicking "Update" the layout changes and all the components are moved to their new regions:

Here's a new patch that adds visual drag-and-drop region mapping:

This screenshot is using Bartik, along with the patch from #2958588: Off-canvas style resets are overriding styles (especially SVGs) resulting in display issues which is required for the layout to render correctly, and this Panopoly feature #3119481: Allow making the Layout Builder tray wider to make the tray 600px rather than 300px.

You can see that the select fields are updated when a region from the old layout is dragged-and-dropped into a region from the new layout. When the form is submitted, it uses the values from those select fields to do the actual mapping.

There's a couple things I'd still like to add to this:

1. Updating the layout via AJAX when layout settings are changed. For most layouts this doesn't matter, but it's theoretically possible for a layout setting to add or remove a region.
2. Add a link to toggle between visual mapping, and the plain select fields. This is similar to how tabledrag toggles between drag-and-drop and raw weight inputs. I could see the select fields being useful for really wacky layouts that can't work in the tray, or for accessibility.

Anyway, just a reminder that this is just proof-of-concept at this point! Let's discuss and if some agreement on how this should work is reached, then the code can be cleaned up, tests written, etc.

This is looking great! Thanks for resuscitating @dsnopek :)

I'll see if I can get some reviews on the UX of the approach.

+++ b/core/modules/layout_builder/src/Form/MapSectionRegionsForm.php
@@ -0,0 +1,299 @@
+class MapSectionRegionsForm extends FormBase {
...
+   * Constructs a new ConfigureSectionForm.

Even before I noticed the "ConfigureSectionForm", I could tell this was copied from there. As this is now the 2nd class to do this sort of thing, it seems worth having a base class or trait for the shared code.

I tested #9 on an existing site and noticed a few incompatibilities with popular layout builder modules. I'm not entirely sure if it would need to be adjusted in the patch or if the modules would need to be adjusted to support the changes done here.

1. When using Bootstrap Layout Builder with the optional Layout Builder Blocks dependency, configuring sections is no longer possible. The "configure section" button doesn't do anything.
2. When adding sections, normally the configure section dialog should appear, but it no longer does with this patch enabled. Configuring a section is only possible when changing the layout.
3. The manage layout part of this patch only shows text, without any of the visual elements (borders, etc). When changing layout (and if configuring sections would be possible most likely), the manage layout settings are shown on every tab. It should most likely only show these settings on the first tab.
4. I tried adding a class to a section's row via Layout Builder Component Attributes while changing a layout (since configuring isn't possible on my end as explained above), but the class is either not saved or the form is cleared every type you attempt to change the layout.

Otherwise the functionality of changing the layouts works great and am absolutely excited to see the progress on this. I hope this early feedback doesn't hinder your progress.

Also is it possible to somehow use that Panopoly patch without the Panopoly distribution?

@tim.plunkett: Thanks!

Even before I noticed the "ConfigureSectionForm", I could tell this was copied from there. As this is now the 2nd class to do this sort of thing, it seems worth having a base class or trait for the shared code.

Yes, for sure, once we're out of the PoC stage, I'm sure there's lots of better ways to organize the code.

I also had the thought that maybe we could do this without adding ChangeSectionLayoutController, because it's just a copy-paste of ChooseSectionController that only changes the title and destination link -- it could maybe just be another "mode" of ChooseSectionController or something.

@NWOM: Thanks for testing the patch!

Unfortunately, I'm having some trouble reproducing some of the problems that you're seeing.

1. When using Bootstrap Layout Builder with the optional Layout Builder Blocks dependency, configuring sections is no longer possible. The "configure section" button doesn't do anything.

I tried installing both of those modules, and adding a section that used a Bootstrap layout from Bootrap Layout Builder, but the "Configure Section" link is still working for me. Are you getting any errors in the JavaScript console or in the Drupal logs that may indicate what is going wrong?

2. When adding sections, normally the configure section dialog should appear, but it no longer does with this patch enabled. Configuring a section is only possible when changing the layout.

I'm able to add sections and I do get the extensive configure layout form for the Bootstrap layouts. Again, maybe there's something in the logs that can help figure out what's happening on your test site?

3. The manage layout part of this patch only shows text, without any of the visual elements (borders, etc). When changing layout (and if configuring sections would be possible most likely), the manage layout settings are shown on every tab. It should most likely only show these settings on the first tab.

I am seeing this issue! Those tabs are added by the contrib module. I think what's happening is that the tabs toggle what is visible at the top of the form, but aren't touching the region mapping fields at the bottom of the form, so it has the effect of appearing on every tab. This seems like something will probably need to be changed in contrib, so that it's alterations are aware of the new form elements, if this patch is merged into core.

4. I tried adding a class to a section's row via Layout Builder Component Attributes while changing a layout (since configuring isn't possible on my end as explained above), but the class is either not saved or the form is cleared every type you attempt to change the layout.

I'm not sure if I'm testing this right, because I haven't used this module before, but I think I'm also seeing what you're seeing. Depending on where that module is storing it's data, I could understand how changing the layout could clear it's settings. If it's using the layout plugin's third-party settings, those are thrown away (with the rest of the layout settings) when you switch to a new layout -- this probably can't be helped since we have no way of knowing if the settings apply to the new layout plugin.

But, also, because Section's don't have a way to change the layout plugin configured, the patch is actually deleting the section and adding a new one (with the same components) using a different layout, so I could also see some data getting lost in that process too. If this is the problem, then this probably could be fixed somehow, by either adding to the API of Section or making sure to copy whatever the missing data is as well.

Also is it possible to somehow use that Panopoly patch without the Panopoly distribution?

With the patch as it is, no. But that patch could conceivably be made into a core patch rather than a Panopoly one, I'm just not sure if core would take it, since I don't know the long-term plan for Layout Builder's UI/UX.

Thanks again for testing!

Here's a new patch that adds a toggle link to switch between visual and non-visual mapping:

@dsnopek: Thanks alot for trying to reproduce those issues! Perhaps something else in my environment is the culprit. I'll try and isolate the problem and get back to you on those first few issues. Thanks so much for your work on this.

Regarding the Panopoly patch, would it perhaps be useful to integrate it into this patch that is in the works?: #3069446: Layout builder's "Add Block" sidebar menu UX improvements

Edit: I found this core issue that widens the off-canvas tray: #2951547: Modify Layout Builder's use of the off-canvas tray to improve UX of larger block forms. Perhaps it would be a good for your Panopoly changes.

Eager to try this out. I have been trying to look for something to replace the "editor workflow" that was easily done in the past with Panels/IPE where site admins could define a set of layouts that editors could use and then they could pick from a selection of blocks to add to this layout. People keep suggesting this is Layout Library; but it is not.

There are 2 issues with setting up what i had assumed was a typical editor use case. 1. Layout Library is a layouts per section; but obviously being able to add any number of sections breaks the idea of providing layouts per page (as would be the use case i am describing). I have found a couple modules now which limit adding sections; so yay!.

But after that.. I seem to be tied to the original defined layout for my 1 and only section. Possibly this patch offers the solution. :)

Per #3134371-11: Allow changing the layout of an existing section in Layout Builder UI, providing a well-needed issue summary update.

Fixed custom command failure.

Here's a patch that's attempting to get this passing on the current tests (its failing some "linter" checks). We still need some new tests for this functionality.

Let's try that again! Updating the non-ES6 version of the Javascript.

In trying to fix those last two patches for the linter, I actually broke the functionality of the patch! Here's a new patch that is working in my testing. I also modified the styles so it looks passable (but not great) with Olivero.

Unfortunately, this still isn't really usable with the default width of the tray. :-/ Unless we go with just the select dropdowns for mapping the regions?

Used wrong (duplicate) form id in the previous patches!

Hi @dsnopek, I have tested https://www.drupal.org/files/issues/2022-08-18/3134371-27.patch, and it's working fine, I have added screenshots.

Can move to RTBC!

Thanks,

Applied patch #27 on 9.5.x.The Change layout option is appearing after applying this patch and its working fine.

However there is no visible separation between the Configure Section and Change layout links.It would be better if there is some space between them.

Attaching screenshot for reference:

First of all, the patch #27 works great for me, amazing work!

I agree with others, that UI can be improved. Probably a follow-up issue can be opened to create a contextual drop-down menu for action-links "Configure section", "Change layout".

I created a merge request from @dsnopek’s patch in #27, feel free to pick it up.

The MR targets the 9.5.x branch for now, as the patch does not apply to 10.1.x-dev.

I have Fix CS error. Please review it

RE #37: we now have a MR and continued patching. Since we have a MR and fork for the issue (#36), please contribute there instead. Mixing up patches and MRs (for the sake of getting semi-automatic issue credit, for example) makes it harder to reconcile the two solution paths.

Attaching screenshot of how this would look like:

I agree with @dsnopek in #8 - I wouldn't expect this to be a separate action:

Also, I had the thought that maybe instead of adding this link, a user could first click the "Configure Section" link and then there could be a "Change layout" link or button on that form? That might be more understandable for users because the layout settings are already on the configure layout form.

From a site builder's or editor's perspective, the chosen layout is just part of how the section is configured. I'd expect to click "configure section" and have layout selection visible there, with the current layout highlighted. Selecting a different layout would produce the reassign form if needed (ideally via ajax in place) or change the layout immediately.

Contrib will inevitably want to add more options next to "configure", core should try not to bloat this out to begin with.

Re #36:

Probably a follow-up issue can be opened to create a contextual drop-down menu for action-links "Configure section", "Change layout".

It would be good to avoid adding more contextual dropdowns, they are a discovery barrier and everything winds up looking identical. There is an issue about this: #3042516: Re-evaluate whether Contextual Links are the best interaction for configuring/moving/deleting blocks in Layout Builder.

Re #43:

I'm adding a new wrapper for the links so we can use not(:first-child):not(:last-child)::after
This alters the form api structure, so might need a change record?

I don't think render element structure is considered part of the API, but I might be wrong. Could you use a:not(:first-of-type)::after and a:not(:last-of-type)::after ?

I agree a wrapper would be useful. There is an issue to add a twig template for the LB render element, which would at least make the structure more predictable/alterable. See #3373330: Provide twig template for layout builder render element and widgets.

I don't think render element structure is considered part of the API, but I might be wrong. Could you use a:not(:first-of-type)::after and a:not(:last-of-type)::after ?

I didn't know this existed, thanks!

I'll leave it with the wrapper for now and use :xxx-of-type based on feedback if needed.

I think we should try to come up with a solution that is as simple as possible for the site builders and content authors. The ideal UX would be one where site builders and content authors don't have to think too much about what happens when they change the section layout because it has been already figured out for them.

My understanding is that majority of Layout Builder users are mostly utilizing simple layouts (1-4 side by side columns). The current default settings seem to work fairly well in these cases. There's some optimization we could potentially make for use cases where sections get removed but IMO what's there now seems fine. We could consider adding an API for modules / themes to provide mappings between layouts for when the defaults don't make sense. However, I'm not sure we need to block this issue on that.

Based on this, I'm wondering, if we should leave the mapper UI to a follow-up or contrib? I would personally be more comfortable if we didn't do it as part of this issue.

Updated the issue summary to restrict the scope of this issue to only have the default region mapping and move the mapper UI to a separate issue [See #48].
Removed the Needs tests tag as the mapper UI testing isn't required anymore.

Tested on an Standard profile setup I had up.
Enabled layout builder for Article content type
It defaults to single column, verified the addition of the "Change layout" link
Clicking it I selected 2 columns
It created the 2 columns (yay) the 2nd column is empty.
I moved the tags field to the 2nd column
Changed back to 1 column and tags field moved to top of 1st column
Changed back to 2 columns and moved tag field over and it saved.

Created an Article filling in all fields but it did not render as 2 columns,
I see the markup is there but something was missing.

When I removed the MR, disabled layout builder, re-enabled, the page now renders as 2 columns.

Tagged for issue summary for the TBD sections to be filled in. Seems like a neat new feature for a CR.

Updated the issue summary and created a change record.
Also, I followed the same steps mentioned in #53 and the page renders as 2 columns with the MR applied as well. The modifications to the configuration are saved and rendered precisely on the nodes too.

Cleaning up patches and MRs for clarity.

I'm still encountering the issue, maybe this steps will help

Before applying the MR

Standard profile install
Enable layout builder
Enabled layout builder on Article content type
Apply MR and clear cache
See in layout builder that I can change layout.
So I changed to 2 columns moving the tags field to the 2nd column
Created an Article filling in all fields
The page does not render in 2 columns

Just tested this, @smustgrave are you keeping the first column empty? , I tried that and it does use the two column layout (you can see it if you inspect the page) but the second column is just offset by a little because of the empty first column which is by design.

I also saw weird behaviour when I rebased the MR

Before adding a comment field

After adding a comment field, the layout is disturbed completely.

Nope first column is the body field and second column tags field. Both I had values to

Hi,

Patch from MR 5526 did not apply anymore on core 10.3.1.

So I opened a new branch, rebased and created a new MR on 10.3 if people are interested.

Here is a patch file for Composer usage.

Unfortunately, patch from #62 does not apply on Drupal 10.3.2. I will try to investigate further shortly.

It turns out it's an issue with another patch of mine. Sorry for the noise.

This seems to be working fine, but the UI is very crude. It looks like https://www.drupal.org/project/lb_plus could provide an inpiration for this.

I have a question regarding this layout migration. I have changed the layout from A to B and node's layout is not changing where we have placed custom blocks.

Could someone help with this?

#64 -- 'a layout migration' ??

you're details are thin, however:
if you mean you've changed the base node type 'default layout' and have a node that already exists...you might need to edit that node and 'Revert to Defaults'

keep in mind, this is a feature request ticket, not a support ticket..

After applying the patch #62 with
"[3134371] Add option to edit section type from layout builder": "https://www.drupal.org/files/issues/2024-07-17/drupal-3134371-62.patch",

I've found this files:

docroot\core\b\core\modules\layout_builder\src\Controller\ChangeSectionLayoutController.php
docroot\core\b\core\modules\layout_builder\src\Form\ConfigureNewSectionLayoutForm.php
docroot\core\b\core\modules\layout_builder\src\Form\SectionFormBase.php

The are identical to:

docroot\core\modules\layout_builder\src\Controller\ChangeSectionLayoutController.php
docroot\core\modules\layout_builder\src\Form\ConfigureNewSectionLayoutForm.php
docroot\core\modules\layout_builder\src\Form\SectionFormBase.php

So it looks that patch is applying, but creates duplicates at docroot\core\b\core\modules\layout_builder