Pattern Editing: Nest content groups and make them selectable to reorder - #82550
Draft
fabiankaegy wants to merge 3 commits into
Draft
fabiankaegy wants to merge 3 commits into
fabiankaegy wants to merge 3 commits into
Conversation
Lets a named container inside another named container become a group of its
own, so a named card inside a named grid keeps both rows instead of only the
outermost one. The previous top-most-only rule made a nested name a silent
no-op, which read as the feature being broken rather than deliberately capped.
Nesting mirrors the markup the author wrote: a container only becomes a row by
being named, so the result is as deep as the author asked for rather than as
deep as the block tree.
Because groups nest, a bare "Premium" heading no longer identifies a group on
its own — two cards under different parents can share a name. Headings are now
built from the whole group path ("Pricing table / Premium"), which also removes
the duplicated heading markup and styles that the content panel and the block
fields panel each carried.
Group membership reads `metadata.name`, and the List View tree must not depend
on `state.blocks.attributes` to see it: that map is replaced on every attribute
change, so depending on it rebuilds the tree on every keystroke. Trunk guards
against this with `getListViewClientIdsTree`'s referential-stability test. A
`blockMetadataRevision` reducer counts only the attribute updates that touch
`metadata`, mirroring how `patternName` is already handled, and the tree and
group selectors depend on that instead.
🤖 PR meta 🤖🏷️ LabelsThis pull request needs exactly one label indicating its type, and has 0.
Read more about Type labels in Gutenberg. If you cannot add labels yourself, a reviewer can do it for you. 📦 Bundle sizeSize Change: +335 B (0%) Total Size: 8 MB 📦 View Changed
⚡ PerformanceShow the resultsClient side metrics exclude the server response time. front-end-block-theme
front-end-classic-theme
media-processing
media-upload
post-editor
site-editor
|
fabiankaegy
force-pushed
the
add/pattern-grouping-nesting-and-reordering
branch
from
September 7, 2026 15:34
6a37f8f to
1497cc3
Compare
Makes a grouping row something you can act on. Reviewers of #79483 all reached for the same thing first — dragging a pricing card into the middle — and found a row that could be focused but did nothing, which read as broken rather than as restrained. A grouping row is selectable, and selecting it gives the ordinary block toolbar, whose mover is what reorders the group among its siblings. That also answers the objection that an unselectable row breaks List View's heuristic that every row is selectable: rather than making the row a special case, it gives selection something to do. Grouping rows and the faded out-of-section context rows are both disabled, but they are not the same kind of row, and until now they shared one treatment. A context row sits outside the pattern being edited and is genuinely inert. A grouping row sits inside it and holds no content of its own, but it is a real target: selectable, expandable, movable. `isFadedContext` now carries the inert treatment and grouping rows opt out of it. Three gates stood between selection and a working mover: - `canMoveBlock` refuses the move twice over: a container is not a content block, and the parent it sits in is disabled. Both rules exist to stop editors restructuring a pattern's design, but reordering named siblings is the restructuring the pattern author opted into by naming them, so named grouping rows are carved out. The carve-out permits a reorder and nothing more: every lock that could forbid the move — preview mode, static inner content, `lock.move`, a `templateLock` of 'all' — is applied before it, and `moveBlocksToPosition` only skips its remove and insert checks when the move stays inside the same parent, so a group cannot be lifted out of its pattern. - `useHasBlockToolbar` renders no toolbar at all for a disabled block, so there was nothing to reorder from. Content groups are carved out. - `BlockSettingsDropdown` would then have offered Paste styles, Lock and Hide, which would make reordering a way around the design lock. It already restricts itself for content-only blocks, so grouping rows take the same restriction. The menu is left with nothing and so does not render. The resulting toolbar is the block icon, the parent selector, and drag plus movers — no design controls, because those are gated on the default editing mode, which a grouping row does not have. Because a grouping row is now actionable, it is no longer announced as disabled, so the e2e assertion added with the base branch is inverted. Also fixes the base branch's e2e test, which asserted that content blocks are visible in List View without expanding the grouping row that now sits above them. Introducing that row put the content a level deeper, so the assertion could not pass; it fails on the base branch too. Duplicate and remove are deliberately left out. They raise the question of what an appender inserts once every card is gone, which is worth settling separately.
fabiankaegy
force-pushed
the
add/pattern-grouping-nesting-and-reordering
branch
from
September 7, 2026 17:09
1497cc3 to
acffbe8
Compare
fabiankaegy
changed the title
The toolbar movers reorder a grouping row, but the drag handle beside them does nothing. Dragging needs a drop zone on the container the group sits in, and that container is disabled, so `useInnerBlocksProps` gives it none. The drag starts — the store reports the group as being dragged — but no drop target is ever computed, so the drop is a no-op. Enabling the container's drop zone is not a one-line change. Doing it from the block's own `isDropZoneDisabled` flag is too late, because that flag is what attaches the listeners and it would have to flip mid-drag; doing it statically attaches the zone but still produced no drop indicator, so something further down declines the target. List View dragging is a third path again, through `useListViewDropZone`. Rather than ship a handle that looks like it works, hide it for grouping rows so the movers are the only reorder affordance on offer. Reinstating it is a follow-up, and the e2e test asserts its absence so that reinstating it has to be deliberate.
Member
|
Thanks for moving this topic forward. I only smoke tested and reordering and grouping appears to be working well. Nice! What's required here as the first step. I assume getting #79483 ready for re-testing and merge? Maybe now is the time so there's plenty of time for testing before 7.2. I'm not sure how much bandwidth folks have at the moment to carry it forward, but we can help test and review. |
Contributor
|
Thanks for continuing to build on this. These giant AI generated PR descriptions are really challenging to review. Screenshots or videos go a long way to helping, so I'd appreciate if you could add some. I probably won't look at this PR until that gets sorted. |
Member
Author
|
@talldan yeah sorry about this. I had added: Caution THIS IS AN EARLY DRAFT AND NOT READY FOR REVIEW YET to the top of the PR description but then an update overwrote it and I didn't notice 🤦 Will ping you if and when this ever becomes ready :) |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Caution
THIS IS AN EARLY DRAFT AND NOT READY FOR REVIEW YET
Important
Stacked PR. Base is
add/pattern-grouping-using-names-rebased— @talldan's #79483 replayed onto trunk — so this diff is only the work on top.What?
Named containers inside a pattern now nest, and a grouping row can be selected and reordered. Refs #75463.
Why?
Naming a nested container was a silent no-op, and a grouping row could be focused but not acted on.
How?
Pricing table / Premium).canMoveBlock,useHasBlockToolbarandBlockSettingsDropdowneach carve out grouping rows — the last so reordering cannot also restyle or unlock.metadata.nameis read via a newblockMetadataRevisionreducer, so List View is not rebuilt per keystroke.Testing Instructions
Pricing table / Lite.Pattern markup
Edge cases — deeply nested
The block names say what each case is.
Design onlyandEmptyshould not become rows; the rest should.Screenshots or screencast
Same pattern and post in both.
A selected grouping row gets the movers and nothing else:
Open questions
Duplicate/Removeare suppressed by the content-only restriction. Add them back?Use of AI Tools
Written with Claude Code; I reviewed it.