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.