Full Site Editing: Templates and Template Parts Duplicates

[Copons]

Note: I'll only mention "templates" for brevity, but this applies to both templates and template parts.

Templates used in Full Site Editing can have different origins (or, as I've called them in #26394, "sources").

• Themes can provide them as HTML files in the block-templates folder; likely plugins will be able to provide their owns as well. Whenever the template loader runs (for example, when opening the Site Editor), these files are converted into wp_template posts.
• Users can create their own templates in the Site Editor, or from Appearance -> Templates.
• Users can update templates provided by themes and plugins, practically making them their own.

The original WP template hierarchy relies on file names to determine which template is used for any given content.

FSE templates aim to recreate the same experience (if anything, for backward compatibility reasons), relying on slugs instead.

This means that it's extremely easy to end up with multiple wp_template posts with the same slug, which can each be used for their corresponding content.

For example, if I activate an FSE-ready theme containing the index template, and then I activate another FSE-ready theme with its own index template, my site will contain 2 different index templates, without a clear way to determine which one will be used.

In #26394 I've added a theme post meta to wp_template, which stores the theme that originally provided that template (wp_template_part already has the same post meta).
This is not enough to address potential conflicts, but it's at least a start.

Automatically Choosing the Appropriate Template

At first we should probably figure out a way to automatize the template choice, on a per-slug basis.

• If there is only 1 template with the slug matching the current content, and it was either provided by the current theme, or it's customized by the user, the site will use that.

• If the only relevant template was provided by an inactive theme, should the site still use it, even if it might not match the current theme design?

• Given the choice, templates customized by the user will have the priority over "siblings".

• What about plugin-provided templates? Should they be prioritized over theme-provided ones?

• What happens if, for example, a site has a user-customized index, and afterwards the user activates a theme which includes its own index? Should we also favour the creation (in this case "conversion from file") date of the wp_template post?

Manually Choosing the Appropriate Template

We don't really have a way to do this right now, but it might be useful, especially as an escape hatch when the automatic choice is not picking the expected template (note: "expected" != "correct").

We could approach this from the template side, or from the content side.

Setting Default Templates

Similarly to how we handle the page order, we could add a new custom field to wp_template.

It could be a number field, working like the page order but on a per-slug basis (e.g. index templates will have their own order, separate from singular templates order), but it will probably become messy when new templates are created.

Another way could be to simply have a "Make template default for its corresponding content" checkbox.
Checking it on a template would automatically uncheck it on other templates with the same slug that had been previously set as default.
Should creating new templates (either manually or via file conversion) affect this value?

Assigning Templates to Content

Similarly to how we handle custom templates for pages, we could create an interface that visually recreates the template hierarchy with the available templates, letting the user pick their preferred template when there's a possible choice.

Such interface could be also handy to let users "toggle" templates for a content.
E.g. the site has a front-page template, but the user would rather use index for the Front Page. Currently the only way would be to remove front-page from the site.
A toggle could switch the template between draft and published (for example), "opening and closing" the hierarchy fallback flows.

---

I'm sure there are other possibilities, but I think these might be the most likely to happen.

If some of these proposal seems too far out, it's because they are mostly supposed to be a way to kickstart a discussion about duplicate templates.

[carlomanf]

For example, if I activate an FSE-ready theme containing the index template, and then I activate another FSE-ready theme with its own index template, my site will contain 2 different index templates, without a clear way to determine which one will be used.

Why does that have to be the case? If the template from the first theme was overwritten by the user, then the second theme template should be ignored and no new auto-draft need be created. If the template from the first theme was not overwritten by the user, then the same auto-draft should be updated with the content of the second theme template (I think this is what's being proposed here.) The content from the first theme need not persist in the auto-draft because the theme's been deactivated.

In #26394 I've added a theme post meta to wp_template, which stores the theme that originally provided that template (wp_template_part already has the same post meta).
This is not enough to address potential conflicts, but it's at least a start.

Correct me if I'm missing something, but I don't see any reason that post meta should be needed, nor any reason to replace the use of auto-draft. My understanding is the auto-draft exists for the same reason it exists for every other post type, which is in anticipation for the post to be saved and published. If that doesn't happen, the auto-draft is not actually used for anything. It's actually the theme file that acts as the template, not the auto-draft, at least not as long as its status remains auto-draft.

• If the only relevant template was provided by an inactive theme, should the site still use it, even if it might not match the current theme design?

No, why would you ever use material from an inactive theme?

• What happens if, for example, a site has a user-customized index, and afterwards the user activates a theme which includes its own index? Should we also favour the creation (in this case "conversion from file") date of the wp_template post?

I thought the rule is the user-customised template is always favoured, as long as its post status is publish.

In short, I actually think duplication of template slugs is a bug. Template parts are different and that's my understanding why the theme post meta exists for them. For templates, however, there should be a mechanism that prevents any newly created template to have the same slug as an existing one, just like there is for posts and pages, and there should be no need for a theme post meta.

I don't mean to be impolite, and again correct me if I'm missing something, but I actually think a lot of what you've proposed above is irrelevant and this should only be a simple bug fix to prevent slug duplication.

[Copons]

Thank you for chiming in @carlomanf, it's very appreciated!

Correct me if I'm missing something, but I don't see any reason that post meta should be needed, nor any reason to replace the use of auto-draft. My understanding is the auto-draft exists for the same reason it exists for every other post type, which is in anticipation for the post to be saved and published. If that doesn't happen, the auto-draft is not actually used for anything. It's actually the theme file that acts as the template, not the auto-draft, at least not as long as its status remains auto-draft.

This is a good point, and I'm pondering how to integrate it into #26394.

I think my confusion was based on the fact that we show auto-drafts in the Site Editor without any indications, which made me believe they were used instead of their corresponding files, while in fact they are, as you correctly describe them, only used "in anticipation" to user customization.

I'm absolutely grateful for your objection, which prompted me to give a second look at the template loader logic, ultimately clearing lots of my misconceptions! 🙇‍♂️

I don't mean to be impolite, and again correct me if I'm missing something, but I actually think a lot of what you've proposed above is irrelevant and this should only be a simple bug fix to prevent slug duplication.

No worries! The intention of this issue was to start a discussion, which I'm glad it's happening.
I've also received comments very similar to yours by some of my coworkers, so it definitely means that I was approaching this from the wrong side.

In short, I actually think duplication of template slugs is a bug. Template parts are different and that's my understanding why the theme post meta exists for them. For templates, however, there should be a mechanism that prevents any newly created template to have the same slug as an existing one, just like there is for posts and pages, and there should be no need for a theme post meta.

The slight difference between posts and templates slugs is that for templates we don't just need for them to be unique, we actually need to prevent creating templates with the same slug.
In other words, if two posts have slug foo, the second just becomes foo-2 and everything's fine. On the other hand, an index-2 template doesn't have any meaning, and would only create confusion.

Either way, for now I'll go back to the drawing board for #26394, and solve the inconsistencies I've accidentally introduced.
Thank you! ✨

[carlomanf]

No problem, I had just spent the weekend trying to make sense of the auto-draft system myself and why the site editor was not updating with the changed theme files but the front-end was, so good timing.

Regarding the index-2 effect, it's not an ideal permanent solution but it might be worth implementing as a temporary fix before a more user-friendly solution is found.

[gziolo]

Why does that have to be the case? If the template from the first theme was overwritten by the user, then the second theme template should be ignored and no new auto-draft need be created.

It is really as simple as that? Sometimes a user would only apply some tiny changes to one of the existing templates and they would expect that it gets discarded when a new template gets activated. Maybe it should a part of the updated flow when a new theme gets activated. What if the user could choose whether to keep customized ones or go fully with the theme (something that is closer to how it works today). All customized templates should be kept unless the user explicitly decides to delete them (it might become a part of the theme deactivation as well).

If the template from the first theme was not overwritten by the user, then the same auto-draft should be updated with the content of the second theme template (I think this is what's being proposed here.) The content from the first theme need not persist in the auto-draft because the theme's been deactivated.

It isn't the case for template parts (unmodified by the user) at the moment. I agree that all preexisting templates and template parts that have the status auto-draft should be removed when the new theme gets activated 👍

[carlomanf]

@gziolo yes, it should be that simple. Your suggested enhancement is good but it should work without two posts getting the same slug.

[vindl]

@Copons is this still relevant after #27910?

[Copons]

Things changed so much that this is not relevant anymore. Closing!