Pattern / Template Part Unification - the technical challenges

[talldan]

Related #41717

With patterns and reusable blocks now mostly unified (albeit with some tidying up to do internally), it might be good to look at template parts and the technical challenges are present with undertaking a similar unification. This issue doesn't really consider whether it's a good idea to do this right now, but only what the challenges would be if we did.

A guiding principle would be to avoid making such a unification any harder in any future work undertaken on patterns and template parts. Generally it'd be future work moves towards aligning the two wherever the opportunity arises.

Here's a list (probably not exhaustive, additions are welcome) to consider:

Post types (wp_template_part and wp_block) and server side code

• Perhaps ideally a data migration could mean a single post type, but a single block could also read from two different entities, or they could be combined via a single REST endpoint as part of an intermediate step towards unification.
• Template parts generally have a different permissions model when compared to a pattern. A wider range of user types can create a pattern, but generally only admin-y users can interact with template parts. This is probably the biggest challenge. Could upcoming work on workflows help solve this? (e.g. a more granular post instance permission model)
• Template parts use slugs, while patterns use ids (as a holdover from reusable blocks). To align them, ideally patterns would also use slugs. It might be quite a lot of work to retroactively change this, but it'd unlock some useful features (edit and clear customizations for patterns).
• Template parts can have a semantic area while patterns can't, but it could be an optional feature of a pattern.
• Template parts have origin and source properties to indicate where they came from (theme, plugin). Patterns also have source (directory, user), so this aligns fairly well.
• Connected to the above origin/source, template parts have an isCustomized attribute to indicate when a user has modified a theme provided template part. This would be something that's beneficial for patterns - see Patterns: allow overriding of theme patterns as well as duplication.
• Template parts don't have a sync status while patterns do. In a migration, template parts would always be considered synced, just like how reusable blocks were handled.
• Patterns can have a category and there's some alignment with the concept of an area, since header/footer is also a category.
• Particularly in the PHP code, there's a lot of code sharing for templates and template parts, so an interesting question would be how patterns fit into that.
• Template parts are also generally coupled to a theme, though I don't know that this is a desired feature. It might be an opportunity to end this.
• Plugins can add template parts and there are several filters available for this.

Blocks (wp:template-part and wp:block) and client side code

• Migrations between block types have been done before, usually at the parser level, so this isn't impossible. Neither block has any deprecated versions, so it doesn't seem like a migration would be impossible.
• As mentioned above, a UI is needed for choosing an 'area'.
• The template part block has a wrapping html element while a pattern doesn't. This could again be an optional feature, but it might need some thought. It ties into the area feature, header/footer areas should really have the <header>/<footer> wrapper.
• Site level template parts (headers/footers) are not useful in the post editing experience, though this is already an issue with patterns.
• The blocks and instances of those blocks are shown in different parts of the inserter, so would need to unified, and potentially template parts would be hidden from the post editing experience (this might also be a good idea for header/footer patterns). This is something that could be done even without unified blocks or post types.
• Patterns support 'pattern overrides', so a unification would likely mean that template parts also have this feature.

Extras

• Template parts can be defined in a theme.json (for what purpose, I'm not sure ... to define metadata?).
• Pattern files in a theme are .php files with some metadata, while template parts are plain .html files. Patterns can also be exported from the UI as json files. There's likely to be some back compat concerns, but it might be good to pick one format as the preferred option.
• Pattern .php files support localization.

Addendum - the wp:pattern block

This block is a little bit of an outlier, it's not visible in the UI, but used by theme devs to incorporate patterns into templates. It could be deprecated and automatically migrated to a wp:block that performs the same task, but this is probably very low priority.

[carolinan]

It is important to keep the HTML format because it allows anyone to create themes without knowing PHP.
I don't think there is anything in a pattern that requires PHP? A pattern is a group of blocks just like a templates and template part, and I think both file formats should be possible.

[jameskoster]

I was working on a friend’s site recently and it struck me how irrelevant template parts feel now that synced patterns exist. They’re adding a lot of perceived complexity to the UX, and aligning these concepts can simplify the site management experience in quite a profound way.

To echo some of the points above;

• In the UI a template part can just be a synced pattern in a special category e.g. ‘Site headers’.
• When a pattern is assigned to one of those special categories the semantic area can be applied automatically behind the scenes

Additionally, by conceptually unifying we can further simplify the UI. For instance there’s no need for so much distinction in the Patterns page sidebar, and in the ‘add new’ flow users no longer need to contemplate the difference between template parts and patterns, that’s all inferred from the chosen category.

Appropriate prominence can also be given to areas that folks are often editing IE headers / footers.

Current	Potential next step

[jameskoster]

Following up to note that by unifying we can simplify the creation process too:

[jameskoster]

Other design details to consider:

• Themes like TT4 register header patterns in the 'Headers' category. Template parts are labelled 'Header', which results in two almost-duplicative 'categories'.
• What should we do with the 'General' template part 'category'? Should it be relabelled and repositioned? Should themes be encouraged to categorise these like regular patterns?

[richtabor]

What should we do with the 'General' template part 'category'? Should it be relabelled and repositioned? Should themes be encouraged to categorise these like regular patterns?

The tough part is that there is still a role for template parts in themes, until they can ship with synced patterns at least. Otherwise one change will need to persist wherever a pattern is used (like blog views, post meta, or comments for example).

[jameskoster]

I agree, but I don't know that the user needs to understand the difference between a "Template part" and a "Synced pattern". For all intents and purposes they're the same thing. Categorisation as a means of classifying things like headers/footers feels more intuitive.

Stuff like post meta and comments are bit trickier... one short-term idea could be: "General" becomes a category under the patterns umbrella alongside headers/footers, ideally with a name that hints that they're for use within templates. That would mean themes could still supply them.

[dballari]

Hi, I’m really interested in this subject. I’ve been thinking a lot about it. I’ve never contributed with code but know I’m writing a little plugin and designing a theme that I hope will someday be in the WordPress repo.

In my opinion, all user customizations should be kept as user patterns, including the content of all template parts.

I would only use template parts in the theme’s folder as a copy of the original design provided by the theme designer or developer. And would, as theme designer, provide the least amount of theme patterns (only the ones categorized as page or post templates). And then I would provide a complete set of user patterns in xml format for the user to import using the import tool, and a theme option to unregister all the theme patterns once the user has customized all of them (or only the ones he/she is going to use) by duplicating and creating hes / her own ones.

The only thing I would do in the editor, is separate template parts from patterns in the site editor. Now the site editor has 5 parts (Navigation, Styles, Pages, Templates and Patters) and I would add ‘Template parts’.

But would not try to unify both things, as Rich says, template parts still have a role.

I would like to share what I’ve been doing in order to simplify things. This plugin explains a little bit: https://github.com/dballari/sahmi

If you edit a template part like a footer, of any theme, and then create a synced pattern inside, with all the content of the template part, then you have an easy way to customize the footer. If you make a mistake, you can always recover the theme’s original code by resetting the template part.

I’m currently designing a theme that will be delivered this way: with the xml content that turns all template parts into user synced patterns. It works and I thing is the best way to simplify things for the end user that does not know what a template part is.