Core published a dev note this morning confirming something that has been drifting toward inevitability for two releases: the iframed post editor is now unconditional in WordPress 7.1.
Not iframed for block themes. Not iframed when the content qualifies. Always.
Starting in WordPress 7.1, the post editor is always iframed, regardless of the theme type, the block API versions of the registered blocks, or the block API versions of the blocks in the content.
The word doing the work there is regardless. Every condition that previously decided whether you got an iframe is gone, and that has an awkward implication for anyone who has already tested their blocks and concluded they were fine.
What the conditions used to be
This is the part worth understanding, because it explains why so many developers will be surprised.
Before WordPress 7.0, whether the editor was iframed depended on whether the Gutenberg plugin was active. Two developers on the same codebase could see different behaviour based on a plugin one of them had installed.
In WordPress 7.0, it depended on the block API versions of the blocks in the post content. If every block in the post was API v3 or higher, you got an iframe. If a single block anywhere in the content was on a lower version, the whole editor fell back to no iframe.
In 7.1, none of that applies.
Read that 7.0 rule again, because it is the trap. Iframing was decided by the content, not by your block. One legacy block in a test post, an old shortcode wrapper, a v2 block from a plugin you had installed for something else, anything, and the editor silently ran unframed. Your block appeared to work. It was never tested in the iframe at all.
That is the specific reason “we already checked” is not a safe answer here. A lot of people checked under conditions that suppressed the thing they were checking for.
How to know whether you actually tested it
The honest way to find out is to look, not to remember.
Open a post in the editor on 7.0 and run this in the browser console:
document.querySelector( 'iframe[name="editor-canvas"]' ) ? 'IFRAMED' : 'NOT IFRAMED'If it returns NOT IFRAMED on a post you used for testing, that test told you nothing about 7.1.
Then check what was suppressing it:
wp.blocks.getBlockTypes()
.filter( b => ( b.apiVersion || 1 ) < 3 )
.map( b => `${ b.name } (v${ b.apiVersion || 1 })` );Any block from your own plugin in that list is a block you need to look at. Blocks from other plugins matter too, because in 7.0 their presence was masking the iframe for everyone.
The cleanest test for 7.1 behaviour is a post containing only your blocks, on a Beta install. If you cannot get to Beta, at minimum re-test on a post where the console check above returns IFRAMED.
What actually breaks
The failure mode is narrow and specific. An iframe has its own document and its own window. Code that reaches for the globals gets the admin page, not the editor canvas, and the two are now different documents.
So anything of this shape is suspect:
// Wrong inside an iframed canvas - this is the admin document.
const el = document.querySelector( '.my-block-target' );
window.addEventListener( 'resize', onResize );The fix core points at is to reach the canvas document through the node you already have, using ownerDocument and defaultView:
const doc = myElement.ownerDocument; // the canvas document
const view = doc.defaultView; // the canvas window
const el = doc.querySelector( '.my-block-target' );
view.addEventListener( 'resize', onResize );And for attaching listeners to canvas elements, core recommends useRefEffect, which gives you the node and handles cleanup when it goes away:
import { useRefEffect } from '@wordpress/compose';
const ref = useRefEffect( ( node ) => {
const view = node.ownerDocument.defaultView;
const onScroll = () => { /* ... */ };
view.addEventListener( 'scroll', onScroll );
return () => view.removeEventListener( 'scroll', onScroll );
}, [] );We covered this pattern in more depth when React 19 was pulled from 7.1 and the iframe turned out to be the real compatibility story of the release. What is new today is not the fix, it is the confirmation that there is no longer any configuration in which you avoid needing it.
Where to look in your own code
A quick audit, in rough order of how often it finds something.
Direct global queries in block edit components. Grep for document.querySelector, document.getElementById and document.body inside anything that renders in the canvas. Each one needs to become an ownerDocument lookup or be justified as genuinely wanting the admin document.
Global event listeners. window.addEventListener for resize, scroll or click, registered from a block. Scroll is the one that fails most visibly, because the canvas scrolls independently of the admin page.
Third-party libraries initialised on a node. Anything that takes an element and does its own measuring or listener attachment, sliders, chart libraries, masonry layouts, lightboxes. These are the hardest to fix because the global access is inside somebody else’s code. Check whether the library accepts a document or window option; many do.
Anything measuring viewport size. window.innerWidth inside the canvas now reports the admin window, not the canvas, which is a different number and usually the wrong one.
Editor styles. Styles enqueued with adminenqueuescripts do not reach inside the iframe. If your block looks correct today and wrong after 7.1, this is the first place to look, the fix is addeditorstyle() or theme.json, not a heavier admin stylesheet.
While you are in there, the permanent 40px control default lands in the same release and affects the same components. Both are worth auditing in one pass rather than two, since the files you open are largely the same.
The symptoms, so you recognise them
Iframe problems rarely announce themselves. Nothing throws, nothing appears in the debug log, and the block usually renders. What you get instead is a set of oddly specific misbehaviours that are easy to blame on something else.
A tooltip or popover positioned wrongly. Usually offset by exactly the height of the admin bar or the editor header, because the positioning maths measured against the wrong document. This is the most common single symptom.
A listener that fires once and then never again, or never fires at all. Attached to the admin window, while the interaction happens in the canvas.
A block that renders unstyled in the editor but correctly on the front end. Editor styles not reaching inside the iframe.
Something that works on first insert and breaks after a reload. Timing - the code found the right document during one lifecycle and the wrong one during another.
A library that measures zero. Charts with no height, sliders with no width, masonry layouts collapsing to a column. The library asked the document for dimensions and got a document where its container does not exist.
Every one of those looks like a CSS bug or a race condition on first inspection. If you are seeing any of them in the editor and not on the front end, check the document before you debug anything else.
Why core did this
Worth understanding rather than treating as churn, because it explains why this is not going to be reversed.
The whole point of the iframe is isolation. Without it, admin CSS leaks into the content you are editing, which means what you see in the editor is systematically not what visitors see. Every “it looked fine in the editor” bug ultimately traces back to that.
The conditional approach was a compatibility ramp, iframe where it is safe, fall back where old blocks might break. Ramps have to end, and the cost of keeping this one was that the editor behaved differently depending on post content, which is close to the worst property a development environment can have. A bug that appears only when a particular legacy block happens to be present is a bug nobody can reproduce.
Making it unconditional means one behaviour, always, testable. That is worth a migration.
What about the Site Editor?
Worth clearing up, because the dev note is specifically about the post editor and that wording is deliberate.
The Site Editor has been iframed for considerably longer. If your blocks are used in templates and template parts, they have been running inside an iframe there for some time, which is why a certain class of bug has historically reproduced in the Site Editor but not the post editor.
That asymmetry is what 7.1 removes. If you have ever had a report along the lines of “this block is broken in the site editor but fine in the post editor” and quietly deprioritised it, that bug is about to arrive in the post editor too. It is worth going back through anything closed as site-editor-only before August.
Conversely, if your blocks already work correctly in the Site Editor, you have good evidence they will survive this change. That is the cheapest test available to most people: insert your block into a template, and if it behaves there it is very likely fine.
What to do before 19 August
Three things, in order.
Confirm you have actually seen your blocks inside an iframe. Use the console check above. If the answer is no, everything else you concluded from that testing session is unverified.
Grep for the four patterns in the audit section. On most plugins this is a short list, and the fix per site is mechanical.
Test with a post containing only your own blocks. Mixed content was the thing masking this in 7.0, and a clean post is the only way to see 7.1 behaviour before 7.1 exists.
If you maintain a plugin that extends blocks rather than registering its own, a formatting toolbar, a sidebar panel, a block filter, you are equally affected and slightly more likely to have missed it, because that code often runs in the admin document and the canvas document at different times.
One thing not to do
Do not reach for window.parent or window.frames to bridge between the two documents. It works, which is what makes it tempting, and it hard-codes an assumption about the editor’s structure that core has already changed twice in two releases.
The ownerDocument approach is not just the recommended fix, it is the one that keeps working if the canvas moves again. Code that asks “which document does this node belong to” is correct in an iframe, correct without one, and correct in whatever comes next. Code that says “go up one frame” is correct only under today’s arrangement.
Same reasoning applies to detecting the iframe and branching. If you find yourself writing if ( isIframed ) { ... } else { ... }, you are maintaining two code paths where one would do, and the else branch is now dead in 7.1 anyway.
The change itself is one sentence and it is the kind of thing that reads as minor. It is not, because of what it removes: the ability to accidentally test the old behaviour and believe you tested the new one.
That is the useful takeaway. Not “the editor is iframed”, most people knew that was coming. It is that in 7.0 the iframe could be switched off by content you did not control, which means a clean test result from last month may have been measuring nothing at all.
No comments yet