Add list view inspector tab for pattern editing #74574
Merged
+127
−102
Conversation
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
talldan
requested review from
andrewserong,
jasmussen,
mtias,
ramonjd and
youknowriad
talldan
added
[Type] Enhancement
talldan
commented
Jan 13, 2026
| ) } | ||
| <ContentTab contentClientIds={ contentClientIds } /> | ||
| <InspectorControls.Slot group="content" /> | ||
| <InspectorControls.Slot group="list" /> |
Contributor
Author
There was a problem hiding this comment.
It may have been for convenience, not sure, but the List tab was previously rendered as part of <StyleInspectorSlots>.
I've moved it out of that component to here, which feels like the right move to me.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
talldan
commented
Jan 13, 2026
| getMultiSelectedBlockClientIds().every( | ||
| ( id ) => getBlockName( id ) === name | ||
| ) ), | ||
| mayDisplayPatternEditingControls: false, // Section/pattern editing not yet supported on native |
Contributor
Author
There was a problem hiding this comment.
Claude did this, I don't know if it's the right move 🤷
Contributor
There was a problem hiding this comment.
Are these native files still in development? The last mobile-specific edit to this file was mid-2024.
Member
There was a problem hiding this comment.
I don't think native has had any content-only/pattern editing changes thus far? Might be wrong.
Contributor
Author
There was a problem hiding this comment.
I don't think so, so I can probably remove the changes. Last I remember the native code doesn't even compile, the CI tests are skipped.
talldan
commented
Jan 13, 2026
Comment on lines
+91
to
-102
| if ( hasContentTab ) { | ||
| tabs.push( TAB_CONTENT ); | ||
| } | ||
|
|
||
| // Add the tabs in the order that they will default to if available. | ||
| // List View > Content > Settings > Styles. | ||
| if ( hasListTab ) { | ||
| if ( hasListFills ) { | ||
| tabs.push( TAB_LIST_VIEW ); | ||
| } | ||
|
|
||
| if ( hasContentTab ) { | ||
| tabs.push( TAB_CONTENT ); | ||
| } | ||
|
|
Contributor
Author
There was a problem hiding this comment.
Reorders the tabs so the List Tab is after the Content tab, like the designs show.
talldan
commented
Jan 13, 2026
Comment on lines
+46
to
+48
| const shouldDisplayForPatternEditing = | ||
| context[ mayDisplayPatternEditingControlsKey ] && | ||
| ( group === 'list' || group === 'content' ); |
Contributor
Author
There was a problem hiding this comment.
Declares exactly which InspectorControls groups support pattern editing, otherwise the Settings tab shows in patterns as well.
talldan
commented
Jan 13, 2026
Comment on lines
+86
to
+78
| const attributes = useSelect( | ||
| ( select ) => select( blockEditorStore ).getBlockAttributes( clientId ), | ||
| [ clientId ] | ||
| ); |
Contributor
Author
There was a problem hiding this comment.
attributes isn't passed into the hook now that it doesn't use the BlockEdit filter, so have to select the values
talldan
commented
Jan 13, 2026
Comment on lines
+236
to
+216
| return ( | ||
| <InspectorControls group="content"> | ||
| <BlockFields | ||
| { ...props } | ||
| blockType={ blockType } | ||
| isCollapsed={ isSelectionWithinCurrentSection } | ||
| /> | ||
| </InspectorControls> | ||
| ); | ||
| } |
Contributor
Author
There was a problem hiding this comment.
This is quite a lot simpler now, we generally render the same thing regardless of whether in a pattern or not, the only difference is isCollapsed. 🎉
|
Size Change: +151 B (0%) Total Size: 3.06 MB
ℹ️ View Unchanged
|
talldan
commented
Jan 13, 2026
| edit: BlockFieldsPanel, | ||
| hasSupport: hasBlockFieldsSupport, | ||
| attributeKeys: [], | ||
| supportsPatternEditing: true, |
Contributor
Author
There was a problem hiding this comment.
supportsPatternEditing is a new thing, the block edit hooks are generally optimized to only work for single selected blocks. There needs to be a way to opt in to also showing the controls for blocks that aren't currently selected, as it the case with Pattern Editing.
talldan
commented
Jan 13, 2026
| return ( | ||
| <InspectorControls group="list"> | ||
| <PanelBody title={ null }> | ||
| <PanelBody title={ showBlockTitle ? blockTitle : undefined }> |
Contributor
Author
There was a problem hiding this comment.
Displays the block title if in a pattern and potentially showing multiple list views.
talldan
changed the title
Contributor
|
Just started testing this and spotted a couple of oddities.
If I have a couple Buttons blocks side by side, I can move Button blocks between them, but once one of them is empty I can't re-add anything to it: list_view.mp4It also feels a bit confusing to have the list view visible no matter which part of the pattern is selected, and always have all the list view eligible blocks all visible in there. Not just when having many blocks that render a list view in one pattern (which is unlikely to happen very often) but even if there's only one button, it's a bit weird for it to be called out in the sidebar like that when it's a very small element of the pattern: 
Other than that, it's working well! |
Contributor
tellthemachines
left a comment
tellthemachines
left a comment
There was a problem hiding this comment.
Just catching up with the current state of the inspector controls work and things seem to be moving pretty fast so I mostly have questions at this point 😅
| getMultiSelectedBlockClientIds().every( | ||
| ( id ) => getBlockName( id ) === name | ||
| ) ), | ||
| mayDisplayPatternEditingControls: false, // Section/pattern editing not yet supported on native |
Contributor
There was a problem hiding this comment.
Are these native files still in development? The last mobile-specific edit to this file was mid-2024.
| export const mayDisplayControlsKey = Symbol( 'mayDisplayControls' ); | ||
| export const mayDisplayParentControlsKey = Symbol( 'mayDisplayParentControls' ); | ||
| export const mayDisplayPatternEditingControlsKey = Symbol( | ||
| 'mayDisplayPatternEditingControls' |
Contributor
There was a problem hiding this comment.
I'm almost certainly missing context here 😅 but my reading of #73845 points to all attribute types (so presumably all the inspector tabs they live in) being displayed in regular (or "design") editing mode? If that's the goal, maybe we don't need this check?
If it does turn out to be needed though, considering that contentOnly mode (not sure if we're still calling it that?) could in future be extended to other places than patterns, it might be good to use a less specific name for this Symbol such as mayDisplayContentEditingControlsKey.
Contributor
Author
There was a problem hiding this comment.
Yeah, I'm not sure. Showing Settings for patterns would be a lot. It'd include all of those Advanced panels.
If you're right then there's a chance it can be simplified.
Contributor
There was a problem hiding this comment.
My read was all tabs would be available when not in contentOnly; that would just mean we would always show content/list view. I don't think the settings should be visible in contentOnly.
Contributor
Author
There was a problem hiding this comment.
Yeah, they are visible when not in contentOnly.
Example for the List Block:
Kapture.2026-01-14.at.12.59.53.mp4
Member
|
Also working pretty well for me. 🚀 What's expected for the Page List block in the Nav? Links show up in the inspector, but if the nav contains only pages, the content pane can be blank. 
|
Contributor
Author
I guess we shouldn't show the content tab in the situation there's no content. Or show a message. I'll look into it. |
Contributor
Author
Hmm, yeah, looks like same happens for nested/indented lists. 😱 I guess we need to figure out how to only show the top level block that has a list view.
I'll look into that, not sure why it doesn't show the appender.
It's consistent with the way 'Content' works at least 😄 . Otherwise users are required to hunt for the blocks to select in the pattern, which I'm not sure is better, it's what the experience is trying to avoid. Maybe there's another option that balances the two. I think also related is the point mentioned in the PR description about whether the lists should have some kind of drill-down like they do normally. |
Contributor
|
Impressive work, this is working well for me. Before:
After:
Noting that it is intentionally not applied to the gallery quite yet, just validating that's correct. Since this is already in place for the Navigation block, it feels sensible to extend it also to these other blocks. There's something about the Contents tab and Media, but I picture that's not part of this PR. The one thing that stands out in testing this, but which is an enhancement idea that should not block other work, is the list view: 
For navigatiom items, we show the content instead of the title of the block: 
We do that for headings in the list view as well, if not paragraphs: 
But with a List container that has a generic name, it might be nice to show the contents as the title, like we do for headings and menu items. Another thing to consider, especially for very tall patterns: should we do some scrolling to where an action takes place? Probably something to mull over before reacting since it's arguably an edgecase. But if you can see a navigation list in the inspector, and you start interacting with it, should the page scroll to where on the page that interaction is visible? |
…ols context value
…PatternEditingControls
talldan
force-pushed
the
add/list-view-tab-for-pattern-editing
branch
from
6582699 to
ea030e6
Compare
Contributor
Author
I've pushed a fix for this. I think it can basically happen whenever there are no block fields, there's some logic that still shows the content tab. |
Contributor
Author
Also fixed this issue, only the top level list views are now shown nested ones are ignored: |
6 tasks
Contributor
Author
This one seems like a smaller issue for users and a List View problem, so I've made a separate issue for it -
I'll handle this one as a follow-up. |
Member
Nice. Tests well for me, thank you! Kapture.2026-01-15.at.16.01.29.mp4
Looks good in my testing too: 
|
ramonjd
approved these changes
Jan 15, 2026
Member
ramonjd
left a comment
ramonjd
left a comment
There was a problem hiding this comment.
This is testing well for me. Tentative ✅ until other folks retest based on their feedback.
I checked with and without the experiments on - it's gated so safe for follow ups I think.
Cheers!
6 tasks
This was referenced Jan 23, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What?
Closes #74567 - Displays the List inspector tab for Pattern Editing when a section is selected.
One caveat with this PR - when in a pattern and selecting a block from the List tab it doesn't drill down into that block like it does normally. Should it? I'm not sure, as if a child block can be selected it takes the user out of the 'pattern editing' experience. At the very least the user would need an affordance to re-select the main pattern.
How?
Technically, I think this PR moves much closer to what's described in the Block Attribute groups issue, where blocks don't have to do anything special to work with patterns, the editor controls showing the Inspector items in the correct way whether the block is within a pattern or not.
To accomplish that I've removed a previous
forceDisplayControlshack for the InspectorControlFill, and now the editor uses amayDisplayPatternEditingControlscontext value to let the Inspector Controls know whether it should render.A similar approach is used for block hooks too.
As part of this I've also ported
BlockFieldsto a block hook, and simplified it quite a bit. (I could probably move this into a separate PR, but it's dependent on this one).Testing Instructions
Prerequisite: Enable the Pattern Editing and BlockFields experiments
Screenshots or screencast