WordPress.org

Make WordPress Core

Opened 7 weeks ago

Closed 6 weeks ago

Last modified 6 weeks ago

#53424 closed defect (bug) (fixed)

remove_theme_support doesn't restore back to classic widgets editor

Reported by: kevin940726 Owned by: desrosj
Milestone: 5.8 Priority: normal
Severity: normal Version:
Component: Widgets Keywords: has-patch commit
Focuses: Cc:

Description

Originally reported in this Slack thread: https://wordpress.slack.com/archives/C01D71823PB/p1623817790191900.

As documented here: https://github.com/WordPress/gutenberg/blob/trunk/docs/how-to-guides/widgets/opting-out.md#using-remove_theme_support, remove_theme_support( 'widgets-block-editor' ) stops working from restoring back to classic widgets editor.

Change History (19)

#1 follow-up: @caseymilne
7 weeks ago

Could you elaborate on the steps to reproduce or provide more detail about what we should expect to see? The hook remove_theme_support( 'widgets-block-editor' ) only removes Widget Block Editor. Does it not do that? Or are you testing for classic editor? Because the documentation appears to indicate we need to install the Classic Widgets Editor plugin separately to restore the class widgets editor.

Last edited 7 weeks ago by caseymilne (previous) (diff)

#2 @jamesros161
7 weeks ago

I am having similar issues. In testing our theme for 5.8 issues, I found that the custom controls we added to the widgets-meta are no longer showing in the Gutenberg widgets block editor, so I decided to opt-out in our theme's configuration by using remove_theme_support( 'widgets-block-editor' ) so that the traditional widgets editor would show inside the customizer. this is run inside of a function hooked to after_setup_theme. However, the Gutenberg editor is still being used inside the customizer.

I have also tried using add_filter( 'gutenberg_use_widgets_block_editor', '__return_false' ); according to the instructions here: https://developer.wordpress.org/block-editor/how-to-guides/widgets/opting-out/ but that doesn't work either.

I can confirm that this DOES work if the remove_theme_support() is added to an init action, rather than after_setup_theme action

Last edited 7 weeks ago by jamesros161 (previous) (diff)

#3 @noisysocks
6 weeks ago

  • Milestone changed from Awaiting Review to 5.8

#4 in reply to: ↑ 1 ; follow-up: @kevin940726
6 weeks ago

Replying to caseymilne:

The hook remove_theme_support( 'widgets-block-editor' ) only removes Widget Block Editor. Does it not do that?

No, it doesn't do that in my testing.

Because the documentation appears to indicate we need to install the Classic Widgets Editor plugin separately to restore the class widgets editor.

I believe this is not true though. The documentation indicates that one of the three methods mentioned should work independently.

Testing instructions:

  1. Add remove_theme_support( 'widgets-block-editor' ) to a theme in a after_setup_theme action.
  2. Go to Appearance -> Widgets.
  3. Should see the classic widgets editor rather than the widgets block editor.

Replying to jamesros161:

I have also tried using add_filter( 'gutenberg_use_widgets_block_editor', 'return_false' ); according to the instructions here: https://developer.wordpress.org/block-editor/how-to-guides/widgets/opting-out/ but that doesn't work either.

This doesn't work for me either. I believe this is a bug in the documentation. We need to update the filter to be add_filter( 'use_widgets_block_editor', '__return_false' ); instead, which works for me.

#5 @noisysocks
6 weeks ago

  • Owner set to noisysocks
  • Status changed from new to accepted

#6 in reply to: ↑ 4 @noisysocks
6 weeks ago

I've opened a PR which should fix the issue: https://github.com/WordPress/wordpress-develop/pull/1382

This doesn't work for me either. I believe this is a bug in the documentation. We need to update the filter to be add_filter( 'use_widgets_block_editor', '__return_false' ); instead, which works for me.

The docs look right to me. add_filter( 'gutenberg_use_widgets_block_editor', '__return_false' ); is correct. I think Trac maybe messed up the formatting.

#7 @noisysocks
6 weeks ago

  • Keywords has-patch added

#8 @Mamaduka
6 weeks ago

I think the initial placement of add_theme_support( 'widgets-block-editor' ) was correct, and we need to update our docs to use widgets_init instead of after_setup_theme.

The widgets support is added via register_sidebar, so doing something like this won't work as well:

<?php
add_action( 'after_setup_theme', function() {
        remove_theme_support( 'widgets' );
} );

I think themes can decide if they want to use the new Widget Block Editor when registering widget areas.

Last edited 6 weeks ago by Mamaduka (previous) (diff)

#9 @audrasjb
6 weeks ago

On another hand, and given most of the {remove|add}_theme_support functions are usually hooked into after_setup_theme (see Bundled themes as an example), I believe it would be really more discoverable for theme developers to follow @noisysocks’s proposal.

#10 @zieladam
6 weeks ago

I agree with @audrasjb and the PR looks good too

#11 @hellofromTonya
6 weeks ago

Testing Results

Env:

  • OS: macOS Big Sure
  • Browsers: Firefox 89.0.1 and Chrome 91.0.4472.106
  • Script used as a must use file (add to wp-content/mu-plugins/test.php
    <?php
    
    add_action( 'after_setup_theme', function() {
        remove_theme_support( 'widgets-block-editor' );
    });
    

Before patch

  • Yes, I can reproduce the problem

After patch

  • With the above must-use plugin => the classic widgets UI is restored.
  • Commenting out the must-use plugin => restores the widgets block editor

#12 @hellofromTonya
6 weeks ago

  • Keywords commit added

Reviewing the bundled themes:

  • add_theme_support() is wired to 'after_setup_theme'
  • 'widgets_init' is used for registering sidebars

I agree with @audrasjb. The approach in PR 1382 is consistent with how themes handle adding theme support vs how they handle registering sidebars.

Though this is dealing with adding theme support for the widgets block editor, it is a theme support. Having it hooked into 'after_setup_theme' keeps it consistent. The advantage here is consistency to help theme authors.

I've approved the PR. Marking this ticket for commit.

#13 @desrosj
6 weeks ago

  • Owner changed from noisysocks to desrosj
  • Status changed from accepted to assigned

#14 follow-up: @desrosj
6 weeks ago

I think it's also worth mentioning that there is precedent here for using the after_setup_theme hook since the traditional widgets screen require add_theme_support( 'widgets' ); and the historically accepted pattern there has been to use after_setup_theme.

The widgets-block-editor feature also needs to be added to the add_theme_support() docblock. I can handle that when committing!

#15 in reply to: ↑ 14 @desrosj
6 weeks ago

Replying to desrosj:

I think it's also worth mentioning that there is precedent here for using the after_setup_theme hook since the traditional widgets screen require add_theme_support( 'widgets' ); and the historically accepted pattern there has been to use after_setup_theme.

Oh actually I missed that this was already called out above but noted that it does not work. Today I learned you cannot remove theme support for widgets, menus, and editor-style in the same way you would other features.

#16 @desrosj
6 weeks ago

Some historical context around the inability to remove support for widgets: ticket:12739#comment:3.

Sorry for the multiple pings. I still think this is the right way, so going to commit.

#17 @desrosj
6 weeks ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 51214:

Widgets: Add support for the Widgets Editor on after_setup_theme instead of widgets_init.

This better aligns with developer expectations, as add_theme_support() and remove_theme_support() are meant to be called within functions attached to the after_setup_theme hook.

This also adds the widgets-block-editor feature to the docblock for add_theme_support().

Props kevin940726, caseymilne, jamesros161, noisysocks, Mamaduka, audrasjb, zieladam, hellofromTonya, desrosj.
Fixes #53424.

#18 @desrosj
6 weeks ago

In 51215:

Docs: Fix typo in widgets-block-editor feature documentation.

Follow up to [51214].
Unprops desrosj.
See #53424.

Note: See TracTickets for help on using tickets.