Call for testing: DataForm editor inspector

What is it?

With the “Editor Inspector: Use DataForm” experiment on, in the 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. editor the classic summary panels of the post inspector (featured imageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts., excerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox., status, date, author, template, etc.) are replaced by a DataForm, for every post type that uses the block editor. The settings follow what each post type supports.

The same form definition is also used to build the Quick Edit interface in the Site Editor.

This is part of consolidating Quick Edit and the editor inspector and we’re aiming to stabilize it for WordPress 7.2. What we’d love help with most though is what plugins add on top.

Why the change?

For users, a cohesive experience: the inspector in the post editor and Quick Edit in the Site Editor show the same information and should look and behave the same, instead of drifting apart.

For developers, APIs that work across both screens: controlling which settings show (this is one example, and it’s possible today with the view config filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/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.), and adding your own fields through the fields APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., so they show up in the inspector and in Quick Edit (#61084, #74865). The fields API is aimed for 7.2.

How to test

Install Gutenberg 24.0 or newer on a test site and turn on “Editor Inspector: Use DataForm” under Settings > Gutenberg. Then open a post and compare the Post tab with the experiment on and off. It’s always better to test in trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. because it’s the most current version, but Gutenberg 24.0 is acceptable.

Note: Gutenberg trunk needs WordPress 7.0 or later, the 24.0 release also works on 6.9. Either way, please mention which version you tested.

If you develop a plugin, your own dev environment with Gutenberg installed is all you need.

For a quick look without setting anything up there is WordPress Playground, with the experiment already on: Gutenberg 24.0 or trunk. To test your own plugin there, install it from the Plugins screen as usual, or upload its zip.

What to expect

• PluginDocumentSettingPanel, PluginPrePublishPanel, PluginPostPublishPanel, PluginSidebar, PluginPostStatusInfo fills and removeEditorPanel keep working.
• The PluginPostExcerpt slot is not ported. It’s a deprecated API and we’re considering not adding it at all, so whatever you render there should move to a PluginDocumentSettingPanel.
• The editor.PostFeaturedImage filter doesn’t work in 24.0. Trunk has it since #83133 (not in Quick Edit), so it will be in 24.1. Anything targeting the classic panels’ CSSCSS Cascading Style Sheets. class names or markup won’t be ported.
• The featured image picker doesn’t go through the editor.MediaUpload filter in 24.0. Trunk has it since #82678 (not in Quick Edit), so it will be in 24.1.

Anything you need in the inspector can go in a PluginDocumentSettingPanel until the fields API lands.

Hiding a default setting or changing where its label sits is already possible with the server side view config filter, get_entity_view_config_posttype_post for posts (see docs). There is an example in this GitHub issue.

Suggested testing flows

You don’t have to follow these exactly, they’re mostly here to give you ideas.

What your plugin adds to the inspector

Open a post with your plugin active. Is everything you add to or change in the Post tab (panels, fills, filters, styles, scripts) still there, and does it still work?

Your custom post types

If you register post types that use the block editor, open one of them. You should only see the settings the post type supports (for example no excerpt setting without excerpt support). Please report anything missing or extra there.

Other user roles

Log in as an editor, author or contributor and open a post. The settings should match what the role can do, like in the classic inspector (an author doesn’t get the Author setting, for example), and saving should still work. Some known issues have already be fixed in trunk (#82844, #82857, #82858).

The editor.MediaUpload and editor.PostFeaturedImage filters

The featured image picker doesn’t go through the editor.MediaUpload filter in 24.0. If your plugin replaces the media picker through editor.MediaUpload, trunk has it since #82678 (not in Quick Edit, which keeps the plain picker), so test it with the trunk Playground link or a trunk build.

The same goes for editor.PostFeaturedImage: trunk has it since #83133, also not in Quick Edit.

Site owners

You don’t need to be a developer for this one. If you use plugins that add things to the Post or Page tab (SEO or social fields, custom panels, that kind of thing), enable the experiment on a test site or in Playground and check they are still there. If something is missing, please share the plugin name and version, and a screenshot with the experiment on and off.

Sharing your feedback

Comments on this post are fine, but the best place is the GitHub issue for this call for testing. Share what you extend, what changed, and whether you can adapt on your side or need something from Gutenberg. “Checked X, nothing changed” is useful too. Feedback about the inspector itself (layout, labels, missing controls) is welcome on the tracking issue, where the open design questions are discussed.

There is no deadline, but the sooner the better, since this is aimed for 7.2.

Out of scope

The goal here is compatibility, what happens to the things plugins add to the inspector. A few things are handled separately:

• Block editing, taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. panels and metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes. The experiment doesn’t touch them.
• Some design questions are still open, like which settings should be regular fields instead of panels, or the Reset button of the Date setting, which isn’t there for now and may come back in a follow up. These live in the tracking issue.

Thanks in advance for testing! Props to @mcsf for reviewing this post.

#core-editor #gutenberg