Consolidate QuickEdit and Editor Inspector

Author: oandregalCreated Mar 3, 2026Updated Sep 18, 2026

Labels[Type] Enhancement[Feature] DataViews

Part of https://github.com/WordPress/gutenberg/issues/81228

What

In WordPress 7.0, we landed a new QuickEdit experience in the site editor built with DataForm. We want the QuickEdit and the editor inspector to be the same experience — visually and behaviourally.

Why

The rationale for this change is twofold: we want to offer a cohesive experience to users, and we also aim to expose developer hooks that works across the screens — to control field visibility (#75529), to add fields, etc.

Pages: QuickEdit vs. Editor Inspector

Quick Edit (SiteEditor Pages)	Editor Inspector (Pages)

Across post types:

Pages	Posts	Patterns	Template parts	Templates

How

We've enabled an experiment (Gutenberg > Experiment > DataForm in Editor Inspector) that replaces the existing editor inspector with a DataForm-based one for post and page types.

Inspector (experimental)

Post & Pages: https://github.com/WordPress/gutenberg/pull/76244
Templates: https://github.com/WordPress/gutenberg/pull/76934 and template parts
Patterns: https://github.com/WordPress/gutenberg/pull/79452
Open the experiment to any other post type (see why it was gated). PR
Centralize logic to load experiment in the sidebar component (conversation). PR
Add e2e tests: 1, 2, 3, 4, 5

Notes about needed e2e changes when the experiment is stabilized:

Tasklist

Enabling the experiment makes the classic sidebar tests fail on exactly these, so the graduation PR needs to do the following.

Mirrors that replace a whole classic spec (delete the classic file, move the one from editor/various/post-summary-dataform/ in its place):

editor/various/datepicker.spec.js (the classic "Immediately" tests go away, the summary date row always renders a concrete date)
editor/various/scheduling.spec.js
editor/various/post-visibility.spec.js
editor/various/switch-to-draft.spec.js
editor/various/sidebar-permalink.spec.js
editor/various/post-editor-template-mode.spec.js

Mirrors that replace some tests of a mixed tests and move the mirrored ones into theclassic file):

`editor/plugins/custom-post-types.spec.jste an hierarchical post without titlesupport'
editor/plugins/plugins-api.spec.js: 'Po
editor/various/sidebar.spec.js: 'should be possible to programmatically remove Document Settings panels'
editor/various/template-resolution.spec.sts setting' tests
site-editor/pages.spec.js: 'swap template and reset to default' and 'change template options should respect the declared postTypes'
site-editor/template-registration.spec.js: 'registered templates are available in the Change template screen' and 'themes can override registered templat

Net new:

Move post-summary.spec.js up to editor/various/ as is (no classic counterpart).
Drop the experiment enabling from utils.PostSummary and EDITOR_CONTEXTS shouldlive.

Classic specs that only use the old sidebar as setup (fix the setup lines, the tests stay):

editor/various/post-content-focus-mode.srious/patterns.spec.js (~1351),editor/blocks/navigation-passive-rendering.spec.js (~20) and the writing prompt test in site-editor/pages.spec.js (~280): 'Template' is now only in the top bar 'View'dropdown. The skipped 'create a new page, edit template and toggle page template preview' test in pages uses the same menu too.
editor/various/preview.spec.js (~242) and editor/various/change-detection.spec.js (~81): 'Change status:' > the 'Edit Status' popover with the 'Status'
editor/plugins/meta-boxes.spec.js (~138): 'Add an excerpt…' > 'Edit Excerpt'.
editor/various/footnotes.spec.js (~371)st-revision__button` is classic only, thesummary has the 'Open revisions screen: N revisions' button.
site-editor/template-revert.spec.js: ths in the settings region need a check.
editor/various/revisions.spec.js needs nothing, its locator already matches the summary row.

Before opening the PR:

Run the whole classic suite with the expe already found tests the first inventory hadmissed, so I wouldn't trust the list above without it.
Remove the flag: the entry in lib/experip, the preload require in lib/load.php,the inline script in lib/experimental/editor-settings.php and the window.__experimentalDataFormInspector checks in edit-post/src/index.jsx, editondex.jsx andeditor/src/components/post-template/hooks.js.

Not mirrored on purpose: the datepicker "Immediately" tests (no floating date state in the summary, design pending) and the validation coverage (the sity` to DataForm yet).

Fields

Misc

Revisions
- https://github.com/WordPress/gutenberg/issues/76246
- https://github.com/WordPress/gutenberg/pull/77333
Design tweaks (validate or update design)
- Excerpt field. First iteration landed here. PR with design tweaks. Excerpt field shouldn't render add an excerpt when empty. It should render nothing like the description field, but it still requires design feedback for the case of empty excerpt (that would show nothing besides the edit/pencil button on hover.
- Revisions panel. First iteration landed here. Field created here
- Fix status field (auto-draft). See this comment. PR

Extensibility

Extensibility should be based on extending the entities (fields, actions) and not in the existing slots.

Backwards compatibility

Currently we hide most post summary content when the post-status is removed. How should this be handled with the new DataForm? https://github.com/WordPress/gutenberg/pull/79441
How should we handle the fills from PluginPostStatusInfo slot? Currently we rendered them alongside the fields that are now part of the DataForm. In cases that 3rd party plugins used this slot to add editable panels(fields) they should do it with new APIs from DataForms/DataViews. What about the content that could be more informational though - maybe links or messages? https://github.com/WordPress/gutenberg/pull/79586
Call for testing for extenders https://github.com/WordPress/gutenberg/issues/82770. There is also a make/core post cft with suggested testing flows and Playground links.

When we have the extensibility APIs (e.g. for fields and actions) we should deprecate the PluginPostStatusInfo and provide directions with good documentation about migration paths and probably a long bake.

Migrating actions, informational UI (notices etc..) and fields will be straightforward and there will be parity for them because we also render the previous fills. The main 'breakage' would be for any extenders which do various stuff by injecting HTML and targeting existing dom nodes and css classnames. In these cases there will be no parity if the extenders don't migrate to the new APIs.

An example I noticed recently is the canonical AI plugin which injects HTML in the excerpt field:

Source: WordPress/gutenberg

View original on GitHub View discussion on GitHub