remove_theme_support doesn't restore back to classic widgets editor

[kevin940726]

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.

[caseymilne]

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.

[jamesros161]

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

[kevin940726]

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.

[noisysocks]

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.

[Mamaduka]

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.

[audrasjb]

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.

[zieladam]

I agree with @audrasjb and the PR looks good too

[hellofromTonya]

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

[hellofromTonya]

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.

[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.

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

[desrosj]

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.

[desrosj]

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.

[desrosj]

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.

[desrosj]

In 51215:

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

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

Trac ticket: https://core.trac.wordpress.org/ticket/53424