Call for Testing the Widgets Screen in Gutenberg 9.1

Thank you to @andraganescu and @mapk who collaborated with me on this post.

Introducing the Widgets Screen

After the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. 8.9 release moved the new blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. based Widgets Screen out of experimental status, Gutenberg 9.1 released today includes design updates that now put the project in a great spot for a call for testing. This new functionality replaces the previous adminadmin (and super admin) Appearance > Widgets screen.

Image showing the layout of the new Widgets Screen.

The new Widgets Screen both replicates the functionalities of the previous screen and unlocks the ability to add blocks to widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. areas (also called sidebars) in any theme that supports this new screen.

Image showing the Inserter in the context of the new Widgets Screen.

Help test this feature

This is a call for testing for this new feature. Please report your findings on GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. in the Gutenberg repository as issues or in the comments below. If you have triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. access, labeling any issue with [Feature] Widgets Screen would be very helpful. Alternatively, you can simply include [Widgets screen] in the title to help those who can set the labels appropriately. Check out the instructions below for more detailed information.

Finally, testing should cover all the features you’d expect from the previous editor, as the new one should offer “feature parity”, meaning all the things previously available should still be available. Of note, it would be particularly helpful when testing to focus on the feature of adding blocks alongside classic widgets and to focus on any backward incompatibility issues that the block editor might introduce in relation to using widgets in themes.

Testing Flow

Here is a basic flow for testing:

  1. Have a site using WordPress 5.5.
  2. Make sure you use a theme that supports widget areas (e.g. TwentyTwenty).
  3. Go to the website’s admin.
  4. Install and activate the Gutenberg pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the Plugin Directory or can be cost-based plugin from a third-party. If you already have it installed, make sure you are using at least Gutenberg 9.1.
  5. Go to Appearance > Widgets.
  6. Notice that it visually resembles the Block Editor now.
  7. If you have a 3rd party widget installed, search for it in the Block Library and add it.
  8. Adjust any required settings and Preview your widget.
  9. Now drag that Widget into another Widget Area on your screen.
  10. Go back to the first Widget Area and add an Image block.
  11. Below the Image block add a Latest Posts block.
  12. Save your changes and view them on the frontend.
  13. Go back to the Widget screen and drag the Image block into the “Inactive Widgets” Area.
  14. Save and check out the frontend of the website.
  15. Share your experience in the comments below or in GitHub directly.

What to notice:

  • Did it crash?
  • If it worked, did the editor perform as expected?
  • Was it intuitive for you to add blocks and third party widgets (ie from other plugins)?
  • Did it work using Keyboard only?
  • Did it work using a screen reader?

Backward compatibility testing

The best way to test for backward compatibility issues is to install plugins that provide widgets and try to add them to widget areas using the new Widgets Screen. If you already have a website using widgets and you use the Gutenberg plugin, the widgets you have set up should just appear in the new editor. Outside of testing what you commonly install, try popular plugins that provide widgets and see if:

  • The plugin widget can be added to any widget area.
  • The plugin widget can be set up and customized in the new Widget Screen.
  • The plugin widget renders well on the website’s frontend.

The new Widgets Screen is expected to introduce some backward incompatibility, mainly because the block based editor does not contain the same HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. as the previous screen. We do aim to support all of the previous screen’s hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same., filters and actions, in both the admin and the frontend, as these are the correct extension points for WordPress.

Extendability testing

The new Widgets Screen should prefer blocks over corresponding widgets. That means that if a block is registered by a plugin and it covers the exact same role that a widget currently has, the developer of the block can use the new widgets_to_exclude_from_legacy_widget_block filterFilter Filters are one of the two types of Hooks They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to add the widget they replaced with the new block to an exclusion list.

All the widgets that have block equivalents will not be available to use through the LegacyWidget block.

Testing extendability should not focus solely on previous available hooks and filters but also imagining new points of extensibility in the new block based Widgets Screen.

Disabling the new Widgets Screen

Users of the plugin who do not want to test the new Widgets Screen or who require the old screen, can use a simple filter to disable the new Widgets Screen. Just place this in your theme’s functions.php file:

add_filter( 'gutenberg_use_widgets_block_editor', '__return_false', 100 );

Thank you!

Thank you for helping with testing the new Widgets Screen! Since it is one of the major focuses of WordPress 5.6 any help in this early stage is immensely valuable. If you would like to suggest improvements to this call for testing, leave them in the comments!

#5-6, #core-editor, #widgets