Legacy Widgets: Allow for turning previews on and off via the Option/Preferences menu

[critterverse]

Based on https://core.trac.wordpress.org/ticket/54075 and feedback from the Accessibility Team's weekly bug scrubs that it would be ideal to have a way to disable Legacy Widget previews.

One possiblity is to introduce a preference in the "Options" ellipses menus in both widget editors to turn the Legacy Widget previews on and off. This could go within the "Preferences" section of the menu.

Note that if this change is implemented, we should probably look at introducing a separate Preferences modal (rather than showing those options inline with other menu options): #32711

^ This change could be made for both the Widget screen and Customizer Widgets screen

[joedolson]

Given the number of potential display problems for legacy widgets, it would also be beneficial to offer a mechanism that allows the authors of widgets to disable the preview for their widget if they know it will cause problems. E.g. "Preview not enabled"

[blogtutor]

If the toggle to enable/disable legacy widget previews is buried behind the ellipses menu, that will make it difficult to toggle back-and-forth (far more navigational effort). I bet most users won't even know to look there, too.

@costdev's mockup (https://core.trac.wordpress.org/ticket/54075#comment:1) with the eyeball icon at the top of the page is a much more obvious solution.

(Regardless of where the toggle ends up, I'm really hoping there will be a filter to disable the legacy widget previews entirely. In our experience so far, our 600+ clients will be much better off with legacy widget previews just disabled completely.

At this point, the legacy widget previews are so bad that we've been installing the "Classic Widgets" plugin preemptively. It would be far better for accelerating adoption to the widget block editor, if we can just disable legacy widget previews instead of the entire widget block editor. So a filter will help towards this goal. I'd be happy to start new issue here about adding a filter, if that would be helpful?)

[theresaweb]

I am not clear what is meant by "disable the legacy widget previews entirely." For sites whose sidebars are currently made up entirely of legacy widgets, does that mean the widget area will be completely blank and make the only visual representation of what is there to be by clicking the List View icon?

What I am finding frustrating is that it seems random that some legacy widgets show a message "No preview Available" while others show a blank space where the widget is. If anyone can help me have all legacies show "No preview Available I would. be grateful!

[blogtutor]

I am not clear what is meant by "disable the legacy widget previews entirely."

In my ideal world, any legacy widgets in the new block widget editor would just show the settings and no preview (like it does once you click on the preview itself). So then there's no preview at all, and no "state change" when clicking on the preview -- it'll just look like the "old style" widget settings directly inside the editor. I still think this would be a massively better user experience.

If someone wants to preview changes as they edit things, they could use the Customizer's widget editor instead. That seems to give a much more accurate preview anyway.

[theresaweb]

@blogtutor thanks for clarifying and I agree that would be fine. But I am trying to understand the current mechanism by which at times I am seeing "No preview available" for a legacy widget and at times it is attempting to show a preview but the iframe returns nothing so it shows a blank spot in the Widget area.

I have 2 very similar legacy widgets and one shows "no preview available" message inside a div with class wp-block-legacy-widget__edit-no-preview and one shows an iframe (this is blank on the backend) inside a div with class wp-block-legacy-widget__edit-preview

If I could just get them both to show the No preview available message then I could use the Widget Block area.

[theresaweb]

In case anyone else finds themselves here, this post was helpful to me #16731 (comment)

By adding

		if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
			return false;
		}

in the beginning of the widget function of my legacy widget, the "No preview available" message is shown in the widget block editor but does not effect the front end display. (The suggestion here will likely cause the widget to not show anything on the frontend.

But ultimately I went with an is_admin check as was suggested here https://core.trac.wordpress.org/ticket/53801

[Oxibug]

Waiting for 5 months for WordPress 5.9 to fix the legacy widgets previews which consume the server's memory, and now after released what should we do to disable preview?

My Ticket: https://core.trac.wordpress.org/ticket/
The other ticket refer to github: https://core.trac.wordpress.org/ticket/54075

[karks88]

Was this officially added to 5.9? I updated an install and found that legacy widgets will not render on the Appearance > Widgets screen. Widgets are in place, but are completely hidden unless I hover over them. I also receive the following error in Firefox (no error in Chrome, but the render issues are still there).

Exception { name: "NS_ERROR_FAILURE", message: "", result: 2147500037, filename: "about:srcdoc", lineNumber: 31, columnNumber: 0, data: null, stack: "t.supports[o[r]]<@about:srcdoc:31:625\n@about:srcdoc:31:1099\n@about:srcdoc:31:1776\n" }

[noisysocks]

No, this has not been implemented in WP 5.9.

A user preference for disabling previews is a good idea.

Happy to also look at allowing the preview to be disabled via the widget developer e.g. using a WP_Widget setting and via the site administrator e.g. using a filter. #35087 (comment) is a good workaround, for now.

If the toggle to enable/disable legacy widget previews is buried behind the ellipses menu, that will make it difficult to toggle back-and-forth (far more navigational effort). I bet most users won't even know to look there, too.

@costdev's mockup (https://core.trac.wordpress.org/ticket/54075#comment:1) with the eyeball icon at the top of the page is a much more obvious solution.

What do you think about this suggestion, @critterverse?