Replace the widgets screen experiment with a theme support #24087
Conversation
youknowriad
added
the
[Feature] Widgets Screen
youknowriad
requested review from
spacedmonkey and
TimothyBJacobs
as code owners
youknowriad
added
[Type] Feature
gutenberg.php
Outdated
| @@ -181,3 +184,5 @@ function register_site_icon_url( $response ) { | |||
| } | |||
|
|
|||
| add_filter( 'rest_index', 'register_site_icon_url' ); | |||
|
|
|||
| add_theme_support( 'block-based-widgets' ); | |||
There was a problem hiding this comment.
The support is enabled by default in the Gutenberg plugin to bring visibility to the feature and get more testing, but in Core it could be made opt-in instead of opt-out.
There was a problem hiding this comment.
Can we rename it to something like "widgets-block-editor"?
|
Size Change: 0 B Total Size: 1.16 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
I like this idea! I tested it locally and it works great.
I am approving but a second opinion might be worth it considering we're hijacking the widgets link in the Gutenberg plugin to point to an experimental screen.
Going back to the old screen would mean I have to disable the Gutenberg plugin?
Alternatively, you could do |
|
Requiring the theme to opt-in for this feels like a safe step in the right direction, especially if we're replacing the Widgets screen entirely. Without theme support
With theme support
|
|
One problem with this is that if a user switches away from a theme that supports block widgets, then goes to the (old) widgets screen and clicks Save, they will lose any blocks that were stored. See #24267. A question I have about making this "opt-in" is: What about old themes that rarely receive updates? I imagined that a requirement of the blocks in widgets project was that it would let users add blocks to their site no matter what theme they're on. |
It's still a question to be addressed but I have doubts that we'll be able to make it work regardless of the theme and widgets used thus the opt-in choice.
This is a good question and one that we'd need to solve regardless of how the screen is enabled. I'd like for this feature to get more exposure and for us to give more priority to solving these issues. |
In explorations with @adamziel we wondered if the path to the widget editor is reversible. Maybe as @mtias suggested we could add in the classic editor plugin, or in some other plugin, the possibility to revert to the old screens (both for navigation and for widgets). However, are they mutually exclusive? In my opinion they should be, as in if you switch back there should be no guarantee that you can easily continue where you left off. However @adamziel suggested in this thread, that by following the current data structure there won't be any issue to just move between the two screens at any moment, which is a nice to have. I like this PR because it allows us to put these new editors in the hands of community developers before they're ready to be shipped with the plugin. They could test this and see where things can be improved. It also does not change anything about the future when we merge the new editors: when that happens the opt in is NOT to get the new editor, the opt in is to enable the new editor to allow blocks next to menus or widgets. This PR is only interesting at this stage. After the merge everyone will get the new editors but only the opting in themes will allow blocks to be used. |
|
It'd be nice to also use |
youknowriad
force-pushed
the
update/widgets-screen
branch
from
dc0453c
to
fbe9250
Compare
youknowriad
force-pushed
the
update/widgets-screen
branch
from
bd157b1
to
3b99fa6
Compare
|
Merging this based on the last discussions on #core-editor chat. |
|
💥 |
closes #24685
The idea at the moment is to try to ship the new block-based widgets screen in 5.6. If we want to make this a reality, we need more testing and a more stable implementation.
This PR does a few things to help with that: