WordPress 7.0 tweaks the iframed editor logic again, and if you’ve spent any time chasing down CSS leaks in the block editor, you already know why that matters. The goal has always been full isolation: keeping admin dashboard styles from bleeding into the content canvas. Getting there, though, has been messy.
The shift: from “registered” to “inserted”
Before this change, the WordPress 7.0 Iframed Editor logic was pretty rigid. If even one plugin registered a block on an older API version (v2 or lower), core would often bail on the iframe entirely just to stay safe. It was a “weakest link” setup: one legacy plugin could cost a clean site its isolation.
The update in WordPress 7.0 moves to a per-post check instead. Rather than scanning every block registered on the site, the editor now looks at what’s actually inserted in the post. If every block on the canvas is API version 3 or higher, you get the iframe. Drop in one legacy block, and the iframe gets removed on the spot.
I’ve seen this break complex layouts when a client insists on running a “tried and true” plugin from 2019. For more on why the isolation matters, see my earlier post on Gutenberg block iframe compatibility.
Enforcing block API version 3
The core team is giving us a soft nudge here. WordPress 7.0 itself won’t force the iframe unconditionally, but the Gutenberg plugin (starting at version 22.6) will start enforcing it for classic themes, mostly to collect “war stories” from developers before the final hammer drops.
If you’re still shipping blocks with apiVersion: 2, you’re the bottleneck now. Upgrading to version 3 isn’t hard, but you do need to make sure your styles are properly enqueued for the iframe environment.
{
"name": "bbioon/custom-cta-block",
"title": "Custom CTA",
"apiVersion": 3,
"editorStyle": "file:./index.css",
"style": "file:./style-index.css"
}By declaring apiVersion: 3 in your block.json, you’re telling WordPress your block is “iframe-safe.” That means no reliance on global window objects or parent-level CSS selectors that won’t exist inside the isolated environment. The full technical requirements are in the official API documentation.
The Gutenberg rollout strategy
The timeline got revised too. Core’s original plan to force the iframe on everyone in WordPress 7.0 was walked back in favor of a gradual rollout, a rare bit of pragmatism that admits the ecosystem isn’t ready for a hard break yet.
If you’re running a classic theme, you might notice the editor behaving differently once the Gutenberg plugin is active. That’s the testing ground. If your block breaks now, fix it now, not after the 7.0 stable release hits your clients’ production sites.
Look, if this WordPress 7.0 Iframed Editor stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final takeaway for developers
The “per-inserted-block” check is good for performance and stability. It lets modern blocks benefit from iframing without breaking legacy content. The long-term goal is still full enforcement, though, so start auditing your custom blocks now and make the jump to API version 3. Better to refactor today than debug a “disappearing editor” ticket later.
