FSE: Add a filter to determine whether a theme should use the Site Editor #31235
Conversation
|
Size Change: 0 B Total Size: 1.39 MB ℹ️ View Unchanged
|
scruffian
changed the title
scruffian
changed the title
|
What kind of conditions are you thinking of, that would have the filter return false? The presence of content in the theme's widget areas and menus? An option that the user can control? Is it maybe even worth revising the default condition, because especially for hybrid themes that have a mix of block templates and PHP templates, the mere presence of |
|
But this is not correct? If a theme wants to use the Site Editors, it needs to have template in the block-templates directory The site editor is not planned to be merged as is neither in 5.8 or 5.9 right now, so is the goal only to disable this when the plugin is enabled? |
Yes that's right. If I am running the latest Gutenberg I might still want to opt users out of the Site Editor.
These are some options. I might also want to do it for new users but not older ones. Or Admins only etc. |
|
Maybe instead of adding a new filter, we should examine where |
|
But themes are already "opting out" of the site editor by not adding the index.html template. If a theme wants to use the Site Editor, it needs to have template in the block-templates directory, The use templates but not the site editor, use the template editing mode to create and edit templates. |
|
I want the freedom to do both without changing my theme's code. If I include block templates in a theme which is running the Gutenberg plugin, then I am forced to use the Site Editor. I want to be able to turn it on/off without updating the theme. |
|
I think I see what you're trying to do, but the implementation is a bit confusing. What about the following as an alternative approach:
I think the effect is the same as what you are doing with the filter, but hopefully it's more intuitive for theme developers to make sense of, because it's just two theme supports where one is a subset of the other. |
|
I want to be able to turn it on/off without updating the theme. Themes would still need to be updated to use new filters or new theme support. Is the problem not that the menu items for the widgets and customizers are hidden? Then revert that change? |
I was also confused at first, and I don't think the openers of the issues explained it very well. The way I'm thinking about it now is it just allows the editing mode to be controlled with a switch, rather than having it pre-destined by the structure of the theme. The switch could be operated by themes, plugins or core. |
Exactly, filters can be modified by a plugin as well as a theme. The theme could also expose an option to the user to give them the ability to switch between the Site Editor and the Customizer. |
I don't think we can do that because we don't want to expose users to the customizer/widgets at the same time as the Site Editor - it should be one or the other but not both. |
There was a problem hiding this comment.
Exactly, filters can be modified by a plugin as well as a theme. The theme could also expose an option to the user to give them the ability to switch between the Site Editor and the Customizer.
I think that this fact makes the proposed approach preferable to relying solely on theme support (even though theme support checks could be used in gutenberg_is_fse_active function I mentioned above).
| @@ -11,7 +11,8 @@ | |||
| * @return boolean Whether the current theme is an FSE theme or not. | |||
| */ | |||
| function gutenberg_is_fse_theme() { | |||
There was a problem hiding this comment.
Maybe some confusion is stemming from the fact that we are using this function to gate FSE features/functionality in different places. Would gutenberg_is_fse_active with a filterable return be a more appropriate name? It could even wrap the existing gutenberg_is_fse_theme function, theme support checks, and in general allow for more complicated checks in the future if needed.
Plugins can add and remove theme support as well. Although I like the idea behind this branch, I'd be disappointed if it were merged in its current form, because it's a complicated mix of theme supports, filters and boolean functions that could be greatly simplified as I explained earlier. |
|
So I have been thinking and discussing this more with folks, and here's my current understanding:
I can now understand more the need for a filter for "force" these hybrid themes to behave as classic themes even if they are also FSE themes. In other words, I think instead of a filter that is called I'm also uncertain whether that filter should land in Core, I mean once FSE themes are in Core, hybrid themes should just behave as FSE themes. |
#31633 is related. |
|
Thinking a bit more about this. Essentially what we want is to is to prevent the theme from using the block editor while it's still under development inside the Gutenberg plugin, but be ready to use FSE once it's launched in core? If that assumption is correct, then whatever we pick should be marked as We could use:
And then check for whichever method we use inside of |
|
We need a way for a theme to manage turning on/off full site editing |
I very much agree with these. Splitting a theme into two development flows to support both classic and FSE is an unnecessary overhead for theme developers. The filter proposed here would let users just flip a switch to choose their preferred experience, without having to go out and pick another theme — which is arguably a very confusing UX.
This sounds reasonable to me. I don't have a strong opinion between EDIT: what would happen if the filter was used in the opposite way, to force enable FSE on a non-FSE theme? |
Not that bad! The frontend is unaffected, and the Site Editor simply fails to load. (Tested with Twenty Twenty and a simple The fact that the impact of a false positive is pretty limited and that it opens up the path towards transitional/universal themes makes me think that there's little reason against this, and many reasons for it. And it would allow somebody to make a "Classic Themes" plugin akin to the Classic Editor plugin for all those who hate and fear change. It would be as simple as: add_filter( 'gutenberg_is_fse_theme', '__return_false' ); |
|
A "universal theme" is just a theme that's capable of running in both environments without separate bundles and should not mind in the least which one gets used. It should not be a concern of the theme to have to choose or manage the context in which it gets loaded. Whether WordPress needs a way to filter out the site editor is a separate consideration — it might look the same (as in, a theme can still access those mechanisms) but is quite different conceptually. It is important that this doesn't become entangled with themes because that will create a cascade of complexity with themes managing the experience in different ways, which will result in inconsistencies. For this reason, we should begin by identifying exactly the scenarios where such a setting would be toggled and then reason about its implications. (For example, it could be a wp-config constant.) |
|
One scenario in which this toggle would be useful is to run block themes on a site where we don't want to enable the site editor. With the Gutenberg plugin we could launch sites with block themes today, but we might not want users to be opted into the Site Editor. |
|
Wouldn't "not run the site editor" be the equivalent of "don't run the gutenberg plugin"? That use case is very clearly unrelated to the nature of the theme and more about controlling WordPress functionality, so the filtering |
No I don't think so. For example if I want to use a block theme then I want to use the Navigation block which means I need Gutenberg installed, since its not shipping in 5.8, but that doesn't mean I want to enable the Site Editor. I do agree that this might not be the best place for the filter. What do you think about adding a checkbox for the Site Editor in the experiments page of Gutenberg? |
|
Just making sure we take this into account: |
|
The navigation block not being present in core is a temporary measure, we should not introduce a filter (that people would use and establish a contract with) for something that is transient. A setting in the experiments page could make sense, but a lot depends on where #29630 lands, as "site editor" might not be a single thing. If there's a huge need in the interim perhaps we can have a filter named |
|
@scruffian I think we can close this! |
|
Yeah, good idea |
Description
This is a different approach to #30760.
A universal theme should work with both Classic site editing tools (Customizer/Menus/Widgets) or the new Site Editor. If a theme wants to use the Site Editors, it needs to have template in the
block-templatesdirectory, so to enable FSE for a universal theme, changes would be necessary to the theme file structure. This filter allows themes to opt out of the Site Editor by changing the value it returns, without having to move files around. This would allow us to enable/disable FSE for particular users/themes as we need without updating themes themselves.How has this been tested?
Screenshots
Types of changes
New feature (non-breaking change which adds functionality) -->
Checklist:
*.native.jsfiles for terms that need renaming or removal).