# WordPress 7.1 is coming. Are your custom blocks ready? > [!question] Lingering Questions > - Does the iframe boundary affect focus order or screen-reader traversal of the block editor? The video never asks. > - Does `patch-package` pinning modified dependency code silently block security updates to that dependency? > - Will the team actually roll back to forcing the iframe on block themes only, and if so, does that just extend the dual-support window rather than remove the urgency? > [!tip] Article Ideas > - "It's a promise, not the work" generalizes past WordPress to compliance attestations, SBOM declarations, and accessibility statements — worth a standalone piece. > - A Playground blueprint reproducing all six iframe failure modes (window/document, click-outside, styles, third-party libraries) would be a genuinely useful teaching artifact nobody has built yet. > [!link] Cross Reference > - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — self-declared readiness flags as a general product-trust pattern > - [[3. Resources/Permanent Notes/Declaring Readiness Is Not Becoming Ready]] — already promoted from this source in a prior pass > - [[3. Resources/Permanent Notes/Silent Failures Cost More Than Loud Ones]] — already promoted from this source in a prior pass > [!quote] Vocabulary > - **Iframed post editor** — WordPress 7.1 forces all block editing to happen inside an iframe with its own document/window, separate from the admin page the editor JavaScript loads in > - **`ownerDocument`** — the DOM property that returns the document an element actually lives in, the version-agnostic fix for code that assumes a single global `document` ## Bibliographic capsule Ryan Welcher (Automattic) uses a purpose-built demo plugin with broken/fixed pairs to show exactly what WordPress 7.1's mandatory iframed post editor (shipping August 19) breaks in custom blocks, and how each break is fixed — usually in one or two lines. ## Author's thesis Every failure in this migration traces to one root cause — editor JavaScript loads in the admin document while block markup renders in a separate iframe document — and every failure mode is silent rather than erroring, which is what makes finding them before users do the actual job, not declaring `apiVersion: 3` and moving on. ## Key arguments (≤3) 1. **One mechanism explains all six failure modes.** Two documents, two windows; code written against the global `document`/`window` silently targets the wrong one. `element.ownerDocument` is the version-agnostic fix. 2. **Declaring `apiVersion: 3` is a promise, not the work.** It tells WordPress a block is iframe-ready; it does nothing to make it so. The verification burden falls on the developer, not the flag. 3. **Silent wrongness is worse than an error.** Nothing in this migration throws — blocks just quietly measure the wrong window, miss clicks, or load unused stylesheets — which is why proactive audit beats waiting for bug reports. ## Claim atoms ### Declaring readiness is not becoming ready > [!quote] ID:rw_iframe_h1 > It's a promise, not the work. Where/why: [18:20], on setting `apiVersion: 3` in block.json. The cleanest available statement of the gap between a declaration and the state it declares. Already promoted — see [[3. Resources/Permanent Notes/Declaring Readiness Is Not Becoming Ready]]. ### Silent wrongness costs more than errors > [!quote] ID:rw_iframe_h2 > No error, just wrong, which is worse than an error. Where/why: [07:00], a block reading `window.innerWidth` reports the admin window and never updates in tablet preview. Names the risk property directly: a failure that announces itself is cheap to find. Already promoted — see [[3. Resources/Permanent Notes/Silent Failures Cost More Than Loud Ones]]. ### Events never cross an iframe boundary > [!quote] ID:rw_iframe_h3 > DOM events do not bubble across an iframe boundary, ever. Where/why: [10:30], why the standard click-outside dropdown pattern breaks. A listener on the admin document never hears clicks inside the canvas — directly explains bug reports closed as "cannot reproduce" by testers on un-iframed sites. ### Start from the element, not the global > [!quote] ID:rw_iframe_h4 > `element.ownerDocument` gives you whatever document the block really lives in. Where/why: [08:00], the fix that resolves most of these bugs. Version-agnostic by design — un-iframed, `ownerDocument` is just the admin document, so behavior is unchanged either way. Pairs with `useRefEffect` so listeners follow a remounted element. ### Defensive scoping became the defect > [!quote] ID:rw_iframe_h5 > The stylesheet is in the room and the selector is describing the other room. Where/why: [13:40], editor CSS scoped with `.wp-admin` matches nothing inside the canvas document. The scoping was deliberate and responsible when written; the fix is deletion, not migration, because the boundary those hacks were fighting now exists structurally. ## Permanent candidates - Both candidates from this source (P1: a compatibility flag records intent not conformance; P2: silent failures cost more than loud ones) were **already promoted in a prior synthesis pass** — see [[3. Resources/Permanent Notes/Declaring Readiness Is Not Becoming Ready]] and [[3. Resources/Permanent Notes/Silent Failures Cost More Than Loud Ones]]. Do not recreate; this pass only backfills the missing Literature Note. ## Processing checklist - [x] Confirmed this doc's `notes` field already contained a full deep-read (Refactor Appendix present) — ported directly - [x] Checked for existing Permanent notes before promoting H1/H2 — both already exist from a prior pass; linked instead of duplicated - [x] Connect into the relevant MOC — [[3. Resources/MOCs/Product & Startup Instincts MOC]] ## Links - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — the declared-readiness-vs-conformance pattern applies beyond WordPress to any self-attested compatibility flag - [[3. Resources/Readwise/Articles/WordPress 7.1 Is Coming. Are Your Custom Blocks Ready]] — source document - [[3. Resources/MOCs/WordPress Platform Design MOC]] — applies-in: Covers block editor changes in a core release, a WordPress platform topic.