Proposal to use classic theme ( single theme ) either as complete FSE theme or classic theme ( with customizer )

[premanshup]

What problem does this address?

It is currently difficult to use the legacy theme as both legacy theme ( with customizer ) and FSE theme.

[Discussion] Hybrid themes: Templating hierarchies

#29024

In the above discussion, It is proposed that theme developers can create a hybrid theme.

If the HTML template is not added by theme for FSE, it currently fallbacks to themes PHP template.

I'm thinking of a scenario where users want to use a classic theme as a complete FSE theme or use the same classic theme as a complete classic theme with the customizer.

With hybrid themes, for HTML templates, the Header and Footer ( for example ) will load from HTML and where there is no HTML template it will load PHP header footer ( with customizer settings ). It may be a little inconvenient for the users to use both FSE features and customizer in a single site.

For example, If the classic theme has only implemented the front-page.html, only front-page.html gets overridden and other pages fall back to PHP templates. This may cause inconsistency across the website.

In case, theme authors want to support both the FSE and classic customizer-based PHP templates there is no option as far as I can see for users to select if the current theme should be completely FSE or should be completely a classic customizer based theme.

What is your proposed solution?

What I want to propose is classic themes can be used completely as FSE themes or as completely classic customizer-based themes.

Users would be able to add a filter to their child theme or theme authors can provide an option from where users can toggle and use the theme as a complete FSE theme or classic theme.

To achieve this I was thinking of introducing two filters:

1. Filter to update if the current theme has FSE support or not. ( this can be managed by theme authors by providing an option from where users can choose if they want to use the theme as complete FSE or complete classic theme with customizer ). Or users can themselves add the filter in child theme and convert the theme from FSE to customizer-based theme and vice versa.
   • Reference PR - https://github.com/WordPress/gutenberg/pull/35616/files#diff-4058342ce84fc16e02cdf0b544a1c3faf21b3b7f421aee9aee11e92983c9b172R14-R21
2. Filter to update if the current theme has a theme.json file or not. ( this can be again managed by theme authors using the same option where users can choose if they want to use theme.json or not ).
   • Reference PR - https://github.com/WordPress/gutenberg/pull/35616/files#diff-995eb1403df37ca3ca196d6198be899a73dbf5e3aba8fec149c0f1ff1d330935R372-R379

Why am I concerned about the theme.json file?

• Firstly, I think it would be better to separate out the theme.json file for the FSE theme and for the classic theme. I just want to make sure that there will be no conflict between theme.json which will be primarily coded to support FSE theme functionality and classic theme.
• Secondly, if the user will use the theme as a classic theme with a customizer, theme.json will have code related to the FSE theme which may not be useful when loading the theme as a classic theme. This can cause confusion among theme developers and users. Anyways, both the filters I have mentioned are separate from each other. So the theme developers who want to avoid loading theme.json when the theme is loaded as a classic theme can do so by using this filter. Since this filter is independent if they wish to load the theme.json file for both classic theme and FSE theme, they can do so by not using the filter ( by default theme.json will be loaded ).

I have added these two filters in this PR - #35616

Using these filters, users can completely switch the themes from classic to FSE and vice versa.

I would appreciate any feedback on this.

My apologies if I'm missing anything here or if I'm completely off here. Thank you.

[aristath]

Hey there @premanshup!

I don't think that having a "switch" would be the best option...
It is possible for a theme to start migrating its structure from "classic" to block-based.

The HTML templates are a starting point, but it's also possible to override the HTML templates with custom templates. With that in mind, a theme can create migration routines and start migrating their users to the new structure.
New users: They get the default HTML templates from the files.
Old users: The theme can get their customizer options, and create the custom templates as-needed, create templates in the database which combine all the user's options.
A couple of years ago I did that in the gridd theme which had some routines to migrate customizer options etc to reusable blocks. Of course that is now obsolete, but the logic behind it is still solid and can easily be adapted to create templates and template-parts instead.

[premanshup]

Thank you for the insight and detailed information @aristath! I will definitely explore gridd theme migration. Though I have one concern, in case if users still want to use existing customizer options/hooks, the "switch" button could be helpful?

[annezazu]

@premanshup I'd recommend reviewing this discussion! #30496 For now, I'm going to close this out since it's not directly related to the functioning of the Gutenberg project. I'd recommend perhaps bringing this to the next block theme discussion in Make Slack for further thoughts if you need them :) More details about meetings can be found in the sidebar of this blog: https://make.wordpress.org/themes/