Remove coupling of templates, parts, and patterns when switching themes

[jameskoster]

I believe the way templates/template parts are handled upon theme-switch may warrant some exploration. For the purpose of this conversation let's assume you are using block themes exclusively.

Currently when you activate a new theme, any of the old theme templates that you have customised are retained. In general I think this behaviour is good as it reduces the unexpected disruption to layout that can occur upon theme activation. But "in general" ≠ "always" :)

Imagine you made some very minor template edits to your post content template part in the past. Now imagine you found a new theme with a post layout you really like. With the current implementation, when you activate the new theme, your posts will continue to render using the old themes post layout, undermining the whole purpose for switching themes in the first place. To get the desired experience you'd have to manually go and delete/revert your old template customisations - an activity that is totally detached from theme activation.

Let's talk about whether users should be presented with options for what should be done with their customisations when they activate a new theme. At the very least, it seems prudent to ask them whether they want to keep their customised templates. But is there a case to be made for unedited templates being kept as well? Maybe their motivation for switching themes is based more on style than layout.

There is potential for any decisions made here to be extended to Global Style customisations as well.

[carlomanf]

Let's talk about whether users should be presented with options for what should be done with their customisations when they activate a new theme. At the very least, it seems prudent to ask them whether they want to keep their customised templates. But is there a case to be made for unedited templates being kept as well?

There is a precedent here with widgets and menus, where you can create them in one theme and then bring them to another theme after switching. The difference between this and what you describe, is it happens after the theme switch, rather than upon the theme switch. In other words, there is a short window of time where the new theme might look "unfinished" because the user hasn't yet moved their old widgets and menus into place.

#31971 would provide the underlying foundation for the same process to be possible with customised templates and template parts, provided a UI is built for it. That said, I guess the preview mode of the customiser was meant to stop the "unfinished" version of a new theme from being publicly visible, so this might be seen as a regression.

In terms of keeping unedited templates, I think that could only be done through some equivalent to the customiser's preview mode, because I'm of the opinion that a theme's files should not be accessed when it's inactive. It seems a breach of trust, and could be a security risk, especially on multisite. That would mean that the user's decision to keep an unedited template can only be made before the theme switch is completed, not after.

Although, this could cause confusion for the user about being allowed to bring over customised templates and template parts whenever they like, but for unedited ones they only get one chance.

[mtias]

There's a few things we need to do here. The biggest new introductions we have are user templates and user global styles; these both open new possibilities and bring new challenges. First we should outline user flows that we anticipate or want to make possible. For example:

• Choosing a theme and wanting to switch everything to the new look (discard any user modifications in templates or styles).
• Wanting to preserve some customizations such as colors or header navigation. Or conversely; wanting to replace styles and navigation but leave everything else intact.
• Wanting to preserve everything (essentially incorporating a new theme's templates or patterns on demand).
• There could be themes with different set of templates (say, a commerce theme that brings in new templates) that are additive.

Some of these problems should be approached from a block perspective since there's a lot we can do on the navigation block itself to accommodate some flows.

What is clear is that we can no longer assume for users what they may want to do but we should choose a good default. It'd be reasonable to make the first option the default since it's what most are accustomed to, but we can discuss it. Semantic template parts are also a tool we have for managing some expectations since they can overlap between themes.

Theme switching should have the option of being a more granular operation in the site editor, walking users through some steps where they could choose to retain or discard specific templates (like a header) or global styles. Right now there's a lack of clarity upon switching themes about whether a specific part of the site will be replaced or not.

[carlomanf]

I opened another patch to aid with a solution to this, if anyone would like to test: WordPress/wordpress-develop#2179

[annezazu]

With four weeks until beta 1, removing this from the 6.4 board as we haven't made enough progress to reasonably ship something to solve this complex problem.

[annezazu]

While this issue remains open, I wanted to share a video about the impact it has today where I switch from using Twenty Twenty-Three where I've edited the blog home template to Twenty Twenty-Four where all of that content is removed:

losing.homepage.content.when.switching.themes.mov

Because that content is in the prior template of Twenty Twenty-Three and not in a page, I'm not able to recover what's there after switching and have to switch back. In the past, when switching between themes, this didn't happen as you either displayed latest posts or had a set page assigned to the homepage. This is part of the conundrum of this issue at hand and, with live previewing available with block themes, we should consider how best to surface those things there.