The wp:pattern block

[mtias]

Note

This is an integral part of the block API #41236

Pattern block tracking issue - #50159

We've so far treated patterns as a block instantiation feature but not a permanent object. This was a useful lens with which to introduce patterns and enabled many workflows (like copy and paste from the directory) without adding further edges to the block API. With time, we also introduced a utility block called wp:pattern to allow block theme authors to reference individually registered patterns dynamically, which has also helped with translations.

There are a series of upcoming features around #39281 we want to unlock that now require us to look more seriously into making this block fully powered:

• Being able to designate a container that can cycle patterns within — just like template parts but without the extra overhead they entail. Shuffle content blocks when templateLock is contentOnly #44581
• Introducing patterns where the content is configurable on a per-instance case but the design and layout is shared and can be globally updated across instances. This requires developing the contentOnly property further to establish a set of attributes (role == content) that the pattern is then injected with dynamically.
• Helping the zoomed.out view properly focus on patterns rather than top level blocks.
• Possibly unifying concepts with reusable blocks where everything is a "pattern" just with different sync properties.
• Attach theme.json child objects to define a new set of style properties that only apply to the pattern contained within.

All of these features can be better conceptualized with the help of such a block.

Task list:

• Pattern Overrides epic (WordPress 6.5) #53705
• Surface related patterns in the template inspector #44582
• Connecting patterns with specific contexts & transforms #27575
• Zoom out view when the "Patterns" in the Inserter is selected #44585
• Building with Patterns #38529
• Patterns: Explore shuffling content blocks #55582

[robglidden]

+1. Ever since the pre-block era, I've wanted an instantiable thing in between patterns and custom (innner-enabled) blocks.

There were whole communities around "parts-based" classic themes using cruder tools of the day, and widget architecture was never quite enough.

I'd like a souped-up wp:pattern to support a Javascript hook (preferably ESM enabled), sort of like what was added to block.json. Would open many options and DX improvement too.

[markusfinell]

I dabbled with a solution to this but didn't quite get there.

I tried creating a post type for creating layouts. In these layouts I would add some layout blocks and some content. I would also add a custom "slot" block wherever I wanted to be able to add editable content when using the layout.

The idea is this:

1. Create layout, with locked content/layout blocks and slot blocks for editable content
2. Insert layout into the block editor
3. Everything in the layout is locked, except for the slot blocks which work like InnerBlocks areas. In these slots any other blocks can be inserted.
4. If a change is made to the layout, this change affects every instance of the layout wherever it is on the site.

The layout works like the wp:pattern block. It server side renders all of the rendered html and creates InnerBlocks areas wherever there are slot blocks.

Imagine a block version of get_template_part. That's what I'm longing for!

[JiveDig]

@mfinell This is exactly the missing link of what is needed (IMHO). I'd love see this in action :)

[carlomanf]

@mfinell There was a good example of your "slot" idea reported at #50060. Did you end up implementing it, or is it just an idea?

[youknowriad]

The video above suggests that the "sync" attribute is something you define in the reference pattern while I think it's something that should be defined in the "instance".

Also, I think we should still keep the difference between "fully synced" and "partially synced", because that's a behavior that existing reusable blocks rely to and we can't just update it without notice.

[SaxonF]

@youknowriad can explain full vs partial syncing behaviour from a users perspective? What's the difference? I may not have a complete picture of existing experience.

Re sync attribute on reference vs instance. I was originally leaning towards the direction you suggest (prompting to sync on insertion) but the more I've thought about this the more I think that would be a difficult transition to make from the way reusable blocks and patterns currently work (UX not technically). I was hoping there would be a natural pathway towards that point if it makes sense in future.

[youknowriad]

@SaxonF The difference is that when "full sync" is applied, the entire pattern is used as is with no change, any change made to the pattern is also applied to all the instances that are also "full synced" including "content".

[SaxonF]

@youknowriad sorry I was referring to existing reusable block behaviour. We don't have partial syncing do we?

You could just lock all layers by default so the experience is reversed ie blocks are marked as overrideable by unlocking them

[gziolo]

The difference is that when "full sync" is applied, the entire pattern is used as is with no change, any change made to the pattern is also applied to all the instances that are also "full synced" including "content".

A fully synced pattern is what we today call a Reusable block (in the future, this pattern could also be sourced from the Pattern Directory, the theme, or registered by the site). You can edit every aspect of the block in a single place, and it gets propagated in all places on the site (or sites for patterns from Pattern Directory).

A partially synced pattern is going to be a combination of the source pattern that provides the design. The design could be sourced from a static representation of the pattern from the Pattern Directory, from the theme, or from another fully synced pattern (Reusable block). The nuance here is that the user would be able to override locally the content displayed in the pattern. Still, all the changes applied to the design externally would get dynamically reflected on the site.

[youknowriad]

It's important to note that "locking editing" and "syncing" is not the same at all: locking only applies in the editor (in fact you can even edit everything in the pattern if you go to the code/HTML view) while syncing is about "rendering" (applies both in editor and in frontend).

[talldan]

The video above suggests that the "sync" attribute is something you define in the reference pattern while I think it's something that should be defined in the "instance".

I was personally imagining the opposite 😄

With the idea being that for editorial flows, a design team can create a pattern, and an author can fill it out without messing with the design. What are the use cases for the other way around?

It could also be both, the pattern creator can define what the inserter of the pattern can do, but maybe that's too complex.

You could just lock all layers by default so the experience is reversed ie blocks are marked as overrideable by unlocking them

I quite like this idea (although I haven't really thought about implementation 😆 ), kind of like the pattern would have locked/synced islands of blocks, but the rest is freeform.

It removes the simplicity of the editing experience (editing is the same as any other blocks rather than using content only mode), so I think we need more understanding of the motivation behind content only mode.

For me, content only mode is great as it makes the implementation of partial syncing much easier, but as Riad has mentioned it is really a separate concept to partial syncing, though one we lean on.

[afercia]

Great exploration. From an UI perspective I have only on concern so far. I'm not sure the 'Edit pattern' button shoul dbe placed within the Settings sidebar. The Settings sidebar should only contain complementari settings and secondary actions. All basic operations like editing should be available in the main interface. This is a principle that was established long time ago, for good reasons of usability and accessibility, and it's mentioned in a few places in the documentation as well, for example here and here. While the documentation mentions the Block settings sidebar, the general principle still applies here.

[wes-davis]

If I can offer two cents as an agency developer working daily on building Wordpress sites/custom themes for business clients:

1. Firstly just to restate that this functionality is badly needed — it's wild to me that there is currently no “modern Wordpress” way available to a) combine existing/core blocks into a single pattern or block template, which then allows BOTH b) the content of each instance throughout the site to be user-editable AND c) the design/presentation to be “synced” i.e. updatable from one central location and applying to all instances of the pattern that have already been inserted/deployed throughout a site. This is such a core, ubiquitous feature used and needed by theme/website developers.
2. As a subjective note, I think calling the states “fully synced” versus “synced” or “partially synced” is unnecessarily abstract — could the options just be called something more meaningful like “sync design only” versus “sync content and design” to make it more self-explanatory to users?

[ryandejaegher]

@wes-davis

2. As a subjective note, I think calling the states “fully synced” versus “synced” or “partially synced” is unnecessarily abstract — could the options just be called something more meaningful like “sync design only” versus “sync content and design” to make it more self-explanatory to users?

+1 to this comment. The block editor is both used as a design tool and a writing tool. Global styles and theme.json help maintain consistency across a site but patterns don't offer anything in the way of design consistency. The more you use a pattern, the more places you need to go and manually update the pattern.

In most cases the site designer is concerned with updating styles and not content. The site editor/writer would care more about consistent messaging/content.