Call for Testing: DataForm Editor Inspector  🔗 **Source:** [Call for Testing: DataForm Editor Inspector](https://make.wordpress.org/core/2026/09/17/call-for-testing-dataform-editor-inspector/) > [!note]+ Document Notes > tags: [wordpress-core, gutenberg, dataform, quick-edit, plugin-compatibility, call-for-testing] > author: Nik Tsekouras > source: Make WordPress Core > reference: https://make.wordpress.org/core/2026/09/17/call-for-testing-dataform-editor-inspector/ > date created: 2026-09-18 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > <!-- deep-read:sections start --> ## 🏷️ Title **Call for testing: DataForm editor inspector** — Nik Tsekouras, Make WordPress Core, 17 September 2026. A compatibility call on rebuilding the block editor's Post/Page settings tab on DataForm, targeted at WordPress 7.2. ## 🧭 Table of Contents - What is it? (the experiment and what it replaces) - Why the change? (user cohesion, cross-screen developer APIs) - How to test (Gutenberg 24.0+, trunk, Playground blueprints) - What to expect (which SlotFills and filters survive) - Suggested testing flows (plugins, CPTs, roles, MediaUpload, site owners) - Sharing your feedback (#82770 for compatibility, #76076 for design) - Out of scope (blocks, taxonomies, meta boxes, open design questions) ## 🔗 References (in-page) - Tracking issue — consolidating Quick Edit and the editor inspector: https://github.com/WordPress/gutenberg/issues/76076 - This call for testing (also hosts the view-config example): https://github.com/WordPress/gutenberg/issues/82770 - Controlling which settings show: https://github.com/WordPress/gutenberg/issues/75529 - Fields API: https://github.com/WordPress/gutenberg/issues/61084 · https://github.com/WordPress/gutenberg/issues/74865 - `editor.MediaUpload` exploratory PR (on hold): https://github.com/WordPress/gutenberg/pull/82678 — rationale: https://github.com/WordPress/gutenberg/pull/82678#issuecomment-5630506528 - Role fixes already in trunk: https://github.com/WordPress/gutenberg/pull/82844 · https://github.com/WordPress/gutenberg/pull/82857 · https://github.com/WordPress/gutenberg/pull/82858 - PluginDocumentSettingPanel docs: https://developer.wordpress.org/block-editor/reference-guides/slotfills/plugin-document-setting-panel/ - Server-side view configuration filter docs: https://developer.wordpress.org/block-editor/how-to-guides/curating-the-editor-experience/filters-and-hooks/#server-side-view-configuration-filter - Playground blueprints with the experiment pre-enabled — 24.0, trunk (`?gutenberg-branch=trunk`), PR build (`?gutenberg-pr=82678`): https://playground.wordpress.net/ - Review props: https://profiles.wordpress.org/mcsf/ ## 📝 Summary **What happened.** A Gutenberg experiment, "Editor Inspector: Use DataForm," replaces the classic post inspector summary panels (featured image, excerpt, status, date, author, template) with a DataForm — the same form definition that powers Quick Edit in the Site Editor. It ships in Gutenberg 24.0 and is aimed at stabilizing in WordPress 7.2. **Why it matters.** This is structural convergence, not a reskin. One definition feeding two surfaces is the precondition for the fields API, which would let a plugin register a field once and have it appear in both the inspector and Quick Edit. It also ends classic panel markup and CSS class names as a stable extension surface. **Stakeholders.** Plugin developers extending the Post tab (SEO, social, editorial workflow, custom media pickers); custom post type authors; site owners running those plugins; Core and Design on the tracking issue; hosts and agencies who will absorb the breakage reports. **Risks.** `PluginPostExcerpt` is not ported and may never be. `editor.PostFeaturedImage` does not work yet. The featured image picker bypasses `editor.MediaUpload`, and the PR fixing that is on hold. Anything keyed to classic panel markup is explicitly unsupported. And the call sets no deadline, which usually means thin response until a release is already close. **Bottom line.** If your plugin touches the Post tab, test against trunk or 24.0 now and report on #82770. The cheap migration is to move everything into `PluginDocumentSettingPanel` until the fields API lands. ## 📖 Main Content This is a compatibility call, not a design review. The stated goal is "what happens to the things plugins add to the inspector"; layout and label feedback is routed to tracking issue #76076 instead. Still working: `PluginDocumentSettingPanel`, `PluginPrePublishPanel`, `PluginPostPublishPanel`, `PluginSidebar`, `PluginPostStatusInfo` fills, and `removeEditorPanel`. Not working: the deprecated `PluginPostExcerpt` slot (likely never ported), the `editor.PostFeaturedImage` filter (may be ported), anything targeting classic panel CSS or markup (will not be), and `editor.MediaUpload` for the featured image picker (PR #82678, on hold). Hiding or relabeling a default setting is already supported server-side via `get_entity_view_config_posttype_post`. That is the sanctioned replacement for CSS-based hiding and it works today. Testing paths are unusually well provisioned: local Gutenberg 24.0 or trunk, or three Playground blueprints with the experiment pre-enabled. Version matters — trunk needs WordPress 7.0+, 24.0 also runs on 6.9 — and testers are asked to state which they used. Five flows are suggested: verify your plugin's additions still render and work; open a custom post type and confirm only supported settings appear; log in as editor, author and contributor and confirm capability-appropriate settings plus successful saves; test the MediaUpload PR if you replace the media picker; and, for site owners, enable the experiment and screenshot the Post tab on and off. **On the feature's own accessibility (distinct from the post's):** the post does not discuss it at all — no keyboard navigation, focus management, labelling or screen reader notes for the new form, and no invitation to the Accessibility team. For a rewrite of a heavily used admin surface across every post type, that is a conspicuous gap. The role flow covers capability visibility, not assistive-technology parity. The only adjacent note is that the Date setting's Reset button is absent for now. ### 🗒️ Notes - Two dependent pieces target the same release: the inspector stabilization and the fields API (#61084, #74865) are both aimed at 7.2. - "Checked X, nothing changed" is explicitly named as useful feedback — negative results count. - Three role bugs were fixed in trunk before the call went out (#82844, #82857, #82858), which is the real reason trunk beats 24.0 for role testing. - Block editing, taxonomy panels and meta boxes are untouched. - Props to @mcsf for reviewing the post — a small signal that Core calls for testing get editorial review. ## 📚 References (primary sources preferred) 1. WordPress/gutenberg#76076 — tracking issue; design questions live here. 2. WordPress/gutenberg#82770 — this call for testing; preferred feedback venue; contains a view config filter example. 3. WordPress/gutenberg#61084 and #74865 — fields API, aimed for 7.2. 4. WordPress/gutenberg#75529 — controlling which settings display. 5. WordPress/gutenberg PR #82678 — `editor.MediaUpload` for the featured image picker; on hold (comment 5630506528). 6. WordPress/gutenberg PRs #82844, #82857, #82858 — role/capability fixes in trunk. 7. Block Editor Handbook — PluginDocumentSettingPanel SlotFill reference. 8. Block Editor Handbook — server-side view configuration filter (`get_entity_view_config_posttype_post`). 9. WordPress Playground — three prepared blueprints. ## 🗣️ Paraphrase (paragraph by paragraph) **Opening.** The Post/Page tab is being rebuilt on DataForm, the same form Quick Edit uses. It is a Gutenberg experiment, ready for testing, aimed mainly at plugin developers, with a separate path for site owners. **What is it?** Enabling the experiment swaps the classic inspector panels for a DataForm across every block-editor post type, showing only what each post type supports. The same definition builds Quick Edit. **Framing.** Part of consolidating Quick Edit and the inspector, targeted at 7.2; the most-wanted help is on what plugins layer on top. **Why the change?** Users get one consistent experience instead of two drifting ones. Developers get APIs that work on both screens: a view config filter today, and a fields API to come. **How to test.** Install Gutenberg 24.0 or newer, enable the experiment under Settings > Gutenberg, compare on and off. Trunk preferred, 24.0 acceptable; trunk needs WP 7.0+, 24.0 also runs on 6.9. Say which you used. Playground links give a zero-setup look. **What to expect.** Five SlotFills plus `removeEditorPanel` survive. `PluginPostExcerpt` does not — move it to `PluginDocumentSettingPanel`. `editor.PostFeaturedImage` is not wired up; markup and CSS targeting will not be supported. `editor.MediaUpload` awaits an on-hold PR. **Suggested flows.** Check your plugin's additions; check CPTs show only supported settings; check editor/author/contributor behaviour and saving; test the MediaUpload PR if relevant; and as a site owner, confirm plugin-added fields still appear, with screenshots. **Feedback and scope.** Comments are fine but the GitHub issue is better; design feedback belongs on the tracking issue. No deadline, but sooner is better given 7.2. Blocks, taxonomies and meta boxes are out of scope, as are several open design questions. ## 📰 Newsletter **The sidebar is getting a new engine, and your plugin is the crash test dummy.** The Post tab in the editor sidebar and Quick Edit in the Site Editor have been telling slightly different stories about the same post for years. Gutenberg's [DataForm experiment](https://github.com/WordPress/gutenberg/issues/76076) makes them read from one script: flip on "Editor Inspector: Use DataForm" in Gutenberg 24.0 and the familiar summary panels become a single form — one that already knows what your post type supports and won't offer an excerpt field to a post type that never asked for one. The catch, as always, is everything we bolted on. `PluginDocumentSettingPanel` and friends survive. `PluginPostExcerpt` does not, and Core is refreshingly blunt that it may never — it was deprecated anyway. If your plugin hides a panel by CSS class, consider this your notice: the server-side view config filter `get_entity_view_config_posttype_post` is the grown-up way now. And if you swap the media picker via `editor.MediaUpload`, the featured image picker doesn't route through it yet; [PR #82678](https://github.com/WordPress/gutenberg/pull/82678) would fix that, but it's parked. Best part: no local environment required. Three [Playground](https://playground.wordpress.net/) blueprints ship with the experiment pre-flipped — upload your plugin zip and look. Site owners can do this too; a before-and-after screenshot with a plugin name and version is genuinely useful. Where to say it: [#82770](https://github.com/WordPress/gutenberg/issues/82770) for compatibility, [#76076](https://github.com/WordPress/gutenberg/issues/76076) for "I don't like where that label sits." No deadline, but 7.2 is the target — and "no deadline" has never once meant "plenty of time." ## ✅ Action Items - **DevRel / OSPO:** Publish a one-page migration note (what survives, what breaks, view-config filter instead of CSS hiding) and circulate to plugin vendors within two weeks. Grep internally maintained plugins for the four at-risk extension points; file a ticket per hit. - **Community:** Run a Playground testing hour before 7.2 beta — browser and a plugin zip is the whole requirement. Recruit site owners specifically; this call has a rare non-developer flow. - **Core:** Test trunk (not 24.0) for role flows and report the version; confirm CPTs expose only supported settings; report gaps on #82770. - **Core Performance:** Measure inspector render and interaction cost with the experiment on versus off, especially on posts with many registered panels. - **Core AI:** Flag the fields API as a dependency — a declarative form definition is a far better target for AI-assisted editing than ad hoc panels. - **Core Program Team:** Surface in release planning that the experiment and the fields API both target 7.2. - **Mobile:** Determine whether the mobile editor inherits or bypasses the DataForm inspector; raise on #76076 if unclear. - **Playground:** Link the three blueprints from testing docs as an exemplar of pre-configured experiment testing. - **Training:** Flag Learn WordPress material screenshotting the classic inspector for refresh after 7.2. - **Marketing:** Hold announcement copy until stabilization; an experiment flag is not user-facing news. - **Support:** Draft a canned reply for "my SEO fields disappeared" pointing to plugin updates, not rollback. - **Design:** Weigh in on #76076: fields versus panels, and the missing Date Reset button. - **Documentation:** Mark `PluginPostExcerpt` as not ported in the SlotFill reference; raise the profile of the view config filter. - **Accessibility:** Request an a11y review of the DataForm inspector on #76076 before 7.2 — keyboard order, focus after save, field labelling. No accessibility flow exists in this call. - **Polyglots:** Expect string churn before 7.2 as field labels replace panel titles. - **Meta / CLI / Openverse / Photos / TV:** No direct action. - **Hosting / Tide:** Consider flagging plugins using the retired extension points in compatibility scans. - **Themes / Plugins:** Surface this call to authors of editor-extending plugins through directory channels. - **The WPOCC / FAIR:** Cite as a norm worth keeping — retiring an extension surface with a documented replacement and a public testing window. ## 🧪 Hypotheses 1. Plugins using only `PluginDocumentSettingPanel` will need zero changes; breakage concentrates in CSS/markup targeting and `PluginPostExcerpt`. Testable by running the top 100 editor-extending plugins under the flag. 2. Feedback on #82770 stays low until a 7.2 beta forces attention, because no deadline is set. 3. Role regressions are the highest-severity remaining class, given three fixes landed pre-call. 4. Site-owner reports yield more actionable bugs per report than developer comments, because they surface real plugin stacks. 5. The fields API slips past 7.2 even if the inspector stabilizes, because it depends on this landing first. 6. Playground testers outnumber local-environment testers, because setup cost dominates participation. ## 📊 Methodology A solicitation, not a study. The method is manual comparative testing: enable a flag, compare a UI surface on and off, across four variables (plugin extensions, post type supports, user role, media picker filter). No sampling frame, no reporting template, no stated threshold for "ready to stabilize." Reproducibility is helped by pinned environments and by asking testers to name the version used. ## ❓ Questions - What counts as enough testing to stabilize for 7.2? No threshold is given. - Will `editor.PostFeaturedImage` be ported, or is deprecation intended? "Might be" is doing heavy lifting. - If the fields API slips, do plugin authors migrate twice — once to a workaround, once to the real API? - Has the new inspector had any accessibility review, and by whom? - What is the fallback if a widely used plugin cannot adapt in time — delay, or ship with known breakage? - Does the view config filter support per-role or per-user variation, or only per-post-type? ## 🔮 Future Research - Static analysis across the plugin directory for the retired extension points, to size the blast radius empirically. - Comparative usability testing of the inspector before and after, including screen reader users. - Post-7.2 support-ticket analysis measuring actual breakage against predicted breakage. - Whether "no deadline" calls for testing draw less feedback than dated ones across Make blogs. ## 💡 Implications **Practice.** Consolidate on `PluginDocumentSettingPanel` now and abandon CSS-based panel manipulation. Agencies should add the experiment flag to pre-release QA checklists. **Policy.** Retiring an extension surface with a documented replacement, a public issue and a testing window is a reasonable deprecation norm; the gap is the absent decision date for `editor.PostFeaturedImage`. **Security.** Capability-aware field rendering is the live surface. A form that shows a setting a role cannot save, or accepts a value it should not, is an authorization bug; three pre-landed role fixes suggest this area is genuinely fragile. **Education.** Material keyed to the classic inspector will age out. The view config filter is badly under-taught relative to its new importance. **Funding.** Sponsored contributor time on compatibility testing here is cheap insurance against post-release support load; hosts have the most direct incentive. ## 🧠 Learning Styles Assessment - **Visual:** Strong — four screenshots including an explicit current-versus-experiment pair. - **Aural:** Absent — no audio, video or linked meeting. - **Verbal:** Strong — clear prose, short paragraphs, precise API naming. - **Kinesthetic:** Very strong — Playground links put a reader inside the feature in under a minute. - **Logical:** Strong — explicit works/doesn't-work list, fenced scope, stated rationale. - **Social:** Moderate — feedback venues named, but no office hours or shared testing slot. - **Solitary:** Strong — fully self-serve end to end. - **Naturalistic:** Weak, as expected for the genre; some ecosystem framing, no systems-in-context material. - **Reading level:** College / technical-professional, roughly grade 11-13. Dense with API identifiers; a non-developer can follow "Site owners" and little else. ## 📊 Accessibility Assessment Assessed on the post as captured, mapped to WCAG 2.2 AA. 1. **Text alternatives (1.1.1):** Fail as captured — all four images have empty alt text. Captions ("Current," "Experiment enabled," "Quick Edit interface") give some context but do not describe the interface differences, which are the entire point. 2. **Adaptable structure (1.3.1):** Pass — proper heading hierarchy, real lists, semantic emphasis. 3. **Distinguishable (1.4.3, 1.4.4, 1.4.10):** Likely pass — standard Make theme, text reflows, no colour-only meaning in prose; screenshots are not zoomable in place. 4. **Keyboard and focus (2.1.1, 2.4.7, 2.4.11):** Pass — ordinary links and images, no custom widgets or traps. 5. **Link purpose (2.4.4):** Mostly pass with a recurring flaw — "this PR," "this GitHub issue," "see why," "try it in Playground" are not self-descriptive out of context, and two Playground links are indistinguishable by text alone. 6. **Readable and predictable (3.1.1, 3.1.3, 3.2):** Mixed — consistent language, but unglossed jargon (`removeEditorPanel`, DataForm, SlotFill, trunk) for an audience explicitly invited to include non-developers. 7. **Input assistance / robustness (3.3, 4.1.2):** Pass — no forms in the post; standard accessible comment form and markup. **Summary:** The blocker is missing alt text on a post whose central argument is a visual before/after. Ambiguous link text is the secondary fix. ## 🌍 DEIB Assessment - **Cultural breadth:** Limited by genre — English only, GitHub-centric, assumes a dev environment or at least a capable browser. No locale or RTL consideration for the new form. - **Inclusive language:** Good — plain, non-aggressive, no gendered or violent idiom. "You don't need to be a developer for this one" is genuinely welcoming. - **Neurodiversity support:** Good — short sections, bounded tasks, and an explicit "you don't have to follow these exactly" that reduces perfectionism pressure. Welcoming null results lowers the contribution bar meaningfully. - **Representation:** Thin — one author, one named reviewer, same contributor circle; no indication of who else shaped the design. - **Psychological safety:** Strong — negative results explicitly welcomed, venues clearly separated so nobody fears posting in the wrong place, and "whether you can adapt on your side or need something from Gutenberg" invites asking for help rather than demanding conformity. ## ✅ Logical Validity **Strong reasoning.** The core argument holds: two surfaces showing the same data should share one definition; a shared definition enables a single extension API; therefore consolidate. Every compatibility claim is specific and falsifiable — named SlotFills, named filters, named PRs — so a tester can confirm or refute it immediately. The hedging is honest ("might be ported," "we're considering," "doesn't work yet"), and fencing scope keeps the feedback channel from collapsing into unrelated complaints. **Fallacies.** 1. *Non sequitur / appeal to novelty* — located in "How to test": "It's always better to test in trunk because it's the most current version." Recency does not entail suitability; for compatibility testing a released build is arguably more representative, and trunk adds churn as a confounder. *Fix:* give the real reason — "test trunk for role flows, since #82844, #82857 and #82858 are only fixed there; 24.0 is fine otherwise." 2. *False urgency / self-undermining appeal* — located in "Sharing your feedback": "There is no deadline, but the sooner the better, since this is aimed for 7.2." It removes the forcing function and then asks for urgency anyway; a 7.2 target is a deadline in all but name. *Fix:* name the gate — "we need compatibility reports before the 7.2 beta freeze on <date> to act on them." **Tone of voice.** Collegial, plain-spoken, low-ego. "We" for Core and "you" for the reader without condescension; limitations admitted before anyone asks; thanks offered in advance. It reads like an engineer asking peers for help rather than a project announcing a change — the right register, and probably its single biggest asset. ## 🛡️ DARVO Analysis **Deny:** None. The post volunteers its own gaps — unported slot, non-working filter, on-hold PR — before anyone raises them. **Attack:** None. Plugin authors relying on soon-to-break APIs are not blamed; even the deprecated slot is described neutrally with a migration path. **Reverse victim and offender:** None. Core owns the breaking change and asks for help rather than casting plugin authors as obstacles. The nearest thing to burden-shifting is that testing labour falls on the ecosystem — the acknowledged nature of a call for testing, and mitigated by prepared Playground blueprints. **Verdict:** No DARVO patterns. Accountability language is unusually clean for a breaking-change announcement. ## 🎯 Conclusion **Bottom line.** The editor inspector is being rebuilt on DataForm so the Post tab and Quick Edit share one definition, with the fields API as the payoff. Well-behaved plugins mostly survive; plugins tied to classic markup, `PluginPostExcerpt`, or `editor.MediaUpload` for featured images do not, at least not yet. The testing path is unusually low-friction and the post is honest about what is broken. **Next steps.** Grep plugins for the four at-risk extension points. Open a Playground trunk blueprint, upload a zip, compare the Post tab on and off. Test as editor, author and contributor. Report on #82770 with the version tested — including "nothing changed." Send layout and label opinions to #76076. And ask on #76076 whether an accessibility review of the new inspector is planned; nobody has, and it is the clearest hole in an otherwise careful call. ## 🧱 Refactor Appendix ### Literature Split Pad ### H1 — The Post tab is being rebuilt on the same form Quick Edit uses > [!quote] The "Post" (or "Page") tab of the editor's Settings sidebar is being rebuilt on top of DataForm, the same form that Quick Edit uses in the Site Editor. It's available as a Gutenberg experiment and it's ready for testing, mostly by plugin developers whose code extends that part of the editor. If you're a site owner using plugins that add things there, there is a flow for you too. Strongest evidence claim: the change is architectural, and the testing audience is deliberately two-tier. ### H2 — The experiment replaces classic panels for every block-editor post type > [!quote] With the "Editor Inspector: Use DataForm" experiment on, in the block editor the classic summary panels of the post inspector (featured image, excerpt, 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. Scope is total within the block editor, and field visibility derives from post type supports rather than hardcoding. ### H3 — A deprecated slot is dropped, with a named migration path > [!quote] 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 clearest concrete breakage, paired with the clearest remedy. ### Atomic Split Pad #### Z1 — Shared form definitions turn two UI surfaces into one extension point When the inspector and Quick Edit read from one DataForm definition, registering a field once makes it appear in both. That is why the fields API becomes possible and why markup-based extension has to die. #### Z2 — Deprecating an extension surface honestly costs a testing window Enumerate what breaks, name the replacement, open a dedicated feedback issue, ship pre-configured sandboxes. A reusable template for retiring any public API in an ecosystem you do not control. #### Z3 — Lowering the contribution floor is a design decision Welcoming null results, plus a browser-only testing path, plus an explicit non-developer flow, converts a developer call into an ecosystem call. The barrier to feedback is itself a product feature. #### Z4 — Capability-derived UI is an authorization surface Rendering settings by role is not cosmetic. Three role fixes landed before the call shipped; a form that shows or accepts what a role cannot save is a permissions bug wearing a UI costume. ### Fleeting Queue - Does `get_entity_view_config_posttype_post` have a CPT equivalent, and is it filterable per role? - Does the mobile editor inherit the DataForm inspector or stay on classic panels? - Watch #82678 — if it stays parked through 7.2, media-picker plugins break visibly. - Ask Accessibility whether the new inspector is on anyone's review list. - Worth writing: a short "stop hiding panels with CSS" post for plugin authors. - Watch whether the fields API actually lands in 7.2 or slips a cycle. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Call for Testing DataForm Editor Inspector.md|Call for Testing: DataForm Editor Inspector by Nik Tsekouras]] ## Highlights - The “Post” (or “Page”) tab of the editor’s Settings sidebar is being rebuilt on top of DataForm, the same form that Quick Edit uses in the Site Editor. It’s available as a Gutenberg experiment and it’s ready for testing, mostly by plugin developers whose code extends that part of the editor. If you’re a site owner using plugins that add things there, there is a flow for you too. ([View Highlight](https://read.readwise.io/read/01m2sap0awjk38cxz3808a2ghw)) - Note: H1 atom. Strongest evidence claim: the change is architectural (one shared form definition feeds both the inspector and Quick Edit), and the testing audience is deliberately two-tier — plugin developers first, site owners second. - Tags: atom/literature/h1 - With the “Editor Inspector: Use DataForm” experiment on, in the block editor the classic summary panels of the post inspector (featured image, excerpt, 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. ([View Highlight](https://read.readwise.io/read/01m2sap2qn3ecpnvrmqkb96a0e)) - Note: H2 atom. Scope is total within the block editor, and field visibility is derived from post type supports rather than hardcoded — which is what makes the CPT testing flow meaningful. - Tags: atom/literature/h2 - 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. ([View Highlight](https://read.readwise.io/read/01m2sap7k2w6asvdwakj4ngv7g)) - Note: Action H1 — the core testing instruction. Trunk needs WP 7.0+, Gutenberg 24.0 also runs on 6.9. Always report which version was tested. Feedback goes to gutenberg#82770. - Tags: action/h1 - It’s always better to test in trunk because it’s the most current version, but Gutenberg 24.0 is acceptable. ([View Highlight](https://read.readwise.io/read/01m2sapfz34bwb0x5fh6hcjcd2)) - Note: Fallacy: non sequitur / appeal to novelty. Being the most current version does not entail being the better test target — for compatibility testing a released build is arguably more representative, and trunk adds churn as a confounder. The real reason trunk is preferred appears later: role fixes #82844, #82857 and #82858 only exist there. Fix: state the actual reason rather than the recency claim. - Tags: fallacy/non-sequitur - 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. ([View Highlight](https://read.readwise.io/read/01m2sap57czwxmekedv4n9vwnf)) - Note: H3 atom. The clearest concrete breakage paired with the clearest remedy. Action: grep plugins for PluginPostExcerpt and migrate to PluginDocumentSettingPanel before 7.2. - Tags: action/h3, atom/literature/h3 - 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. ([View Highlight](https://read.readwise.io/read/01m2sapacdvbw7y00na9s59m8c)) - Note: Action H2 — the non-developer path, and the most recruitable one for Community and Training. Browser-only via Playground; deliverable is a plugin name, version, and a before/after screenshot. - Tags: action/h2 - There is no deadline, but the sooner the better, since this is aimed for 7.2. ([View Highlight](https://read.readwise.io/read/01m2sapj1qm12re4rskd9gdymh)) - Note: Fallacy: false urgency / self-undermining appeal. The sentence removes the forcing function and then asks for urgency anyway; a 7.2 target is a deadline in all but name. Fix: name the real gate — "we need compatibility reports before the 7.2 beta freeze on <date> to be able to act on them." - Tags: fallacy/false-urgency - Block editing, taxonomy panels and meta boxes. The experiment doesn’t touch them. ([View Highlight](https://read.readwise.io/read/01m2sapd1nwjjggmc7d119hzga)) - Note: Z1/F1. Scope fence: the consolidation stops at the summary panels. Fleeting question — if taxonomy panels and meta boxes stay classic, the Post tab ends up half DataForm and half legacy until someone ports them. - Tags: atom/fleeting/f1, atom/zettel/z1