WordPress 7.2 DataForm Inspector: Plugin Test Guide

WordPress is rebuilding the Post and Page settings tab with DataForm, the same form system used by Quick Edit in the Site Editor. The experiment is available in Gutenberg 24.0 and is being aimed at WordPress 7.2.

For users, the goal is consistent settings in two places that currently drift apart. For plugin developers, the change is more consequential. Code that adds a supported plugin panel should keep working. Code that reaches into the old inspector's markup, CSS classes, deprecated slots, or featured-image implementation may not.

The WordPress project published a call for testing on September 17. This is the useful window to find compatibility problems while the design and extension paths are still being discussed.

This guide explains what is changing, what WordPress expects to remain compatible, and how to test a real plugin across posts, pages, custom post types, roles, and media integrations.

What the DataForm inspector changes

With the Editor Inspector: Use DataForm experiment enabled, the familiar summary panels in the editor's Post or Page tab are replaced by a DataForm. The affected settings include featured image, excerpt, status, date, author, template, and other fields supported by the current post type.

The same form definition also builds Quick Edit in the Site Editor. One definition can therefore control which fields appear and how they are arranged in both editing surfaces.

This is the main architectural shift:

Before
Post editor inspector -> its own panels and markup
Site Editor Quick Edit -> DataForm configuration

Target direction
Post editor inspector -> shared DataForm configuration
Site Editor Quick Edit -> shared DataForm configuration

The tracking issue describes the intent as a visually and behaviorally consistent experience with developer hooks that work across screens. It also makes clear that extensibility should move toward entity fields and actions rather than old slots tied to one interface.

The experiment is not a finished WordPress 7.2 contract. It is a compatibility target under active testing. Plugin developers should report concrete breakage rather than coding against every private detail they see in the current Gutenberg build.

Why WordPress is consolidating the two forms

Quick Edit and the full editor can modify many of the same properties. Maintaining separate UI implementations creates predictable problems: labels differ, one screen receives a new field before the other, permissions are interpreted differently, and plugins need separate integration code.

DataForm describes the data, editable fields, layout, validation, and changes through a shared component model. The DataViews package documentation defines DataForm as the component for editing one item. A field describes how a value is read, rendered, edited, validated, and written. The form configuration decides which fields appear and how they are laid out.

For a plugin, the intended gain is not a different-looking sidebar. It is one extension model that can reach the editor inspector and Quick Edit. That could reduce duplicated controls and mismatched behavior, provided the Fields API and configuration filters cover the real extension needs found during testing.

The compatibility map today

The official testing call gives a specific snapshot of what should work and what does not yet work.

Integration	Current expectation
PluginDocumentSettingPanel	Should keep working
PluginPrePublishPanel	Should keep working
PluginPostPublishPanel	Should keep working
PluginSidebar	Should keep working
PluginPostStatusInfo	Should keep working
removeEditorPanel	Should keep working
PluginPostExcerpt	Not ported; deprecated
editor.PostFeaturedImage	Does not work yet
editor.MediaUpload in featured image	Not used by the picker yet; exploratory work exists
Selectors tied to classic inspector markup	Expected to be unreliable
CSS tied to classic panel class names	Expected to be unreliable

"Should keep working" still calls for a test. A slot may render but have spacing problems, save the wrong value, appear for the wrong role, or behave differently between the full editor and Quick Edit.

The recommendation for content previously rendered through PluginPostExcerpt is to move it to PluginDocumentSettingPanel. The former is deprecated and may not be added to the new implementation.

Set up a useful test environment

Do not enable the experiment first on a production site. Use a disposable local, staging, or Playground environment with representative content and plugin settings.

The WordPress call gives two supported starting points:

• Gutenberg 24.0 or newer, which also works with WordPress 6.9;
• Gutenberg trunk, which requires WordPress 7.0 or newer and contains the latest fixes.

Install the selected Gutenberg version, then open Settings > Gutenberg and enable Editor Inspector: Use DataForm. Test the same content with the experiment on and off.

Record the versions in every report:

WordPress: 7.1.1 RC1 or trunk revision
Gutenberg: 24.0.0 or commit SHA
Plugin: name and exact version
Theme: name and exact version
Browser: name and version
Experiment: on or off
Post type: post, page, or custom slug
User role: administrator, editor, author, contributor

WordPress also provides linked Playground instances in the testing call. Playground is useful for a quick visual and functional check. Upload your plugin ZIP through the Plugins screen, reproduce the behavior, and save enough information to recreate the same environment locally if debugging needs source maps or automated tests.

Build a before-and-after inventory

Before looking for bugs, list everything the plugin adds to the Post or Page tab. Search the codebase for editor slots, filters, panel removal, and CSS selectors.

Useful search terms include:

rg "PluginDocumentSettingPanel|PluginPostStatusInfo|PluginPostExcerpt" .
rg "PluginPrePublishPanel|PluginPostPublishPanel|PluginSidebar" .
rg "removeEditorPanel|editor.PostFeaturedImage|editor.MediaUpload" .
rg "edit-post|post-summary|document-settings|components-panel" src build

The last search is intentionally broad. It finds style and DOM assumptions that may never call a public extension API. Review each match rather than replacing class names with new experimental ones.

For every integration, record:

• where it appears with the experiment off;
• where it appears with the experiment on;
• whether it appears in Site Editor Quick Edit;
• the value it reads;
• the value it writes;
• the REST field or meta key involved;
• which post types and roles should see it;
• the public API it relies on;
• any private DOM or CSS dependency.

Screenshots help with layout comparisons. A small automated test is better for persistence and permissions.

Test supported plugin panels

Start with PluginDocumentSettingPanel, because WordPress identifies it as the temporary home for inspector content until the Fields API lands.

A panel test should cover more than rendering:

1. Create a post and set the plugin value.
2. Save, reload, and confirm the value persists.
3. Change the value and verify dirty-state handling.
4. Switch between the Post and Block tabs.
5. Close and reopen the settings sidebar.
6. Test autosave and manual save.
7. Test a failed REST update.
8. Confirm the panel respects post-type support and capabilities.
9. Check keyboard navigation, focus order, labels, help text, and errors.
10. Compare the same workflow with the experiment off.

If the plugin uses removeEditorPanel, verify that it removes only the intended setting and does not hide unrelated DataForm fields. A removal call that worked by matching an old panel identifier may behave differently when the setting is represented as a field.

Pre-publish and post-publish panels are outside the main summary form but should still be exercised. Publish, schedule, update, and fail a save. Check that the plugin does not rely on state formerly exposed by the classic inspector's component tree.

Test custom post types from their declared support

The DataForm inspector should show settings supported by the current post type. A custom type without excerpt support should not gain an Excerpt field. A type without thumbnails should not show a featured-image control. Hierarchical and template-aware types may have different fields from ordinary posts.

Create a matrix from the plugin's registered post types:

Post type	Block editor	Supports	Expected fields	Plugin fields
book	Yes	title, editor, excerpt, thumbnail	status, date, author, excerpt, featured image	ISBN, edition
event	Yes	title, editor, custom-fields	status, date, author	venue, start time
legacy_item	No	title	Not part of this inspector test	Classic metaboxes

Open new and existing records for each type. Test missing values and values created before the plugin's current version. Confirm that REST schema, show_in_rest, authentication callbacks, and meta registration still permit the editor to read and write the fields.

Do not report classic meta-box behavior as a DataForm regression without checking scope. The call for testing lists meta boxes and taxonomy panels as separate concerns.

Test roles and capabilities

An administrator-only test misses one of the highest-risk regressions. The official call asks developers to test editors, authors, and contributors. It gives a concrete example: an author should not receive the Author setting.

For every role the plugin supports, test:

• which core fields are visible;
• which plugin fields are visible;
• whether a disabled field is clearly disabled rather than silently failing;
• whether saving strips or preserves values the role cannot edit;
• whether REST errors are displayed;
• whether private, draft, pending, scheduled, and published states behave correctly;
• whether switching author, template, status, or date respects capabilities.

Check the server response as well as the interface. Hiding a field is not authorization. The REST endpoint, meta registration, and save callback must reject unauthorized changes independently.

Automate at least one lower-privilege path if the plugin changes editorial permissions. User-facing controls are likely to move again while the experiment develops, but capability rules should remain testable through outcomes.

Audit featured-image customizations carefully

Featured image has two named compatibility gaps in the current experiment.

The editor.PostFeaturedImage filter does not work yet. Plugins that modify the classic featured-image component through that filter need to report their use case and test current Gutenberg work. CSS or scripts that target the old featured-image markup should be treated as fragile.

The new picker's media flow also does not yet pass through editor.MediaUpload. An exploratory pull request exists, but the testing call says it is on hold. If your plugin replaces the media picker, test the linked PR or Playground build from the official call in both the post editor and Site Editor Quick Edit.

Document why the plugin replaces the picker. Is it enforcing an asset library, adding licensing metadata, restricting sources, applying an image transform, or changing permissions? A clear use case helps the WordPress team evaluate whether an old filter should be ported or a new API should represent the requirement.

Avoid shipping a DOM patch for the experiment. It may work for one Gutenberg build and fail before WordPress 7.2 reaches beta.

Use view configuration for supported layout changes

WordPress already exposes server-side view configuration filters. For posts, the official call names get_entity_view_config_posttype_post. Other post types use the corresponding dynamic filter name.

The view configuration reference documents a form structure containing a layout and ordered field list. A configuration can choose field order, labels, layout types, and nested children. Only fields registered for the entity are rendered.

A simplified shape looks like this:

$form = array(
    'layout' => array( 'type' => 'panel' ),
    'fields' => array(
        array(
            'id'     => 'status',
            'label'  => __( 'Status', 'my-plugin' ),
            'children' => array( 'status', 'password', 'sticky' ),
        ),
        'date',
        'author',
    ),
);

Use the official schema and filter documentation for the build you test. Preserve unknown entries when modifying shared configuration so another plugin or a later WordPress version is not accidentally removed. Treat field IDs as identities, not as display labels.

The Fields API intended to add custom fields across the inspector and Quick Edit is aimed at 7.2 but is not yet a stable contract. Follow the tracking issues rather than copying private package exports into a production plugin.

Separate API compatibility from visual compatibility

A plugin can pass its save tests and still produce a poor sidebar. DataForm may render fields with different spacing, labels, panel triggers, focus behavior, or responsive layout.

Run a visual and accessibility pass at common viewport sizes. Zoom to 200 percent. Navigate with the keyboard. Check screen-reader labels and error associations. Use long translated labels and right-to-left text. Test empty, loading, error, and disabled states.

Remove selectors that style generic WordPress internals. A rule targeting a reusable panel class can affect core fields and other plugins. Scope plugin styles to a wrapper you own. Prefer component props and public layout configuration over DOM traversal.

Do not assume a visually similar control has the same semantics. A date field can represent local time, site time, a scheduled publication, or an immutable event time. Verify the saved REST value and timezone conversion.

Report findings so maintainers can use them

The WordPress call says the best reporting location for extension compatibility is the linked GitHub issue. Reports about the inspector's design belong on the tracking issue.

A useful report contains:

Plugin and version:
WordPress and Gutenberg versions:
Experiment state:
Post type and role:
Extension API used:
Expected behavior:
Observed behavior:
Steps to reproduce:
Screenshots or short recording:
Browser console and REST errors:
Minimal plugin or repository:
Can the plugin adapt with a public API?:

Report successful tests too. The project explicitly says that "checked X, nothing changed" is useful. Compatibility evidence helps distinguish widely used working paths from paths nobody exercised.

Keep the reproduction small. A plugin ZIP with one panel and one failing save is easier to diagnose than a production plugin with unrelated build tooling. Remove secrets and customer content before attaching logs or exports.

Add regression coverage before the interface stabilizes

Visual details may change during the experiment, but plugin outcomes can be automated now. Build tests around public behavior: the field is available to the right role, the value loads, an edit becomes dirty, saving persists it, and reopening the post shows the same value.

Use end-to-end selectors based on accessible roles, names, and plugin-owned identifiers. Avoid a long selector copied from the current DataForm DOM. If the field label changes through translation, give the plugin's wrapper a stable identifier that you control while still asserting the visible accessible label.

Keep experiment-on and experiment-off cases temporarily if the plugin supports both the current editor and the developing 7.2 path. Reuse the same outcome assertions through a small page-object adapter. That isolates expected UI differences without duplicating the whole test suite.

Server tests should cover the authorization boundary separately. Call the REST update as each supported role, confirm unauthorized fields are rejected, and verify that a failed update does not erase an existing value. A browser test that cannot see a field proves nothing about whether the endpoint will accept a forged request.

Add custom post-type fixtures with different supports combinations. Include a post type with excerpt and thumbnail support, one without them, and one unavailable in the block editor. This catches assumptions that every entity has the same DataForm definition.

When Gutenberg changes, run the suite against the pinned version used by customers and a scheduled job against Gutenberg trunk. A trunk failure is an early compatibility signal, not automatically a production emergency. Record the first failing commit or package version so a report can identify the regression window.

Screenshot tests can help with plugin-owned panels, but keep the capture area narrow. Full-editor screenshots change for many unrelated reasons and produce noisy diffs. Pair visual coverage with functional assertions so a pixel match never substitutes for a successful save.

What site owners should test

Site owners who use SEO, social, workflow, or custom-field plugins can contribute without writing code. Use a staging site or WordPress Playground, enable the experiment, and compare the Post and Page tabs before and after.

Check whether plugin panels are present, values can be edited and saved, featured-image flows still work, and authors see the right controls. If something disappears, record the plugin name and version and capture matching screenshots with the experiment on and off.

Do not use a production editorial workflow as the first test. The experiment may contain known issues, and active Gutenberg builds change quickly.

Prepare without coding against an experiment

Plugin teams can do useful work now without committing to unfinished APIs:

• inventory inspector extensions and private selectors;
• migrate away from deprecated PluginPostExcerpt where practical;
• move inspector content into supported PluginDocumentSettingPanel surfaces;
• add tests for custom post types and lower-privilege roles;
• isolate featured-image customization behind one adapter;
• separate server authorization from field visibility;
• follow the Fields API and inspector tracking issues;
• test each Gutenberg milestone before WordPress 7.2 beta.

WordPress 7.2 has other developer work in progress, including the proposed Secrets API covered in our WordPress 7.2 Secrets API analysis. Treat both as release targets under development, not promises that every proposal will ship unchanged.

The DataForm inspector is a chance to replace two drifting interfaces with a shared model. Whether that works for the plugin ecosystem depends on evidence gathered now. Test the extension points your plugin actually uses, report the gaps with small reproductions, and avoid trading an old private selector for a new one.

---