Templates: Update the available templates

[scruffian]

What?

This makes all created templates and template parts available to users when they are editing their site. Fixes #25071

Why?

This will make it easier for users to switch between different template parts and build themes more easily.

How?

This implementation is messy. I've copied the changes from core back into the 5.9 compat file, but I guess ideally this would happen in the 6.0 compat folder? It's not easy to override since gutenberg_get_block_templates isn't a class method. If anyone has an idea for a better approach that would be great.

We also need to think a bit about the design. Should we make it clear what theme these template parts came from? What other details should we surface? @jameskoster

Testing Instructions

• Switch to a block theme
• Open the site editor
• Edit a template part
• Switch to a different block theme
• Open the site editor
• You should see the edited template in your list of templates
• Add a template part block to the site editor
• Choose an existing template part
• You should have your edited template as an option

Screenshots or screencast

See above

[carlomanf]

This makes all created templates and pars available to users when they are editing their site.

Do they just show up in the editing area, or are they activated for use on the site as well? If just in the editing area, how would the user start using the template if they want to? If on the site as well, then particularly for templates as opposed to template parts, how would the active theme avoid getting jumbled with other themes?

This implementation is messy. I've copied the changes from core back into the 5.9 compat file, but I guess ideally this would happen in the 6.0 compat folder? It's not easy to override since gutenberg_get_block_templates isn't a class method. If anyone has an idea for a better approach that would be great.

This might be an overly obvious answer, but why not target the pull request at core instead of the plugin? I understand the reasons for testing out new features in the plugin, but it seems like a square peg in a round hole in this case. I opened a similar pull request at WordPress/wordpress-develop#2179 (I think it's less ambitious than this one) and it's targeted at core because it just seemed simpler to do it that way, and I also opened a trac ticket for good measure.

[jameskoster]

Should this work for templates and template parts? In my testing I found it worked only for template parts, so I'll concentrate on that for now.

I edited the Footer template part in my "Minerva" theme. Here's what I see on the Template list:

I then switched to Twenty Twenty-Two, and now see;

Should we make it clear what theme these template parts came from?

Yeah, it might be better to state the origin theme rather than the template author. A couple of other thoughts:

In my example above, both themes supply a footer template part named 'Footer'. When I switched to 2022 I could only see the customised footer from the previous theme, I expect this is because both parts had the same name or slug. This implementation prohibits me from using both footers on my site, which seems like a potential user need. Is there any way to make both available? I appreciate this may not be trivial because we then need to determine which version to use in the 'new' templates, but it seems quite important?

Tangentially to the above; while I think this is a fantastic feature, it does kind of go against the decade long expected experience where switching themes replaces all templates. Should there be a prompt on theme switch, asking the user if they want existing template parts to persist? This could help with the clutter issue @carlomanf mentioned by enabling folks who are looking for a clean break to discard all their current templates. It also educates that templates can now be portable across themes.

[scruffian]

@jameskoster let me try to explain technically what is going on here, as I think it might help to inform some of the design questions. (sorry if you already know all this but I just want to be clear :) )

In block themes, templates are loaded from HTML from. When you edit a template in the site editor, we save a copy of the template in the database and then these templates are loaded from the database. When you switch themes we stop loading the templates from the database and fetch them all from the files of the new theme.

The reason you are only seeing some of the templates from your previous theme is that you'll only see the templates that were edited - this also explains why you see "Added by admin" next to them. I wonder if we really need two columns here now - one to show which theme the template originated from, and another to show who edited it? or maybe when it was edited?

I don't think it would be a good idea to show all available templates from all themes (at least not without significant changes to this interface) as you might have 10 themes and each one with 5 templates. I can see that in the future that would be useful direction though - we'd just need a different interface to navigate them.

This PR doesn't actually change anything about what happens when you switch themes, except that you'll see more options for templates. Do you think that is a big enough change to warrant adding a theme switch prompt?

[scruffian]

but why not target the pull request at core instead of the plugin?

The main reason is that we'll be introducing a fairly significant UI change, so I'd rather do that in the plugin first.

[mtias]

Thanks for starting this! It's a fundamental step towards decoupling templates form themes. I think we should focus first on two of the biggest pain points: custom page templates and modified template parts becoming inaccessible upon theme switching.

These are the ones that have dedicated UIs for "using" them so they benefit immediately from inclusion. Custom page templates can be assigned in the page editor and template parts can be inserted or replaced in templates. We can leave other dynamic templates (archive, category, etc) on hold until we have a better UI for dealing with which one might be active. We might need to group things differently, indicate you have multiple variations of one of them, etc.

[jameskoster]

I wonder if we really need two columns here now - one to show which theme the template originated from, and another to show who edited it?

We may need to rethink this page a bit in the future. For now displaying the origin theme name seems to be more useful than displaying who customised the template part in question.

Unpacking things a little more from my example above... after switching themes if I delete my old theme's customised Footer template part, the new theme's Footer seemingly appears out of thin air. I think there is potential for confusion there, which is why displaying both in the template list might be preferable.

It may also be confusing that the theme I just activated defaults to using my old themes template parts. I understand why this is useful some of the time, but it is not a certainty, I don't even know if it should be the default which is why I mentioned a prompt on theme switch before. Imagine you just browsed a theme demo, liked what you saw, and activated that theme only to find that the header and footer haven't changed to match the demo. Is it sufficiently obvious that the 'fix' for this issue is to delete the old theme's header and footer? 🤔

[carlomanf]

It should be noted that the unrestricted approach being floated here was actually the pre-existing behaviour until late 2020, and it was changed for a reason. I agree with @mtias that it would be better to target the specific pain points, which is what my open pull request WordPress/wordpress-develop#2179 does, than open up everything.

[carolinan]

Not a code review

Works as described for template parts (Not for theme templates or custom templates).

For now displaying the origin theme name seems to be more useful

I felt the same.

the theme I just activated defaults to using my old themes template parts.

Is this accurate? Because I did not notice this happening.

[scruffian]

Is this accurate? Because I did not notice this happening.

That's not the behaviour I see either.

[jameskoster]

Doesn't seem to be happening now :)

This is still an issue though:

after switching themes if I delete my old theme's customised Footer template part, the new theme's Footer seemingly appears out of thin air. I think there is potential for confusion there.

If possible, when template parts from different themes share a name, we should list them separately in the template list.

[ndiego]

@scruffian is this still something we are trying to land in 6.0. If not, I will remove from the project board. Thanks!

[mtias]

@ndiego fine to remove from project board, the remaining work would be for a x.x.1 release or (more likely) 6.1.

[scruffian]

Closing this old PR.