Experiment: Make unsynced patterns content only by default #71512
Conversation
talldan
added
[Type] Experimental
talldan
requested review from
andrewserong,
draganescu,
getdave,
jasmussen,
jeryj,
mtias,
ramonjd,
richtabor,
scruffian,
tellthemachines and
youknowriad
|
Size Change: +164 B (+0.01%) Total Size: 1.94 MB
ℹ️ View Unchanged
|
|
Just did a quick test of this! It does feel nice when it works: just dropping some patterns in a template and changing text/images is quick and easy. It doesn't work consistently though. Not all patterns have 
is just a couple Media and text blocks in a trench coat 😅 I also notice a difference between theme defined and user-created unsynced patterns (both having 
vs theme-created where none of the options are available and it's not possible to add new blocks: 
|
It looks like that one doesn't have a single wrapping block, it's made up of two blocks at the root level. This approach definitely won't work so well for those kind of patterns. The |
Yeah, I'm not actually sure how the We may have to move to the former approach to make this work. cc @scruffian @getdave @jeryj for thoughts. |
|
I've pushed a commit that makes these |
|
Thanks for helping to progress/evaludate this idea, Dan!
I just snooped around for my own benefit, because I was also wondering if the same treatment should be given to user-created patterns. For theme patterns, the name and other metadata does exist in the pattern object itself and returned in the response. Looks like the metadata is added in parsePattern, used by the |
This improves things as it also removes most of the styles and settings from the sidebar. We'll probably need to adjust the block toolbars so the section containers show the styles toggle: 
|
|
Quick GIF showing building a simple about page using patterns:
This feels ergonomic, and more intuitive than I expected it to. Even the absence of the inverted toolbar to indicate "this is different" does not feel surprising. By opening the patterns tab and building with patterns, it feels completely reasonable to work on the section level in this more curated experience. Nice work. I'm curious what you and others think about adding an "Edit contents" button to the inspector: 
Related to that, potentially that same Edit contents toolbar can become the same button that exists there in the inspector for patterns and synced patterns, which beckons us to also consider the toolbar button: No strong opinion on what the label should be, but there may be a nice opportunity to ensure all 4 buttons (toolbar + inspector for both synced and unsynced patterns) are the same, may be a nice bit of coherence. I vaguely recall the addition of this badge to indicate the block type used for the pattern container: 
—but reflecting on it, it doesn't seem useful to have this. Not an action item here, but as far as refining the flow, potentially a piece to polish. |
talldan
force-pushed
the
refactor/template-lock-block-editing-modes-to-reducer
branch
from
516ead0 to
e32f963
Compare
talldan
force-pushed
the
try/content-only-patterns-by-default
branch
from
e2e54da to
fff584d
Compare
|
Flaky tests detected in 5440ea5. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17606011427
|
talldan
force-pushed
the
try/content-only-patterns-by-default
branch
from
582551c to
67f55a1
Compare
|
I’ve added a little TODO list to this PR description. I’ll probably start looking at this one next - “Add contentOnly mode to unsynced patterns more reliably via the patternName attribute (e.g. user created patterns as well as bundled patterns)” |
|
I've been testing this a bit further to try to work out the difference between user created and theme patterns and I realised that in my previous testing the user created pattern had less nesting layers than the theme ones, and that was why I was able to add blocks to it. If there's a content block at the root level of a theme created pattern, it will also be possible to add blocks to it. Not sure if this is desirable 😅 Another thing I noticed is that the |
It shouldn't require write mode, the write mode experiment can be turned off (or left on, it's up to you). |
tellthemachines
left a comment
tellthemachines
left a comment
There was a problem hiding this comment.
This is looking good! Aside from the comments below, there's only a couple of things we're missing:
- add a toolbar button to make the pattern fully editable (ideally toggle between modes)
- remove stuff we shouldn't be able to do from the options menu (for instance "ungroup" makes it not a pattern anymore, and can substantially change the layout):
| } ) | ||
| ? ( blocks ?? [] ).map( ( block ) => | ||
| cloneBlock( block ) | ||
| ) |
There was a problem hiding this comment.
This is working well now!
One thing that would also be good to fix is having theme patterns appear in the slash inserter; currently they don't. But that can be addressed separately!
There was a problem hiding this comment.
Yep, lets treat is as separate, I'm not sure if there's a reason they're omitted.
If we can include them I think it would help tidy up some of the Inserter code.
packages/block-editor/src/components/block-variation-transforms/index.js
Outdated
Show resolved
Hide resolved
| }; | ||
|
|
||
| if ( ! variations?.length || isContentOnly ) { | ||
| const hideVariationsForSections = |
There was a problem hiding this comment.
Is this supposed to hide the transforms menu? It's still there and usable:
There was a problem hiding this comment.
It hides the variations on the block card for groups. Only remembered this one is still there after doing it 😄 .
There was a problem hiding this comment.
Pushed a commit that should address this.
…ocking Move contentOnly template locking code from selector to reducer Simplify getBlockEditingMode tests and add additional cases Remove unused dependencies WIP
talldan
force-pushed
the
try/content-only-patterns-by-default
branch
from
5440ea5 to
73b967f
Compare
aaronrobertshaw
left a comment
aaronrobertshaw
left a comment
There was a problem hiding this comment.
Nice work on this @talldan 👍
In the block editor this is testing really well for me.
✅ Inserting a pattern works as expected
✅ Inserted user patterns default to simplified content only mode editing
✅ Non-content blocks aren't selectable via the canvas
✅ Only content editable blocks are shown in the List View or Block Inspector controls
✅ Transforms menu is correctly hidden
✅ Continues to function as per trunk when experiment is not opted into
As @scruffian noted there appear to be a few issues in the site editor at the moment.
- When first inserting a pattern, clicking on the content does not allow it to be edited
- Opening the List View, the pattern does not appear to have any selectable inner blocks
- Opening the Block Inspector shows no controls to select editable content in the pattern either
- Dragging and dropping the pattern elsewhere in the block hierarchy appears to trigger the pattern's blocks to be recreated so they show and are now editable
- Stopping editing the page, then clicking on the editor canvas again also results in the pattern functioning as it does in the block editor
Here's a quick glimpse of what I was seeing while fumbling around testing this PR:
Screen.Recording.2025-09-10.at.7.19.33.pm.mp4
With these changes behind the experiment, I think this PR is good to merge and address the noted site editor issues in a follow up. I've confirmed that without the experiment enabled, the site editor functions as per trunk. |
andrewserong
left a comment
andrewserong
left a comment
There was a problem hiding this comment.
I like the direction of this, too, and with other PRs exploring subsequent changes that depend on this experiment, I reckon merging and iterating behind the flag is a good way to go 👍
LGTM
| ); | ||
| return category ? category.slug : catId; | ||
| } ), | ||
| content: userPattern.content.raw, |
There was a problem hiding this comment.
Tiniest of nits, but will content always be truthy? In getInserterItems (before this PR) the accessing of both content and title use optional chaining, whereas this function doesn't.
There was a problem hiding this comment.
Yeah, it's interesting. Does it mean there are patterns without a title or content?
I added the optional chaining anyway to be safe 😅
…#71512) * Update derived block editing modes to support content only template locking Move contentOnly template locking code from selector to reducer Simplify getBlockEditingMode tests and add additional cases Remove unused dependencies WIP * Fix `getEnabledBlockParents` test * Make unsynced patterns contentOnly by default * Consider blocks with `patternName` as sections * Fix failing test by adding some back compat * Guard behind an experiment * Insert parsed patterns via the slash inserter * Fix test * Hide variation selector for section blocks * Show shuffle styles for any section in any mode * Use experiment flag for a couple of changes * Combine select calls * Hide transforms for sections when experiment is active * Optional chain pattern properties --------- Co-authored-by: talldan <talldanwp@git.wordpress.org> Co-authored-by: andrewserong <andrewserong@git.wordpress.org> Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org> Co-authored-by: aaronrobertshaw <aaronrobertshaw@git.wordpress.org> Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: jasmussen <joen@git.wordpress.org> Co-authored-by: scruffian <scruffian@git.wordpress.org>
| _isSingleBlockSelected && isTemplatePart( _blocks[ 0 ] ), | ||
| hasContentOnlyLocking: _hasTemplateLock, | ||
| isDisabled: editingMode !== 'default', | ||
| isSection: isSectionBlock( clientIds[ 0 ] ), |
There was a problem hiding this comment.
Do we need to check for multi-selection? Maybe it should use the same condition as the template and synced pattern.
There was a problem hiding this comment.
Oooh! Maybe yes 😄
Maybe it should use the same condition as the template and synced pattern.
Which condition is that?
A bit related, but another thing I noticed while testing was that the inspector sidebar also shows default controls when several patterns are selected.
There was a problem hiding this comment.
Trying to address this here:
There was a problem hiding this comment.
This condition - _isSingleBlockSelected && isTemplatePart( _blocks[ 0 ] ).
Current logic will return true if the first block in the multi-selection is a section block. Not sure if that's the result we want.
There was a problem hiding this comment.
I think #71708 should take care of this since it turns off block switching in a multi-selection if any block is a section.
What?
Part of #71517
Fixes #71552
Tests out an idea of making all unsynced patterns
contentOnlywhen inserted.At the moment this is missing some niceties, like being able to 'unlock' the pattern to edit it fully. The PR is just to see how it feels, but I'd welcome anyone to add commits with additional features.
How?
this PR is based on Refactor: Content only template locking block editing modes to reducer, which makes it much easier to implement.
When a block has a
metadata.patternNameattribute it'll be given the sameblockEditingModesas a block that hastemplateLock: contentOnly.Todo
patternNameattribute (e.g. add it to user created patterns, check that it works for patterns that are included in templates by the theme, as well as bundled patterns)Testing Instructions
First, enable the experiment in Gutenberg's experiment settings page:
Screenshots or screencast
Kapture.2025-09-05.at.11.54.45.mp4