Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#53424 closed defect (bug) (fixed)

remove_theme_support doesn't restore back to classic widgets editor

Reported by: kevin940726's profile kevin940726 Owned by: desrosj's profile 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
2 years 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 2 years ago by caseymilne (previous) (diff)

#2 @jamesros161
2 years 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 2 years ago by jamesros161 (previous) (diff)

#3 @noisysocks
2 years ago

  • Milestone changed from Awaiting Review to 5.8

#4 in reply to: ↑ 1 ; follow-up: @kevin940726
2 years 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
2 years ago

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

#6 in reply to: ↑ 4 @noisysocks
2 years 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
2 years ago

  • Keywords has-patch added

#8 @Mamaduka
2 years 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 2 years ago by Mamaduka (previous) (diff)

#9 @audrasjb
2 years 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
2 years ago

I agree with @audrasjb and the PR looks good too

#11 @hellofromTonya
2 years 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
2 years 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
2 years ago

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

#14 follow-up: @desrosj
2 years 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
2 years 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
2 years 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
2 years 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
2 years 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.