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.