An equivalent to "Inactive Widgets" for template parts

[carlomanf]

In many ways, template parts are considered the equivalent of widget areas. Through template parts, users who have the capability to edit_theme_options will be able to add blocks of content to their sidebars/headers/footers just like they added widgets to their widget areas.

When a theme with widget areas is deactivated, the widgets that the user added will go into the Inactive Widgets section, enabling the user to transfer those widgets to their new theme easily.

When a theme with template parts is deactivated, the user's customised template parts become quite difficult to retrieve. They will not show up in the Site Editor at all, meaning that Appearance > Template Parts is the only way to retrieve them. Even then, they would have to open up two browser tabs to transfer their blocks to their new theme.

Clearly, there will be a need to be able to transfer template parts between themes in a more seamless way, like is possible with widgets. However, when a theme is not active, it is possible to delete that theme.

How can this be solved without risking content suddenly disappearing because of a theme being deleted, and also without denying users the freedom to delete old themes?

[carlomanf]

Thinking more about this, the problem seems to stem from the way that two different concepts in the old theming paradigm are mapping to the same concept in the new paradigm.

In the old paradigm:

• Template parts were purely a convenience mechanism for theme developers, enabling them to reuse code between templates. The user didn't get advised of the theme's template parts at all.
• Widget areas were a mechanism to avail additional content (i.e. not design) areas to the user, beyond the standard post content. The user had the expectation that any content they add to these areas would be easily retrievable after switching theme.
• Template parts often wrapped widget areas, but they were still two separate things.

In the new paradigm, the nuance seems to be lost.

An easy "solution" to this problem is already possible, which is for the user to use reusable blocks when they add content to template parts. In this way, the reusable block effectively plays the role of the widget area. When they switch themes, they can just drop in these reusable blocks into their new theme.

However, how many users would have the foresight to do this? Probably not many.

Here is a proposal to solve the problem:

1. Remove the wp_template_part post type, but leave intact the template part block, the template-parts endpoint and the block-template-parts directory
2. When a user customises a theme's template part, the new post is saved as wp_block and an entry is saved to theme_mods that maps the template part slug to the reusable block ID
3. When a user switches theme, the new theme's theme_mods can map each of its own template part slugs to an existing reusable block, a new one, or none at all
4. When resolving a template part for a given theme and slug, it would be done by looking up the slug within the theme's theme_mods, and using the theme file if the slug is not set, and using the nominated reusable block if the slug is set. (This solves all the nasty problems with slug conflicts that have been discussed to death in other issues.)

Tagging @youknowriad @Addison-Stavlo because I personally think template parts should be left out of 5.8 and not merged to core until this issue is resolved.

[Addison-Stavlo]

there will be a need to be able to transfer template parts between themes in a more seamless way

I definitely agree and think we should take steps towards allowing all template part CPTs to be available from within the editor, regardless of what theme they were originally created with. However, I don't see how this would require drastically changing the implementation and using wp_block instead behind the scenes? Why not keep using the wp_template_part post type and allow the endpoint to return results regardless of its theme term?

When a user switches theme, the new theme's theme_mods can map each of its own template part slugs to an existing reusable block, a new one, or none at all

Would that mean if I customized my header on theme A, then switched to theme B, that my custom header would be mapped and used instead of theme B's default? I feel like this is too opinionated and ruins some of the magic of switching themes for folks that would do so for the sake of headers/footers/global-styles etc. Instead I would think theme B should show theme B's default header and give the user the option to replace it with the one they had customized before the theme switch. 🤔

[carlomanf]

However, I don't see how this would require drastically changing the implementation and using wp_block instead behind the scenes? Why not keep using the wp_template_part post type and allow the endpoint to return results regardless of its theme term?

I ended up using the existing post type after all when implementing the solution at #31971, so you can disregard the wp_block suggestion. I also extended it to templates as well.

Regarding the endpoint returning results regardless of the theme term, I considered it, but settled on an alternative approach to let the endpoint accept a post ID instead. The main reasons are:

1. it excludes file-based templates, which should not be accessible from inactive themes because they could be deleted at any time.
2. it keeps a clear distinction between active and inactive template parts, by requiring them to be re-attached to the active theme before they can be included by the block.

Instead I would think theme B should show theme B's default header and give the user the option to replace it with the one they had customized before the theme switch. 🤔

That's actually exactly what I meant, sorry if it was unclear.

Although, there are actually three different ways this could be done with my proposal:

1. replace the slug being nominated by the block instance (if the slug is already active)
2. leave the slug as is, but replace the post ID that the slug maps to
3. create a new slug and map it to the new post ID, and update the block instance with the new slug

Although each might be appropriate for different situations, it might be better for the system to automatically select the best method behind the scenes, to avoid overwhelming users with options.

[Addison-Stavlo]

it excludes file-based templates, which should not be accessible from inactive themes because they could be deleted at any time.

I think the current approach would as well if we are only accessing file based templates corresponding to the currently active theme's directory.

it keeps a clear distinction between active and inactive template parts, by requiring them to be re-attached to the active theme before they can be included by the block.

How are we defining active here ("in use" or "able to use")? I would think 'active' means it is currently being used by a block somewhere, but it sounds like we would be marking it 'active' just to have the ability to use it - so by this definition it could be both 'active' but 'unused' at the same time?

I may totally be missing something, apologies if so. But it still sounds like we could skip all the theme attachment complexity and just allow users access to customized template parts regardless of theme? It seems much more simple and manageable than updating slugs, ids, and/or theme mods every theme switch?

[carlomanf]

How are we defining active here ("in use" or "able to use")? I would think 'active' means it is currently being used by a block somewhere, but it sounds like we would be marking it 'active' just to have the ability to use it - so by this definition it could be both 'active' but 'unused' at the same time?

You're right about this, and although it might seem like an extra layer of complexity, there are two reasons for it:

1. It's a massive efficiency improvement over searching all templates to see which template parts are in use
2. It allows a consistent approach between template parts and templates. If I want to use my customised 404 from theme A in theme B, how else can it be done other than keeping a per-theme registry?

I may totally be missing something, apologies if so. But it still sounds like we could skip all the theme attachment complexity and just allow users access to customized template parts regardless of theme? It seems much more simple and manageable than updating slugs, ids, and/or theme mods every theme switch?

I appreciate the critique, it's the only way to know if the approach is viable. I certainly considered allowing the endpoint to accept different theme values, but it was applying the same kind of critique that led me to conclude it wouldn't work.

1. It means that the theme term represents the first theme it was used with, not necessarily the only one. If I customise a header in theme A, and then switch themes four times over four years and keep using that same template part throughout, I'm still referring to it as the theme A header, correct? It seems semantically wrong to be referring to a theme I haven't used in four years.
2. It also can cause unexpected effects because taxonomies do not provide a safeguard for each post to belong to one term only. In this comment I described an unwanted scenario that could occur, and to me this is the biggest red flag of all.
3. It would not be possible to use the same template as single in one theme and single-post in another theme, because the slug is declared by the template.
4. Customising and reverting a header in theme A can be done quickly and easily without modifying any block instances. If theme B has multiple templates that each include a footer template part, and I want to replace this footer with my customised header from theme A, each block instance has to be updated one by one. Reverting them also has to be done one by one, and there is no memory of the original because both the slug and theme have been changed on the block instances.

Theme mods overcome all of the above problems, and it mirrors exactly how themes handle widgets and menus. A menu doesn't forever continue referring to the theme that happened to be active when it was first created, menus in the active theme can't unexpectedly change because an inactive theme was deleted, and the same menu can be instantly moved in and out of the header of one theme and the footer of another. #31971 will make the same true of templates and template parts. Why risk a new and unproven mechanism for theme customisation when there is already a proven pattern to follow?

[Addison-Stavlo]

Thanks for explaining @carlomanf! It sounds like a promising alternative.

[carlomanf]

It looks like there is a new perspective on this issue now that 6.3 has started the process of merging template parts and patterns. The new "Patterns" section essentially is the equivalent of "Inactive Widgets," but I think there is still more work to do.

One thing that strikes me as a little bit confusing is that when the user tries to create a new pattern, they have the option of creating either a template part or a pattern:

I am not sure exactly why the user would choose to create a template part rather than a synced pattern. The main difference is synced patterns remain available after switching themes and template parts do not. Why would the user knowingly choose to impose this limitation on themselves? (Another difference is that template parts can be assigned to areas, but it seems to be more of a superficial difference that doesn't carry any behavioural implications.)

Template parts seem like more of a mechanism for theme authors than for users. Am I missing something? It seems like it would mostly solve this issue to remove the "Create template part" option from an upcoming version of core and make it only available through the Create Block Theme plugin. Users would still be able to edit template parts provided by themes, just not create new ones.