There are several fundamental problems with the current approach to the widgets screen. This issue outlines an alternative approach that leverages existing WordPress core functionality to improve user experience and minimize reinventing the wheel. It streamlines the process of bringing blocks to the widgets screen and to the customizer.

Much of the current implementation could remain as-is, but the underlying technical foundation will be reworked. The user interface could be refined as a result and the user experience benefits significantly. The design could be similar to what is currently proposed or evolve as desired.

Why Now? (Before First Release of the Widget Blocks Screen, Proposed WordPress 5.6)

The Gutenberg plugin currently supports a new widgets screen with blocks. But there is no support for block-widgets in the customizer. This introduces several challenges:

• Blocks cannot be added to widget areas with contextual live preview (in the customizer).
• Only some widgets in the customizer are editable, blocking user flow.
• The new widgets screen and widgets in the customizer are separate technical implementations, amplifying technical debt and increasing the burden of maintaining future compatibility in WordPress core.
• Plugins extending the widget editors must contend with multiple divergent interfaces in core.
• Plugin authors cannot reliably convert their widgets to blocks because those widgets would no longer be usable in the customizer.
• The widgets screen remains severely crippled in functionality. “Change and surprise” becomes “save and surprise” and it remains impossible to contextually preview without publishing. Or to schedule or draft changes.

Generally, the current approach creates several disruptions to user flow. In contrast, reconstructing the widgets screen to leverage the customize API has several benefits:

• Widget edits can be drafted, scheduled, and shared before publishing.
• We can support a contextual (and optionally live) preview of all changes to widgets.
• Concurrent editing can be blocked (for now) and eventually enabled consistently.
• The same interface can be used in both the customizer and wp-admin, or this could eventually be unified into one location to manage widgets.
• There is reduced technical debt and future maintenance burden in WordPress core.
• We can improve the transition from editing posts in wp-admin to editing all content in a unified front-end-oriented interface while maximizing backwards compatibility.

Any change to the existing widgets screen will disrupt existing user flows. A vocal group of users expressed this concern when widgets and menus were originally added to the customizer. Let’s take the time to make sure the new experience is better, and to go through this disruption only once.

Why the Customize API?

The customizer is a framework for live-previewing changes to a site. It is not, necessarily, the specific interface that most of us are familiar with at wp-admin/customize.php. The power of the customizer is its API and its contextual live preview – the ability to instantly see edits as they apply on the frontend of the site. Users can navigate to different pages on the site within the preview; for widgets, this makes it easier to understand how dynamic and conditionally-visible widgets work across a site.

Most importantly, the customizer allows users to schedule changes, save draft changes, and even share a public link to navigate through the site with a preview of changes. The widgets screen has long suffered from a "change and surprise" publishing experience. The Gutenberg plugin’s new widgets screen currently has only a publish button with none of the other features.

We can leverage the customizer API outside of wp-admin/customize.php to bring this enhanced publishing experience to the standalone widgets screen (specifically, this is the customize changesets API). We can also offer a "preview" button that opens a standalone customizer preview of the frontend of the site reflecting changes to widgets.

Previewing Widgets

Once widgets are managed with the customize API, we enable previews of widget options using existing core functionality. There are several ways to show these previews:

1. Live inline pseudo-preview (Gutenberg editor does this)
2. Live standalone preview (this is part of what the customizer does)
3. Standalone contextual preview (Gutenberg does this in a new tab, customizer does this on mobile)
4. Contextual live preview (customizer does this)

The preview under option 3 could open in a new tab similar to the editor preview. But, because we're using the customize API, we could also open it as a full-screen or modal overlay. The editor/preview toggle could be similar to the mobile interface that the customizer currently uses. This is contextual, but not live, preview. Exceptionally large (desktop) monitors might show a live preview next to the editor (option 4). Blocks already do inline preview (option 1), but traditional widgets are not as successful in this format.

Contextual preview (via options 3 or 4) is critical to widgets because they aren’t consistent across all pages on a site. Some widgets include dynamic content based on the current view. Others may have conditional visibility. Most frequently, a given widget area may not be shown in all views. Without contextual preview, widgets and blocks in widget areas cannot be reliably tested and reviewed before being published to the live site.

Technical Approach

How can we leverage the customize API for the widgets screen? Here are a few steps aligned with the customizer object structure:

1. Merge blocks with legacy widget customize controls. This is the editing UI for individual widgets and blocks (rebuilt WP_Widget_Form_Customize_Control). There could be different control classes for blocks vs. legacy widgets as appropriate.
2. Merge block settings with customize settings. This is they key element that unlocks support for saving, previewing, and publishing. May involve a setting extending WP_Customize_Setting and/or primarily work in JS. There could be different setting classes or types for blocks vs. legacy widgets as appropriate.
3. Update widget area customize sections to the new design used on the widgets screen. This is a reworked (and maybe new/renamed) WP_Customize_Sidebar_Section, which controls the order and interaction between blocks.
4. Create a new WP_Customize_Widgets_Panel, extending WP_Customize_Panel. See WP_Customize_Nav_Menus_Panel and WP_Customize_Themes_Panel for examples. This is the “screen” that holds all of the widget areas. It includes the widget inserter and block areas/block settings sidebar. And it’s responsible for the overall screen layout (“taking over” the customizer preview for the customizer version).
5. Update the add-widgets/block inserter to create the appropriate customize controls and settings, adding the controls to the appropriate customize section.
6. Bootstrap an instance of the customizer on wp-admin/widgets.php. This instance will only load the widgets panel and associated controls. See https://core.trac.wordpress.org/ticket/29071 for some background and links to examples.
7. Implement supplementary UI for the preview, save, schedule, and publish functions on the standalone customizer instance. Essentially, add everything managed directly by wp-admin/customize.php. Includes design decisions on how to handle previews.
8. Where the preview approach is live (within the customizer), verify that the customize selective refresh functionality triggers whenever edits are made. JS-managed blocks should be able to handle previews instantly through postMessage.

All of this could be built in the plugin first by selectively extending and replacing elements (customize remove_* functions, dequeuing scripts) of the current customize-widgets infrastructure. The customizer PHP API is more stable and fully-featured that the JS API. This could be a great opportunity to improve the JS side and coordinate with the approach that Gutenberg takes with JavaScript. All of the object references above apply to both the PHP and the JS aspects of the API.

A Path toward Integrating Gutenberg with the Customizer

If the goal of the standalone widgets screen is to provide a full-screen experience for editing widgets, then it shouldn't use the same interface that widgets in the customizer currently use. But with block editing incorporated into widget editing, maybe customizer widgets should also offer a more-full-screen editing interface.

Customizer panels (widgets, menus, etc.) can take any form that's appropriate for the feature. The theme browser takes over the customize preview to offer a full-screen.) Why not do the same for widgets? With this approach, the widgets screen and widgets in the customizer can use exactly the same interface with exactly the same technical implementation as a customizer panel.

Do we need to offer the same interface in two different places? At that point, we can unify to a single full-screen widget editor that is powered by the customizer behind the scenes. We can keep links to the widgets screen as links that go directly to the full-screen widgets panel in the customizer. And users can also get to the widgets screen from directly within the customizer, without leaving the site customization scope. Or we can keep separate screens but use the same infrastructure and interface in both places. Either way, this general strategy brings Gutenberg into the customizer and demonstrates a path forward for integrating other parts of Gutenberg with the customizer.

Longer term, there becomes a clear path forward:

1. Integrate Gutenberg blocks into widget areas, editing them in a full-screen customizer panel.
2. Enable post editing within the customizer API with a similar approach to the widgets panel. Most site content (but not structure) can now be managed in a unified interface.
3. Move widget and post editing from separate panels to inline editing in the customize preview. This is inline-edited contextual live preview on the frontend of a site.
4. Add support for full site editing, or editing the site structure with block templates. This can live within the customizer to provide contextual live preview with the customize changesets publish flow.

Note: full site editing as currently conceived is a new feature set introduced to core that individually benefits from the customizer’s contextual live preview. It does not replace the role or functionality of the customizer. Step 4 outlined above would be a good opportunity to implement site structure editing with post and other content area editing and other features in the customizer to create a unified site management experience that prioritizes contextual live preview.

Conclusion

The widgets screen in the Gutenberg plugin currently feels very "alpha". From accessibility to publishing flow there is work to do. We have an opportunity to significantly improve the experience and reduce technical debt by leveraging the customize API in the technical implementation. And we can bridge the gap between the editor, Gutenberg, the widgets screen, and the customizer in the process.

This may not be achievable in time for WordPress 5.6. But it is a better approach than the current separate implementations. Focusing on a single implementation, we can focus on critical needs such as accessibility. And we can create a better editing experience for all users.