Synced patterns vs template parts

[unscripted]

As Gutenberg continues to evolve, I find the line between synced patterns and template parts becoming more blurred. I'm curious if there is still a case for template parts in WordPress, and if so, what are the clear differences and guidelines for when to use one over the other?

I'd love to hear how other developers and agencies use template parts and synced patterns.

I can tell you from experience that while it's slightly confusing for me, it's even more confusing for my clients.

[youknowriad]

Agreed that we would be in a better position if we merged the two concepts. That said, it's a complicated project. I've laid out more details and potential approach here #62566 (comment)

[fabiankaegy]

From my perspective the main concern right now is that synced patterns only ever exist in the database. Which makes them very hard to use productively on large complex sites with strict editing requirements such as WordPress.org for example.

Template Parts do support reading the file from disk. So (#59272) is my main issue that blocks merging the concepts.

Besides that, the fact that a template part has a clearly identifiable wrapper element which can get a unique class name as per the template part area applied to it via a filter is very useful.

In a pattern all that gets output is the actual nested group. Which makes it very hard to target that specific pattern with custom styles unless you resort to adding a custom class name through the UI

[justintadlock]

A few things:

Template parts can live in the theme itself (maybe this is solved with synced theme patterns).

It's possible to create block style variations for Template Parts. I don't think that's promoted in particular, but they are in use. Whereas patterns must have the style variation on something like a Group.

Like style variations, you can also add custom classes to the existing template part wrapper element (this can be very useful for theming).

We also have template part areas. There are defaults for header, footer, and sidebar, but a lot of extenders have created custom areas. That feature doesn't exist at the pattern level, so it'd need to be recreated in some way.

The loss of the render_block_core/template-part (and related hooks) with a potential merge would break back-compat on the front end unless that was carried over in some way. I know I'm already using this for a few scenarios (for example, disabling render for the comments template part when there are no comments and comments are disabled).

From a theming perspective, it's nice to let users edit a single part of a template without those edits being saved in the template itself. For example, I have a "Loop" or "Posts" template part area with a default template part for it. Users can update that single part and have it apply across every other template that uses it. I'm guessing synced theme patterns could fill this void at some point.

---

Side note: so much of the confusion for users, IMO, is because we moved Template Parts under Patterns in the UI. I still think that was the wrong decision. While the two features share some concepts, they have very different use cases for me.

[fabiankaegy]

I still think that was the wrong decision. While the two features share some concepts, they have very different use cases for me.

Couldn't agree with this more. To me they might be similar features from a technical standpoint. But from a user perspective they are not.

[youknowriad]

I do think "template areas" make sense but themes can also have patterns. In fact most themes have "header" patterns and "header" template parts. I think assigning patterns to areas is indeed a good thing but I think for most users and conceptually, there's not much need for a difference.

[youknowriad]

That said, I have to agree with you that moving template parts in the UI without actually unifying the concepts, is not the ideal move. We probably should have waited until the concepts were merged fully.