Template editing: convert semantic patterns to template parts upon insertion

[jameskoster]

Potentially part of #41379.

On occasions where patterns designed to be used for template headers / footers are inserted it might be good to automatically create template parts, or at least offer a way to do so. This helps in a couple of ways:

1. It unlocks functionality associated with semantic template parts (replacing)
2. Reduces the chance of using the same pattern in multiple templates without synchronisation

A very rough mockup:

create.footer.mp4

To do:

• Convert patterns to template parts when inserted via the Inserter
• Convert pattern to template part during template part replacement flow (see: Template editing: convert semantic patterns to template parts upon insertion #41397 (comment))

[mtias]

I don't know that you always want to make these synchronized by default. If pursuing this, we should probably ask for semantic patterns, and only if you don't already have a header / footer saved.

[Addison-Stavlo]

I think this is definitely a necessary improvement. Especially considering the quick inserter's current functionality when you search "Header" you end up with only patterns suggested (since block results are prioritized after patterns), and selecting one just drops blocks directly onto the template.

not only do users miss out on:

It unlocks functionality associated with semantic template parts (replacing)
Reduces the chance of using the same pattern in multiple templates without synchronisation

But they also miss out on the semantic template part functionality of automatically having a semantic <header> element wrapping that section of content.

Something like @jameskoster's mockup to present an option when inserting one of these patterns definitely seems useful! Although also note it would be smart to bypass presenting this option if the insertion point is already inside a template part.

[jameskoster]

Noting that patterns should probably be converted to template parts during the replacement flow as well. Or we should ask the user how they'd like to proceed (update current template part or create new).

At the moment, if you replace a template part, and select a pattern from the resulting modal, that pattern gets inserted into the current template part. This is obviously an edit, not a replacement. Video demo:

tp.mp4

[talldan]

I'm not sure if there are already other ideas for solving this, but I had a potential idea. The template part block could declare a new type of block transform for patterns.

Whenever a pattern that has a blockTypes property is about to be inserted, the editor could check for the matching block transforms, and if it finds any present the user with the option of converting to the block types or inserting the pattern as it is.

The only downside is that this transform is probably only going to be useful for template parts, I can't think of any other use cases. But at least it's an existing system rather than inventing something completely new.

Another option could be to actually define a template part within the pattern itself (similar to how the navigation block works in that it can have serialized inner blocks), but that seems problematic given there are so many existing patterns in the wild, they'd all need to be updated.

[mtias]

@talldan also related, we have discussed pattern transforms in a few places: #27575, #28737, #38529.

The core idea being that we can have "pattern variations" defined as set of patterns that loosely have the same overall blocks and map attributes of role=content. It wasn't clear how we'd define these variations in a way that doesn't create too much API overhead.

One thing I proposed at some point was using wp:pattern/category in the blockTypes restriction if we don't want to introduce another attribute.

We need to bring this to places other than header and footers, so a user can cycle through some variations of a Hero pattern without being inundated with an entire category worth of patterns.

cc @mcsf

[talldan]

Thanks for those links. A lot of interesting discussions that I wasn't entirely aware of. 👍

My comment above was mostly about finding a way to codify the creation of an entity for template part patterns. I think that's still a valid issue (and possibly for the navigation block too). At the moment this is only surfaced in specific flows within those blocks.

It wasn't clear how we'd define these variations in a way that doesn't create too much API overhead.

Yeah, this is interesting. A good example is a set of blocks that might have an image, where a pattern incorporating a cover could be an appropriate substitute. It isn't clear to me how using role=content alone it'd be possible to infer that the cover's url attribute is an image url. There's nothing in the cover block's declaration that implies it's primarily an image, perhaps other than the block category being 'media', and the transforms (which I saw you mentioned here - #27575 (comment)). It isn't a sourced attribute, and that's probably the biggest issue.

It feels like there's some crossover with the concept of microformats as well. Going deeper down the rabbit hole, how would patterns showing events be surfaced if the blocks involved are mostly groups, post titles and post dates. Though maybe that's being a bit too clever—a user can always search.

[annezazu]

This came up as part of the FSE Outreach Program's Build a Block Theme exploration. In particular, here's a link to a video where @paaljoachim very kindly walks through his thought process of adding a new header pattern and trying to have it "takeover" as the header template part: https://youtu.be/tniEqn9q0fk?t=1344 It runs for about a minute until moving on to other issues.

I add a Header pattern and now I have one official Header template part where I see it has the Header template part label.
The other newly added Header pattern does not have the Header template label but is in a Row. How do I make the new pattern become the Header template part?

[paaljoachim]

Thanks Anne!

What if Patterns are actually just another option like Row, Stack, Grid etc in a Group block.
I add in a Pattern Group block and in the sidebar have an option to select Header, General or Footer template part.
I added a more detailed comment here: #44581 (comment)

[jameskoster]

Closing this as it is essentially captured by #48458. Specifically: the ability to update the sync status of a pattern.