Add disable FSE theme support flag #30760
Conversation
MaggieCabrera
added
[Feature] Themes
MaggieCabrera
requested review from
spacedmonkey and
TimothyBJacobs
as code owners
|
Thanks for the PR. That said, this needs a bit more context, why do we want to do that, what do we want to disable exactly here since FSE also means block based themes? Also, we've been moving away from theme support flags, if we want to introduce config, theme.json is probably the best way. |
|
Size Change: -776 B (0%) Total Size: 1.47 MB
ℹ️ View Unchanged
|
|
Thank you Riad. The context is this: In the meantime if we build only block-based themes then most users will not have access to these new themes. If we build only classic themes then... eww. With this flag we could then build themes that target the general population and allows us to build themes the "new" way. Decoupling how themes are built and how themes are customized allows us to build themes that are useful in the FSE, and also useful in the classic environment without building the same theme twice. There are of course other obstacles to overcome and known limitations but this gives us the option to move forward with that possibility. Flagging that option in theme.json would certainly be a fine way to do this. If we were pointed toward an example of that being done then we would be happy to refactor. |
|
👋 In terms of global styles, themes can use the theme.json mechanism independently from any other feature: as long as there's a theme.json, the mechanisms that pass configs to the editor and embed a global stylesheet work. There doesn't seem to be any difference for global styles with or without this flag. Is there anything particular you'd like to work differently? |
|
The ability to use block based templates to build a theme is what we are attempting to separate from a dependency on the full site editor. |
|
Have you tried using |
|
The idea is that a theme may want to have control over what tools the user has to customize their site. There are a few scenarios where this flag could be helpful, such as:
Potentially this flag would not be needed in the future, but we think it's a good tool for the transition period until we get there. I should have explained a bit better my PR, we just wanted to put this out there to encourage this conversation and the implementation of course may not be ideal. I'm happy to explore this as an option on theme.json of course. |
|
I think there's value in having the theme control what UIs to be shown to the user but right now these UIs are still in flux though, so it's going to be hard to come up with the right flags/configs (site editor might not exists as is according to the latest designs) and having a global Curious what @mtias thinks here as well. The other hidden question this PR raises is that you want to start building production block-based themes. While I think we're very close to that, this raises the question about the maintainability of the existing APIs. What happens if we decide to change how block templates are written or break any API. At the moment, these are experimental things and soon to be stabilized but what would be your expectations here? |
|
Tagging @Sandstromer, because reading this reminded me of a comment they left on another issue about "crippleware" themes. |
Yes, that's exactly it. At some point, we need to start getting these themes in the hands of users and the way to get there is not a black or white, take it or leave it, here's the new way of editing themes, so I think it's really important that we have this conversation and I think we are about that time. I'm also curious about what @mtias thinks after our talks about universal themes, since that is what we were trying to approach with this PR, what would be a good way to leverage those kinds of themes. In terms of the APIs, I totally see your concern and I know it may be too early to decide the form those would take place, but it's also an important conversation. The way I see it, some themes may want to surface GS to the user. Some may want to hide it, some may want to show just the template editor or neither. Those could be options on theme.json and I think they are valid options to have for themes in the future (when FSE is stable and adopted by the public) for corporate themes that may want to control what can be edited by users or not, so it's still a valid tool. |
|
I am still trying to understand (not judging). You want to build a block theme with the HTML templates and theme.json, but you do not want: So basically, all benefits and no worries about confused users? Like a standard theme before we had widgets and customizer options. Except how would they add menus? |
They would have access to the customizer and they could add the menus there. This is not meant for full-fledged block themes, but more as a transitional thing, where not all the aspects of the theme are ready for FSE or in cases where changing the UI would confuse the users. Think about having a classic theme and you want to handle a few templates using blocks, but not all of them, or add some GS using theme.json without rebuilding the whole thing. Or think about building themes that will soon be ready to take advantage of FSE but you want to have control about the moment when your users will have access to those tools. |
|
I think it is too soon to determine what both users and theme authors need 🤔 and that we should focus on improving the template workflows. The risk of adding this is that developers will use it as an excuse to postpone learning about the changes, instead of getting involved. |
How come? they won't need this flag if they are not already using FSE templates. And if they are, then they are already getting involved. |
|
Then I still don't understand. |
|
For a transition we can have mixed templates already... <?php echo do_blocks( file_get_contents( 'templates/page.html' ) ); ?>Using something like that in a "classic" theme will allow theme-authors to use HTML templates, without exposing any of the UI to users. Then, when the theme-author feels that FSE is at a stage where they can expose the UI to users, they just rename the |
My understanding is that |
It's not exactly because of |
Having that would definitely make this PR irrelevant, I wasn't aware of the constraints, thanks for pointing them out. |
|
I think it's worth bringing up template locking in this discussion and when that may be available: #29864 If we had a mechanism via the theme.json to lock the templates entirely, I would feel less strongly about having a way to disable the site editor. |
|
Per some discussion I have refactored this to leverage theme.json settings instead of a theme_support flag. Would be the addition to the |
MaggieCabrera
force-pushed
the
add/disable-fse-support
branch
from
0e0bcda to
6db9a5a
Compare
|
If we imagine that we have themes which are capable of being used in the Customizer or the Site Editor (which is our hope), I think it would be useful to have some kind of toggle in the experiments section of the Gutenberg settings to enable/disable the Site Editor. |
Description
Made FSE optional via a theme support flag so that block-based themes can be used in a classic environment.
How has this been tested?
Added the
add_theme_support( 'disable-fse' );flag to a block based theme (such as Empty Theme)Screenshots
Types of changes
New feature (non-breaking change which adds functionality)
Checklist:
*.native.jsfiles for terms that need renaming or removal).