• Initial proposal: Consider iframing the editor canvas/content #20797
• Related announcement: https://make.wordpress.org/core/2021/06/29/blocks-in-an-iframed-template-editor/

We aim to have all editors work as iframes in the future.

The announcement was posted in 2021, and since then, we have tried several times to make the legacy post editor work as an iframe. However, we were forced to revert those efforts, mainly due to concerns from users, or plugin developers who were not yet ready for the iframe editor. We need to figure out how to migrate the legacy post editor to the iframe in a sensible way.

Below is my understanding of the history so far and my thoughts. Any points I have missed or new suggestions are welcome.

Why make the editor work as an iframe?

From my understanding, the biggest benefits are:

• Completely separates the editor canvas from the core, i.e. the styles for the dashboard. This is a very important factor in the effort to unify style specificity to 0-1-0.
• Width/height media queries work relative to the editor canvas, not the browser window.

When does the post editor work as a non-iframe editor?

This is determined by the useShouldIframe hook. In other words, the post editor works as a non-iframe editor when the following conditions are met:

• If the Gutenberg plugin is enabled:
  • The active theme is the classic theme
  • Desktop preview
  • v2 or lower block is registered
• If the Gutenberg plugin is not enabled:
  • Desktop preview
  • v2 or lower block is registered

What is the impact on consumers if the post editor always works as an iframe?

From my experience, the two major issues are:

Plugin doesn't work in iframe editor

Plugin developers need to work to make their products work properly in the iframe editor.

However, it seems that sometimes it is difficult to do so due to dependencies on third-party libraries and technical issues.

For example, see this issue: #47924

Resizable meta box UX

Getting both the iframe editor and the legacy meta box to work was a big challenge.

To solve this, the resizable meta box was introduced in the iframe editor (#64351). This resizable meta box was then introduced in the non-iframe editor (#66706). However, this new meta box was met with negative feedback from some users, so the PR was reverted.

If we decided to make the post editor always work as an iframe, it would mean forcing users to use this new meta box.

My Proposal

When to completely move to the iframe editor

I propose to move completely to iframes in WordPress 7.0.

WordPress 6.9 is scheduled for release on 2 December 2025, about three months after this issue was reported. Because we need to give users ample advance notice, migrating to the iframe editor in 6.9 may be difficult.

On the other hand, the release date of WordPress 7.0 has not yet been decided, but it will probably be 2026. Developers should have enough time.

Finding a more rational meta box behavior

As mentioned above, the resizable meta box has received negative feedback from many users. We may need to come up with another approach to replace this new meta box.

Tasks

Here are some tasks that may need to be addressed to move this issue forward: Please feel free to add any other tasks that may be needed.

• Display browser console warnings for blocks with apiVersion below 2: Blocks: Display browser console warnings for blocks with apiVersion below 2 #70783
• Only allow "apiVersion": 3 as a valid value in the block.json schema: block.json schema: Make the apiVersion field required and only allow 3 #71107
• Finding a more rational meta box behavior: @stokesman has released a plugin to test the new meta box behavior. You may be able to proceed with the implementation based on this. https://github.com/stokesman/wheel-meta-boxes
• Adding documentation to the Block Handbook to help developers migrate to version 3 blocks so that their blocks work correctly in the iframe editor
  • Blocks: Display browser console warnings for blocks with apiVersion below 2 #70783
  • block.json schema: Make the apiVersion field required and only allow 3 #71107