Site Editor: add option to disable templates

[annezazu]

As part of the FSE Outreach Program's Build a Block Theme exploration, the following was brought up:

How the heck do I delete pre existing templates? Such as Two Page templates Page (Large Header) and Page (No Separators). As well as the extra Single Post (No Seperators) template.

Right now, when you install a block theme, there's no option to delete or disable current templates. You can only delete custom templates or reset customizations to current ones. This is because template files that are bundled with your theme are not stored in the database. For folks building block themes or even switching between block themes with a desire to mix and match, this becomes a more important flow to unlock. This inherently relates to https://github.com/WordPress/gutenberg/issues/25071 in that it's another use case around it in many ways afaik.

[paaljoachim]

Thank you for creating this issue. Anne!

Hey James @jameskoster I believe we have mentioned deleting templates in a few issues. Not sure where they are right now.

[paaljoachim]

Actually it would be helpful to disable a template first, and then either restore or delete the template as another step.

[jameskoster]

A couple of thoughts on this...

What is the motivation for disabling templates? The quote in the OP refers to $custom templates which I interpret as a desire to hide templates that are not in use. Is there more to it? If we make all templates disable-able, then what happens on the frontend if you disable all of them?

The nomenclature is becoming a little verbose, we'd have:

• Reset (clear customizations)
• Delete
• Disable

Which all amount to roughly the same thing. Can we simplify?

[paaljoachim]

This is what I think.

Different states. Normal - working order. Disable - as if placing the template into the trash bin. Delete - as if emptying the trash bin.

Reset - should instead be added to a template revisioning system. So that one can explore revisions go one step back or select to reset.

Site needed templates - A question comes up should the user be able to disable and then delete these? Should users only be allowed to first disable custom and for instance home/index/blog page template. Having to use atleast one of these for blog post previews. As templates are disabled one can see which ones are strictly needed for the operation of the site. Then delete or restore back to normal working condition.

So if we remove Reset from templates and just have it under Revisions. Then we are left with Disable (testing to see how a site works without a specific template) and then Delete if the user chooses to do so.

[zu]

I love the idea of being able to disable templates (and of course also to delete them). But being able to disable first would allow to see the template hierarchy in action by disabling a more specific template (not only custom templates). I find it easier to go with lesser templates and clone and adjust when needed then to see a choice of different templates in a theme and must figure out why they're even here and what's the difference. Disabling make the learning experience via existing theme much more advanced.

[jameskoster]

To answer my own question, one motivation is when a theme includes a template like Front Page but you want to use a different template for the site homepage. The only way to achieve this currently would be to manually delete Front Page from the file system. This is too technical, and of course it will return when a theme update is installed.

I still think we'll need some affordance to stop all templates being disabled and breaking the site. It could be something as simple as prohibiting Index from being disabled.

[Olein-jp]

While creating a Block Theme in the Site Editor, we encountered an issue where the template could not be deleted from the Site Editor.

The above mentioned idea of deactivating and deleting is something I also found to be very brilliant. It's an idea that users are already familiar with through the WordPress plugin system.

Certainly removing files from the editor and file navigation would solve the problem, but I don't think it's an essential solution to encourage a wide user base to create or customise block themes in the Site Editor.

I am very much looking forward to the resolution of this issue here.

[annezazu]

Update on this effort that there were some designs shared recently around a disabled template flow: https://github.com/WordPress/gutenberg/issues/36951#issuecomment-1674411656 I've connected the two issues at this point and am adding this to 6.4 for good measure as it relates to TT4.

[jameskoster]

I asked this in 36951 but worth bringing up here too; conceptually, disabling a template is going to be very similar to making it a draft. Is it worth leaning into that less technical and more familiar language here?

Instead of disabling/enabling a template, you can make it a draft/publish it. The UI could be aligned with the one for updating a post/page status, and it could potentially pave the way for scheduling and other status changes.

[jasmussen]

One way to build a theme is to install a Twenty theme, customize it to your liking, and save it as a new theme. Deleting templates to change the default behavior, or to just slim things down if you don't need multiple archive view types, feels entirely valid. Especially as, in the future, it will become possible for templates to detach from a theme, at which point you can delete and create templates to your own liking.

To that end, it makes sense, "disable" should be thought of as a bandaid because you can't delete from an existing theme. Or to frame it differently, it's the button that takes the place of the "delete" button.

To that end, the disable button could sit exactly where the delete button is for custom templates. Perhaps it can move all disabled templates under a subheading?

[jameskoster]

Eventually bandaids are removed. Will that be the case here—will it ever be possible to delete theme files? My assumption was no.

If the intention is to make theme files deletable then I agree. Otherwise it feels more like a status to me.

Worth noting that you may also want to temporarily disable a template you created yourself.

[jasmussen]

Eventually bandaids are removed. Will that be the case here—will it ever be possible to delete theme files? My assumption was no.

I guess that's valid enough, though the nuance probably is that it will eventually be possible to entirely detach a theme from the theme files, saved only into the database. In such a detached theme, you should be able to delete files. Presumably you could also download a zip, upload it again, in which case it would become manually "attached", as it were.

[jameskoster]

Worth noting that you may also want to temporarily disable a template you created yourself.

Just wanted to note how important this is. Templates are automatically enabled as soon as they're created. So when you create a Front Page template the appearance of your site homepage is changed immediately – before you even had a chance to edit the template! For a new site in development this isn't a big deal, but for an established site that's not the case.

This is the main reason I like the draft/published language rather than enabled/disabled. It effectively allows the creation of draft templates, which feels a bit more natural to me versus creating a template in a 'disabled' state.

[annezazu]

Punted after no efforts have been made here to move this forward.

[colorful-tones]

Hi folks, We are only one week away from the Beta 1 cut-off date for WordPress 6.6. This issue hasn’t seen any movement in a while, so we (the editor triage leads of the 6.6 release) have decided to remove it from the WordPress 6.6 Editor Tasks project board.

[sdwire]

Here's another concrete motivation for wanting to disable templates.

Blockbase is supposed to be a super minimalist parent for custom child themes. And Blockbase has many, many variations available as templates for headers, patterns, etc. And many of them look very similar. That's useful when initially beginning the design of a website, but it becomes confusing and encourages errors once that website moves into maintenance. Those who build new page templates when they add a feature a year from now will have to know which of the myriad of header templates was actually chosen for the website design.

I'd like to be able to 1) start a new website design with Blockbase, 2) customize the fonts, colors, templates etc. that I want to make available to the site maintainers, 3) use the "Create Block Theme" plugin to lock in my design decisions into a child theme, and then 4) disable the parent Blockbase templates (especially the proliferation of headers) that are NOT part of that website's design.