# WordPress 7.1 Field Guide > [!question] Lingering Questions > - Which plugin patterns still cross the editor iframe boundary despite years of warnings, and does 7.1 finally force them to break visibly rather than silently? > - Which JSON Schema shapes remain difficult for common external clients to consume from the Abilities API's client-compatible preparation work? > [!tip] Article Ideas > - A release-audit matrix for WordPress 7.1 extension boundaries — map each changed API (media, tooltips, abilities, iframe, DataViews) to the extension patterns it breaks. #articleseed > [!link] Cross Reference > - [[3. Resources/Literature Notes/What’s the value of DataViews and who is it for?]] — same release cycle, same underlying API family (DataViews/DataForms/View Config land as part of 7.1's admin-modernization work). > - [[3. Resources/Literature Notes/WordPress 7.1 Release Candidate Phase]] — the process note for the same release this field guide scopes. > - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] > [!quote] Vocabulary > - **Field guide** — Core's release-scoped index of developer-facing changes and linked dev notes; a scope map, not a test report. ## Bib capsule Milana Cap, "WordPress 7.1 Field Guide," Make WordPress Core, August 5, 2026. ## Author's thesis WordPress 7.1 contains a wide, developer-facing change set — client-side media processing, accessible tooltips, an expanded Abilities API, editor-iframe completion, and maturing style/data APIs — and extenders should treat the field guide as a compatibility map to be tested against a pinned build, not as proof of compatibility on its own. ## Key arguments (≤3) 1. **The release is broad by ticket count (310+ Trac tickets, ~600 Gutenberg enhancements) but risk doesn't track volume** — one boundary change (the completed editor iframe) can matter more to a given plugin than hundreds of unrelated fixes. 2. **Several changes move formerly-server-side or formerly-implicit behavior into explicit, testable contracts**: media processing moves partly into the browser; ability exposure gets a unified public flag; tooltips get one accessible pattern instead of ad hoc title-attribute hacks. 3. **The guide is as disciplined about what's excluded as what's shipped** — React 19 and real-time collaboration are named as deferred, which the source treats as a scope-integrity feature worth preserving in any compatibility claim. ## Claim atoms ### New media APIs move work before upload > [!quote] ID:rw_01kz97avvhnped5pm1tjyy2hxb > New client-side media processing APIs allow supported image operations to happen in the browser before a file is uploaded. Related REST API changes support validating image dimensions, selecting size-aware encoding quality, and registering a sideloaded file for multiple image sizes. - Candidate note: covered by the release-scope claim below; not independently promoted. ### Editor extensions must respect iframe boundaries > [!quote] ID:rw_01kz97awwffynknt725tgj8980 > WordPress 7.1 completes the move to an iframe-based post editor, including for sites that register legacy meta boxes. This creates a more consistent editing environment, but plugins that rely on reaching across the editor document boundary should review their JavaScript and CSS for compatibility. - Claim: The highest-risk compatibility boundary in 7.1 is the editor document frame itself, not any single feature. - Candidate note: folds into the release-auditing claim below rather than standing alone. ### Release notes establish scope, not runtime proof > [!quote] ID:rw_01kz97az8rbjftk49brn58ratm > Not every feature explored during the release cycle was ultimately included in WordPress 7.1. The following initiatives were deferred, changed direction, or remained experimental, giving contributors more time to validate their design and implementation before they reach Core. - Claim: An official field guide identifies expected scope; only executed tests against a pinned build establish actual behavior. - Candidate note: [[Release Notes Define Scope Not Runtime Compatibility]] ## Permanent candidates - **Release notes define scope, not runtime compatibility** — a durable, reusable claim about the evidence hierarchy for any release announcement (not just WordPress). Promote. - The per-API technical claims (media processing, tooltips, iframe boundary) are useful reference material but are release-specific facts rather than durable claims — kept as source-linked atoms, not promoted individually. ## Processing checklist - [x] Confirmed no existing Literature Note for this source before creating - [x] Checked existing Permanent Notes for overlap — none found on "release notes as scope vs. proof" - [x] Connected into [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] ## Links - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — release-boundary changes are exactly what a hosting/security stack needs to track pre-upgrade - [[3. Resources/MOCs/WordPress Platform Design MOC]] — applies-in: Joins the cluster on WordPress release and platform direction.