Skip to content

Starter patterns should show content only in preview #75679

Open

Description

@mikeybinns

What problem does this address?

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.

Image

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><?php echo esc_html( $is_preview ? 'This is a preview' : '' ); ?></p>
<!-- /wp:paragraph -->

This could also be used to solve #28135 like so:

<?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 here
endif;

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.

Activity

  1. added
    [Feature] PatternsA collection of blocks that can be synced (previously reusable blocks) or unsynced
    on Feb 19, 2026
  2. talldan commented on Feb 19, 2026

    @talldan
    Contributor

    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.

  3. ashutoshgautams commented on Feb 19, 2026

    @ashutoshgautams

    What do you think about this approach?

    1. Add an is_pattern_preview() global PHP function that pattern authors can call inside their pattern files
    2. Extend the block patterns REST controller (via a Gutenberg compat subclass) to accept a context query parameter (view | preview)
    3. When context=preview is passed, set a global flag before pattern PHP files are executed, so is_pattern_preview() returns true
    4. Update the JS side to pass context=preview when fetching patterns for the inserter/pattern explorer

    A usage example in a pattern file would look like:

    $is_preview = function_exists( 'is_pattern_preview' ) ? is_pattern_preview() : false;
    ?>
    <!-- wp:paragraph -->
    <p><?php echo esc_html( $is_preview ? 'Lorem ipsum placeholder text...' : '' ); ?></p>
    <!-- /wp:paragraph -->

    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?
  4. mikeybinns commented on Feb 19, 2026

    @mikeybinns
    ContributorAuthor

    @talldan

    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 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/edit paradigm we already have for other things in the REST API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    [Feature] PatternsA collection of blocks that can be synced (previously reusable blocks) or unsynced[Type] EnhancementA suggestion for improvement.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions