Remove the classic widgets panel only if the theme did not opt out of the new editor #25415
Conversation
… new widgets editor
adamziel
requested review from
spacedmonkey and
TimothyBJacobs
as code owners
adamziel
changed the title
adamziel
requested review from
youknowriad,
kevin940726,
talldan,
azaozz and
draganescu
|
Size Change: 0 B Total Size: 1.2 MB ℹ️ View Unchanged
|
|
I think this theme support flag is a temporary step, the real solution is via the Classic Editor plugin which can work using the standard panel removal procedure |
|
@draganescu do you meant that the "widgets" panel should be removed when the classic editor plugin is not installed? |
|
I am not sure of this, but my initial understanding of this was that the optimal way to opt out was to make it an option in the Classic Editor plugin. This pr makes it so that when you enable the Classic Editor you end up with the classic widgets editor as well. The problem is it still uses the theme supports. If the theme supports is too late for the customiser we should make it so that feature of the Classic Editor ALSO calls customize_loaded_components. IMO, there is no real reason to have a theme supports flag. "Supports" is by definition meant fo opt-in! Opting out of the widgets editor should be via plugin - how the plugin does it is a separate subject. We ended up having one simply because the Classic editor was not ready with the opting out feature and we should deprecate it ;) |
|
Blocked by #25625 |
|
This is not blocked anymore, as the work on the embedded block editor progresses we need to disable it when the block widgets editor is disabled. |
|
We're moving the old panel using gutenberg/lib/widgets-customize.php Lines 29 to 36 in c62ccd8 |
Description
Solves #24949 in a very non-elegant way. Let's talk.
The problem is that:
customize_loaded_componentshook.remove_theme_support( 'widgets-block-editor' )in response toafter_setup_themeaction.customize_loaded_componentsis fired before the theme'sfunctions.phpis even loaded!This PR calls
$wp_customize->remove_panel( 'widgets' );instead, the problem is that it's discouraged and generates a warning since WP 4.5:"Removing widgets manually will cause PHP warnings. Use the customize_loaded_components filter instead."
https://core.trac.wordpress.org/ticket/35242
It makes sense - the design seems to assume that all the panels not removed via
customize_loaded_componentsare assumed to stay, there may be some core, plugin, or theme code relying on that behavior.It seems like relying theme support is not going to work for removing the
widgetspanel. We could either not rely on theme support and figure out a different solution, or remove the panel after the fact and suppress the warning.CC @draganescu @noisysocks @kevin940726 @talldan @youknowriad