You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Starter patterns should show content only in preview #75679
Currently when creating a starter pattern, you have two options. Either create a starter pattern with content added which makes the preview look nice but then requires the user to remove that content to start editing, or you can create a pattern without content and then the preview looks terrible.
As shown in the example above, it's difficult to tell what the pattern looks like because there's no content and it's filled with placeholders.
What is your proposed solution?
I think it would be good to get a PHP function like is_pattern_preview() which allows patterns to specify different markup only for the preview.
An example of the code could look like this:
<?php/** * Title: Test pattern with preview content * Slug: holburne/pattern-preview-content * Categories: starter-templates * Inserter: yes * Block Types: core/post-content * Post Types: page */$is_preview = is_pattern_preview();
?>
<!-- wp:paragraph -->
<p><?phpechoesc_html( $is_preview ? 'This is a preview' : '' ); ?></p>
<!-- /wp:paragraph -->
<?php/** * Title: Test pattern with preview content * Slug: holburne/pattern-preview-content * Categories: starter-templates * Inserter: yes * Block Types: core/post-content * Post Types: page */$is_preview = is_pattern_preview();
if ($is_preview) :
echo <img src="some-custom-image" />
else :
// The pattern hereendif;
Alternatively, you could have a header such as "Use Examples In Preview" which uses a blocks example content instead of the raw actual content of the pattern, however you'd have to merge the content/attributes of the block in the pattern on top of the example as any change to e.g. className would break the styling of the pattern itself.
Good issue. Pre-filling a pattern is probably the best option there is today.
Blocks have an example, so another option is to allow something like this for patterns. That looks like what #28135 suggests as well.
If there is a solution to this, it might also be good to consider whether a solution is possible for user created patterns which are stored as a custom post type.
A completely separate idea would be to offer a way to 'clear' all the content in a pattern back to the default block values.
A few things I'd love your thoughts on before I start:
Is a global flag + function the right API surface, or would you prefer something like a filter or a block context approach?
For the JS side, should I fetch preview patterns separately (context=preview), or would it be better to return a preview_content field alongside the regular content in a single request (to avoid a double fetch)?
Is lib/compat/wordpress-6.9/ the right place for the new compat files, or is there a different target version I should use?
Blocks have an example, so another option is to allow something like this for patterns
I feel like this is harder to create for a pattern than a block. A block is a specific thing with attributes and inner blocks itself, where as a pattern on its own doesn't have that, it relies completely on the blocks it's made of. That being said maybe there is a nice DX here I'm not seeing.
It might also be good to consider whether a solution is possible for user created patterns which are stored as a custom post type.
I think a context of preview makes perfect sense and a preview window is a different context than editing, however if view isn't currently being used other than preview, perhaps we could just use that to keep the view/edit paradigm we already have for other things in the REST API.
Activity
talldan commentedon Feb 19, 2026
Good issue. Pre-filling a pattern is probably the best option there is today.
Blocks have an
example, so another option is to allow something like this for patterns. That looks like what #28135 suggests as well.If there is a solution to this, it might also be good to consider whether a solution is possible for user created patterns which are stored as a custom post type.
A completely separate idea would be to offer a way to 'clear' all the content in a pattern back to the default block values.
ashutoshgautams commentedon Feb 19, 2026
What do you think about this approach?
is_pattern_preview()global PHP function that pattern authors can call inside their pattern filescontextquery parameter (view|preview)context=previewis passed, set a global flag before pattern PHP files are executed, sois_pattern_preview()returnstruecontext=previewwhen fetching patterns for the inserter/pattern explorerA usage example in a pattern file would look like:
A few things I'd love your thoughts on before I start:
context=preview), or would it be better to return apreview_contentfield alongside the regularcontentin a single request (to avoid a double fetch)?lib/compat/wordpress-6.9/the right place for the new compat files, or is there a different target version I should use?mikeybinns commentedon Feb 19, 2026
@talldan
I feel like this is harder to create for a pattern than a block. A block is a specific thing with attributes and inner blocks itself, where as a pattern on its own doesn't have that, it relies completely on the blocks it's made of. That being said maybe there is a nice DX here I'm not seeing.
I hadn't considered this and yes I fully agree
@ashutoshgautams
I think a context of preview makes perfect sense and a preview window is a different context than editing, however if view isn't currently being used other than preview, perhaps we could just use that to keep the
view/editparadigm we already have for other things in the REST API.