Allow patterns within patterns to render in BlockPreview

[richtabor]

What problem does this address?

We should be able to reuse patterns that are already created inside another patterns, using the core/pattern block.

When I add a pattern inside of another pattern, it does not render properly within the BlockPreview of the Pattern Library — but once inserted, the pattern called by the core/pattern block does get successfully applied.

To test, I added the pattern below to Twenty Twenty Two, which calls the twentytwentytwo/footer-default pattern with the pattern block:

<?php
/**
 * Pattern block test
 */
return array(
	'title'      => __( 'Pattern block test', 'twentytwentytwo' ),
	'categories' => array( 'featured' ),
	'content'    => '<!-- wp:group {"align":"full"} --><div class="wp-block-group alignfull"><!-- wp:pattern {"slug":"twentytwentytwo/footer-default"} /--></div><!-- /wp:group -->',
);

What I’d expect

I’d expect that a pattern referenced with the core/pattern block renders within BlockPreview. As you'll see in the last screenshot, the core/pattern does render once added to the page — it just doesn't render within the Block Preview.

If we can use the core/pattern block within patterns, theme developers can properly reuse patterns in "page patterns" — instead of duplicating entire patterns (doubling the maintenance of any patterns included in full page patterns).

Screenshots:

Viewing the pattern above within the library (notice it's empty):

Inserting the "blank" pattern containing the pattern above, renders properly on the page:

[ellenbauer]

I'm wondering if there is any solution for this issue, since it would allow a much easier work flow for block theme authors allowing us to add more complex nested patterns e.g., a Landing page pattern to a theme.

[mtias]

Looks like a bug in block preview that we can address, but I also wonder what is the structure that is leading to the need of nested patterns. Are we talking about optional full-page templates that reference multiple patterns or something else? Want to check that there's no anti-pattern (no pun intended!) buried within that we should address in a different way.

[ellenbauer]

@mtias Thank you so very much for your reply. You are totally right, and it's great that you mention there might be an issue with confusing patterns vs templates. Maybe you can help solve the confusion a bit?

There are 2 scenarios where I feel using nested pattern blocks can be useful for block theme creators:

1. Page patterns

Next to smaller section patterns, I also feel it is helpful to provide our theme users with patterns that have the pages they see in the theme demo all ready to go. Therefore, I followed themes like 2022 (as I researched other themes in the Automattic theme collection, do this too) and created page patterns like 'About', 'Contact', 'Pricing' etc.

The reason for not creating Templates for anything but the Home page (home.html) is that I think it's confusing to have the content in the Template, then assign the Template to a page and have this page be empty. Or am I missing a point here?

2. Reusing small patterns on multiple occasions in a pattern collection

Additionally, when creating a pattern library for a theme, I feel like creating small patterns and reuse them multiple times in my pattern collection can save me a lot of repetitive code.

And example would be a number of Footer patterns with let's say the lower section including the copyright notice and social links will stay the same, but the top parts of the patterns do change in their layout.

[mtias]

Thanks for expanding on the use cases!

1. Are those patterns encompassing of page layout (do they include parts like header, sidebar, footer) or just post-content in general? I think some of these could be a custom page template that — in addition to — may or may not reference a pattern as core/post-content within.

2. Those smaller ones are what I was thinking more of — particularly because it's not immediately clear if they are a development convenience or also part of the user experience. For example, are you generally making them available in the inserter for users or it's more for grouping things while developing?

[ellenbauer]

@mtias Thank you sooo much for your reply 😍

1. No, they don't include the header, footer, or sidebar. We use a 'Header and Footer' Template and then provide the page patterns, let's say with the content of the About page. I thought these could be custom Templates as well when I created my first block theme. Then I looked at 2022 and discovered that page patterns are used there.

The only thing that holds me back from, creating, e.g., an About Page Template is the result of empty page content for users, when they open the Page in the block editor. It feels like this would not be something the user would want. Is there a plan to make Template content available in the page as well, or to merge these somehow.

I just feel like I'm still missing the concept here a little.

2. My plan is to make them available individually, but also offer combined versions. But you are right, it's also a case of development convenience, especially when thinking of maintaining the patterns later on.

[richtabor]

Are we talking about optional full-page templates that reference multiple patterns or something else?

This is what I'm referring to, mostly.

Full page patterns

If I've created three patterns to use in a full page pattern, say for the Add New modal, I can't reuse any of those patterns, or the block preview shows up empty. I would say this instance is developer convenience, as we'd be able to reuse patterns instead of maintain less 2x the code.

Template parts

The same follows for header template parts that leverage patterns. Twenty Twenty Two went around this particular BlockPreview issue by adding header patterns, like this, and template parts with the exact same pattern code.

That works fine enough, but then we have both of those header choices (which are the same patterns) to pick from within the Template Part "Replace" modal, adding unnecessary weight to the decision point here.

Templates

I'm still exploring, but I don't think adding patterns to whole templates is generally a good idea (currently). Otherwise, like @ellenbauer mentioned, the actual patterns would not be leveraged properly as they cannot be edited, unless from the Site Editor. Eventually those experiences (block v. site editors) will be closer, but today that would add a good bit of confusion to the mix imo.

[mtias]

This is very useful, I think there's a slight difference between the pattern flows that relate to creating new pages, selecting a header, etc, from what could be plain pattern in the directory. But regardless, there's something to fix there if we can make the previews work without performance penalties.

@ellenbauer it seems like they'd be core/post-content patterns indeed. Have you used those to get the modal inserter when creating new pages?

[BE-Webdesign]

#42832 Fixes this, with minimal performance cost by only passing the needed patterns to the block preview.

[inc2734]

#39732 (comment)

I agree with the above!

I also have another use case. I am calling pattern in template parts. To translate strings displayed in template parts.

When I want to display a string in a template part, translation is not possible because template parts are static HTML. However, since patterns are PHP, I can use PHP translation functions.