WordPress 7.0 is tweaking the iframed editor logic again, and if you have spent any time debugging CSS leaks in the block editor, you know why this matters. The goal has always been full isolation—keeping the admin dashboard styles from bleeding into the content canvas. However, the path to getting there has been messy.
The Shift: From “Registered” to “Inserted”
Previously, the WordPress 7.0 Iframed Editor logic was fairly rigid. If even one plugin registered a block using an older API version (v2 or lower), core would often bail on the iframe entirely to ensure compatibility. This was a “weakest link” approach that penalized clean sites because of one legacy plugin.
Specifically, the update in WordPress 7.0 moves to a per-post check. Instead of scanning every registered block on the site, the editor now checks the blocks actually inserted in the post. If all blocks on the canvas are API version 3 or higher, you get the iframe. If you drop in a legacy block, the iframe is removed dynamically.
I have seen this break complex layouts when a client insists on using a “tried and true” plugin from 2019. For a deeper look at why this isolation is critical, check out my previous post on Gutenberg block iframe compatibility.
Enforcing Block API Version 3
The core team is essentially giving us a “soft” nudge. While they aren’t forcing the iframe unconditionally in 7.0, the Gutenberg plugin (starting version 22.6) will start enforcing it for classic themes to gather “war stories” from developers before the final hammer drops.
If you are still shipping blocks with apiVersion: 2, you are essentially the bottleneck. Upgrading to version 3 is straightforward but requires you to ensure 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 are telling WordPress that your block is “iframe-safe.” This means you aren’t relying on global window objects or parent-level CSS selectors that won’t exist inside the isolated environment. You can find the full technical requirements in the official API documentation.
The Gutenberg Rollout Strategy
Furthermore, the timeline has been revised. The initial plan to force the iframe on everyone in WordPress 7.0 was walked back in favor of a gradual rollout. This is a rare moment of core pragmatism—admitting that the ecosystem isn’t fully ready for a hard break.
Consequently, if you are running a classic theme, you might notice the editor behaving differently if the Gutenberg plugin is active. This is the testing ground. If your block breaks, now is the time to refactor, not when 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 a win for performance and stability. It allows modern blocks to benefit from iframing without breaking legacy content. However, the long-term goal remains full enforcement. Start auditing your custom blocks today and make the jump to API version 3. It’s better to refactor now than to debug a “disappearing editor” ticket later.
