[PP-1] Reorder Layout Builder sections

Thanks, For having this issue and patch.
Noted, that the patch is not applying to the 10.0.x branch

Updated patch for 10.1.x.

@alexahumada can you please provide an interdiff and how the previous patch no longer applies per the new policy. But definitely an interdiff as the file size goes up from the previous patch of #71

Also per #90 there are still some remaining tasks.

Hi @smustgrave,

sorry i forgot about the new interdiff policy.

The new patch can't be applied to Drupal 10 becouse some changes in code in 10.0.x and 10.1.x branches, notably some css classes present in #71 patch have been removed. Also, notable difference in size is caused by Drupal 10 using PostCSS to transpile pcss files to css using yarn → , which require changes to new .pcss.css files.

I'll try to work on the remaining task we have in #77 and #85, but sadly this new patch only addresses Drupal 10 compatibility.

The patch from #72 still applies to D11, yay!

Updated the patch to fix the CCF and updated the tests since they were failing.

Setting to needs review, if tests come back green I'll jump onto IS and the CR.

I've put #100 in https://git.drupalcode.org/project/drupal/-/merge_requests/4075

Let's make our lives better with MR

Could issue summary and follow up tags be removed based on #86.

Also the change record?

Think the MR failures are random so running the tests again.

Updated the IS to add some screenshots of the functionality.

Added a draft CR. Happy for review and more information added as needed.

Thanks for the quick updates.

Tested out a little by adding 3 sections.
The reorder work but noticed something weird
If I change the sections to say 3,1,2 it renames the sections to 1,2,3.
It moves the content in the blocks correctly but was a little confusing.

Is that desired behavior?

Personally I would find it more confusing if sections were arbitrarily numbered based on their starting position rather than sequentially down the page.

So is more about bulk moving blocks vs sections right? Since the sections rename

Not necessarily, sections can have different layouts/number of columns. But if you think of a section as a 'group of blocks' then sure, it's about moving the blocks (but also the layout containing them).

The default 'Section #' only appears if a section lacks a user-provided label. I think it makes sense to keep them numbered based on how they are stacked on the page at the time you are re-ordering sections, otherwise it becomes a meaningless label.

One option might be to make clearer these are automatically named because they have no label (e.g. 'Unnamed Section #'), but I realize the Layout tray width is troublesome.

I think it makes sense to keep them numbered based on how they are stacked on the page at the time you are re-ordering sections, otherwise it becomes a meaningless label.

I agree with this

CR looks good
MR tests are passing

Someone please assign the issue to me once this is implemented so I can provide the subsystem maintainer signoff.

from #77

Will take a look either tomorrow or at DrupalCon

Setting back to NR for @tim.plunkett to give his thoughts as subsystem maintainer

I've updated the MR to address the first of the remaining tasks: Moving the Reorder trigger so it's inline along with the Remove and Configure triggers for each section.

• Removed action from Default and Overrides entity forms
• Added action to each section via the Layout Builder element
• Added minimal CSS to separate links

I started to take a look at the 2nd task, highlighting the section in the off-canvas tabledrag now that we know which section the request was called from. In the Move Blocks UI, the block is identified by its UUID. Layout sections do not have UUIDs (see ✨ Add UUID to sections Needs work ). If the section does not have a label, the only way to distinguish it is by its delta. Is a highlight going to be doable with just the delta?

Maybe this is blocked by ✨ Add UUID to sections Needs work

looking at this again I feel like it should be postponed on ✨ Add UUID to sections Needs work but if anyone disagrees please put back to NR.

Sounds right to me, let's make it official

Re-roll of #100 for 10.3.0 (moved links to traits)

Re-roll provided on #121 worked for me. Thanks :))

I also confirm: patch #121 works correctly. Thank you.

Why don't we include this version & iterate when uuids are ready? not sure why that suposes a blocking change for this...
No clear reason given when changed to postponed

@CRZDEV the reason is that this is a core issue so it needs to pass through all of the core gates → , which is a valuable though time-consuming process. As our core committers are incredibly busy administering the project as well as managing their dayjobs, half-measures don't get committed to core if there is a plan for a better way to achieve the same outcome. The community just doesn't have the resources to open that Pandora's box :)

Typically projects use a patch until the issue gets committed, and the community is pretty good at sharing updated patches.

@darvanen Understood, thanks!