Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#54075 closed enhancement (reported-upstream)

Disabling legacy widget previews in the block editor

Reported by: eatingrules's profile eatingrules Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Widgets Keywords:
Focuses: ui, accessibility, administration Cc:


In the new Widget Block Editor, when a user clicks on a Legacy Widget the state shift to a different interface is a jarring user experience.

It is additionally confusing because the behavior is different than regular blocks in the same interface.

From what I've seen on multiple production sites so far, the previews aren't very accurate right now (though #53801 should help a lot), with width and height spacing issues being different than the front end.

Being able to preview widgets in the Block Editor is also not that important since they can be edited in the Customizer -- which actually does show an accurate preview.

Instead of trying to fix the previews (which may never be 100% possible), I propose we remove Legacy Widget Previews altogether.

If that's a nonstarter, we should at least give users the option to disable them -- and add a filter to do the same.

@costdev showed us a nifty trick to disable the widget previews via the DevTools console: I tried this and found that having the legacy widgets look & behave like old-style widgets made it more intuitive and easier to use.

Additionally, removing Legacy Widget previews will accelerate adoption of the new Widget Block Editor.

This will make the distinction between the new/legacy widgets much more clear, which will help both users and developers see the benefit in moving to new block widgets.

Note, too, that the very popular Genesis Framework has completely disabled the new Block Widget Editor, and I know of at least one other theme that has had significant issues with the new editor as well. So disabling Legacy Widget Previews may allow them to restore the functionality for their users and help further the adoption of the new editor.

Change History (13)

#1 @costdev
3 years ago

Here's an updated snippet as an example of how a toggle could look (entirely illustrative and by no means complete nor tested for coding standards etc!).

To view this:

  1. Go to Appearance > Widgets.
  2. Open DevTools (F12).
  3. In the console, paste the following and press enter:
const togglePreviewsBtn = document.createElement('button'),
      redoBtn = document.querySelector('[aria-label="Redo"]'); = 'toggle-previews';
togglePreviewsBtn.type = 'button';
togglePreviewsBtn.tabIndex = '-1';
togglePreviewsBtn.setAttribute( 'data-toolbar-item', true );
togglePreviewsBtn.setAttribute( 'data-hidden', 'false' );
togglePreviewsBtn.setAttribute( 'aria-label', 'Toggle Legacy Widget Previews' );
togglePreviewsBtn.classList.add( 'components-button', 'components-toolbar-button', 'has-icon' );
togglePreviewsBtn.innerHTML = '<svg width="24" height="24" viewBox="0 0 488.85 488.85" xmlns="" role="img" aria-hidden="true" focusable="false"><path d="M244.425,98.725c-93.4,0-178.1,51.1-240.6,134.1c-5.1,6.8-5.1,16.3,0,23.1c62.5,83.1,147.2,134.2,240.6,134.2   s178.1-51.1,240.6-134.1c5.1-6.8,5.1-16.3,0-23.1C422.525,149.825,337.825,98.725,244.425,98.725z M251.125,347.025   c-62,3.9-113.2-47.2-109.3-109.3c3.2-51.2,44.7-92.7,95.9-95.9c62-3.9,113.2,47.2,109.3,109.3   C343.725,302.225,302.225,343.725,251.125,347.025z M248.025,299.625c-33.4,2.1-61-25.4-58.8-58.8c1.7-27.6,24.1-49.9,51.7-51.7   c33.4-2.1,61,25.4,58.8,58.8C297.925,275.625,275.525,297.925,248.025,299.625z"></path></svg>';

redoBtn.parentElement.appendChild( togglePreviewsBtn );

togglePreviewsBtn.addEventListener('click', function() { 
    const legacyWidgets = document.querySelectorAll( '.wp-block-legacy-widget' );
    legacyWidgets.forEach( ( widget ) => {
        const form    = widget.querySelector( '.wp-block-legacy-widget__edit-form' ),
              preview = widget.querySelector( '.wp-block-legacy-widget__edit-preview' );

        if ( 'true' === togglePreviewsBtn.dataset.hidden ) {
            form.setAttribute( 'hidden', true );
            preview.classList.remove( 'is-offscreen' );
        } else {
            form.removeAttribute( 'hidden' );
            preview.classList.add( 'is-offscreen' );

    togglePreviewsBtn.setAttribute( 'data-hidden', 'false' === togglePreviewsBtn.dataset.hidden );

You should now see an eye icon at the top left of the Widget Block Editor toolbar. Click it to toggle Legacy Widget Previews.


  1. This is a rough targeting of elements. It is by no means intended to reflect the typical approach in Gutenberg.
  2. The focusin / focusout handlers on .wp-block-legacy-widget would need to be added/removed depending on the toggle state.
  3. Clicking the toggle button should probably be saved as a persistent preference, and likely on a per-user basis.
  4. Accessibility testing hasn't been done, although keyboard navigation appears to work the same as before at least.
  5. The tooltip for the icon isn't working - I didn't see this as something worth resolving for this illustration.
  6. The icon would obviously need an alternate state.
Last edited 3 years ago by costdev (previous) (diff)

#2 @eatingrules
3 years ago

Just gave it a try on a couple of sites - looks great! 😃

#3 follow-up: @andraganescu
3 years ago

Have not thought this through, but since these problems with previews seem to be more like edge cases, I wonder if a filter would be useful, so if a plugin does things that don't work with previews, that plugin can disable them via a filter (for the widgets it provides or globally)?

#4 in reply to: ↑ 3 @eatingrules
3 years ago

Replying to andraganescu:

since these problems with previews seem to be more like edge cases, I wonder if a filter would be useful

I agree, a filter would absolutely be useful! But I think we really need to also provide the users with an easy way in the interface to disable (or at least toggle on/off) the preview.

So far on every site where I've tried the new widget editor, the Legacy Widget previews have been problematic (even once #53801 is solved).

The biggest problem I'm seeing is that the width of the preview is wider than the sidebar, and the height of the individual widgets is not being calculated correctly.

Here's a screenshot of the widget block editor preview on my site:

Here's what it looks like on the front end:

That should probably be raised as another ticket -- but in the meantime, at least adding this preview toggle (and a filter, yes!) would go a long way to making the new widget editor functional for users.

#5 @eatingrules
3 years ago

Also, I think having a per-widget filter (which developers can add to their own widgets) and a sitewide filter (to disable all legacy widget previews) would be great. 😁

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.

3 years ago

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.

3 years ago

#8 @sabernhardt
3 years ago

  • Milestone changed from Awaiting Review to 5.9

#9 @ryokuhi
3 years ago

This ticket has been reviewed during the last two weekly Accessibility Team's bug-scrub.
Some members of the team shared their preference for having the widget preview off by default.
In any case, at the very least users should be able to activate or deactivate the widget preview on their own.
Also, a filter to allow plugins which add widgets to enable or disable the preview for their widget might be a plus.

#10 @critterverse
3 years ago

Hi all, I opened a new issue in the Gutenberg repository to discuss adding this as a preference within the "Option" ellipses menu that appears in the editor top bar on both the Widget screen and Customizer Widgets screen:

This ticket was mentioned in Slack in #accessibility by critterverse. View the logs.

3 years ago

This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.

3 years ago

#13 @ryokuhi
3 years ago

  • Milestone 5.9 deleted
  • Resolution set to reported-upstream
  • Status changed from new to closed

Since a related GitHub issue has been opened in the Gutenberg repository, this ticket can be closed.

Note: See TracTickets for help on using tickets.