contentOnly Patterns experiment: Add content only support again for template parts #73419
+68 −18
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, ramonjd and tellthemachines 
| Size Change: +154 B (+0.01%) Total Size: 2.54 MB
ℹ️ View Unchanged
|
| Flaky tests detected in 5b8af6f. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/19489656313
|
Contributor Author
| Something else I think this surfaces is that we should look into adding support in the inspector fields for blocks like Site title/logo/tagline. Those are tricky as they edit entities and not attributes. I think we're now feeling the pain of not having updated these blocks to use bindings. Made an issue for it here - contentOnly pattern experiment: add inspector 'fields' support for blocks like Site Tagline, Site Logo etc. |
| 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. |
Contributor
Oh, thank you! I was just going to mention that as the main drawback of enabling this for template parts right now. So not a criticism of this PR, just that it highlights that we do need to support those blocks, as you mention. |
Contributor
There was a problem hiding this comment.
Thanks for revisiting the behaviour for template parts!
Not necessarily a blocker for this PR, but when we active editing the template part, I wonder why we can't access the list of alternate designs. Is it a similar issue to the one where the block icon shows when we don't expect it? This is the control I mean:
Other than that, and that we don't have contentOnly support for entity-based blocks like Site Title and Site Logo, this is testing pretty well for me and the code looks good:
2025-11-19.15.50.26.mp4
Keen to hear what @jasmussen thinks of merging and iterating?
Contributor
| Took this for a quick spin. At a glance, it worked almost exactly as I would expect, given a unification towards the spotlight-powered focus mode. Andrew makes a good point here:
Not a blocker, but we need a plan for this, because this was one of the most wonderful aspects of template part editing before, the extremely trivial discovery of transforms. If you'll excuse what is most likely a technically slightly illiterate question, can we do either of the following? Show the transforms for the inner-root block here:  Show the transforms for the "unlocked" pattern, the root block/pattern, here: Both have the space for it, so it's mostly the code feasibility I assume. Also a casual CC: to @jameskoster and @fcoveram just for awareness around the spotlight focus unification. I believe they are supportive as well. |
Contributor
| Another thought: now that we unify the "Edit" toolbar button with the "Edit section" button in the inspector, should we also unify the labels? I realize "Edit section" followed by "Edit navigation" may make for a long block toolbar. But it may be worth trying, it may just fit, even on smaller devices. Speaking of, here's "Edit navigation" with a "locked" template part:
Here it is, "unlocked":
This is probably a separate conversation that deserves feedback by @getdave and others, but the main question to ask here is whether the same button should do different things depending on lock or unlock state. I'm leaning towards no, because in the contentOnly locked template part, clicking "Edit navigation" only selects the navigation block inside, whereas its goal really was to jump right to the list-view-esque sorting mechanism. |
Contributor
| Thanks for the ping Joen. It will be great to have a more unified experience here so it's good to see this PR.
Important context here is that we identified through user testing that it was particularly important to have users able to jump straight to editing their Navigation Menu from the template part itself. This was becayse users find it difficult to identify where to edit Navigation Menus so the more signposting we can do the better. The
Agreed. The objective is to provide users with a simple yet effective mechanism to edit and manage their Navigation Menu. This goes beyond updating links or labels as the Editable List View allows for:
@jeryj is looking at this as part of #73042 so I'll invite him to leave his thoughts here too. |
talldan commented Nov 20, 2025
Comment on lines -86 to +87
| const { getBlockRootClientId, getPatternsByBlockTypes } = | ||
| select( blockEditorStore ); | ||
| const rootClientId = getBlockRootClientId( clientId ); | ||
| return getPatternsByBlockTypes( blockNameWithArea, rootClientId ); | ||
| const { getPatternsByBlockTypes } = select( blockEditorStore ); | ||
| return getPatternsByBlockTypes( blockNameWithArea, clientId ); |
Contributor Author
There was a problem hiding this comment.
This change fixes visibility of the 'Design' panel that allows switching between patterns.
The issue was that it was using the rootClientId, so checking which patterns can be inserted into the parent of the template part. This template part's parent is disabled with the new spotlight mode, so blocks can't be inserted there. It didn't look correct to me, as the pattern is inserted into the template part itself, so I've changed it to use clientId.
andrewserong approved these changes Nov 20, 2025
Contributor
andrewserong left a comment
andrewserong left a comment There was a problem hiding this comment.
Working nicely now, and yes since the template part is updating attributes on the template part instead of replacing itself as a block, checking against the client id rather than the root client id makes sense to me 👍
Testing well with the experiment switched on and off, but here's what it looks like with the experiment on:
2025-11-20.12.42.57.mp4
LGTM!
Contributor Author
| Thanks, I've also updated the copy of the toolbar button to 'Edit section', I think looks good: Lets iterate on the Edit navigation part. I wasn't sure of the feedback. I'm happy to make another PR if it can be clarified - are we saying 'Edit navigation' could invoke the spotlight editing mode? |
talldan deleted the update/add-content-only-support-again-for-template-parts branch 
Member
| Nice work here - thanks for reaching a compromise |
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?
Revisits #73332 to see if we can incorprate template parts into the experiment again
Why?
The idea is to achieve consistent behavior across any blocks considered 'sections'. I think it's worth trying this so at least we get some feedback about whether it's good / ok / terrible.
Also, by incorporating template parts, whatever improvements we make are required to work well for template parts too, so it means we're required to consider the breadth of the problem.
How?
Changes the behavior of the template part 'Edit' toolbar button to also initiate the spotlight style inline editing.
With #73268 now merged, users can also double-click, which works I've found to be a very natural interaction once you discover it.
I don't think the button implementation is perfect though, as the button has to toggle between 'Edit' and 'Exit', and users will need to reselect the template part to get back to the 'Exit' button (or they can also click outside / press 'Escape'):
Kapture.2025-11-19.at.12.04.21.mp4
Maybe this is something we can continue to iterate on as part of #73126. We might try some of the ideas around surfacing the interaction in the editor document bar.
I think we could also consider keeping the old 'Edit' action in the block settings menu. Perhaps 'Open in new editor' is a good way to phrase it? It'd be great to get thoughts on that.
Testing Instructions
Also worth testing - check that template parts work as they do normally with the experiment inactive.