Post editor now always iframed (v7.1) — WordPress Core Dev…

Previous posts on this topic:

Overview

For several releases, WordPress has been moving its editors into an iframe, starting with the template editor back in 5.8. In WordPress 7.1, the post editor takes the final step: it is now always iframed.

If you want the full reasoning behind the move, see Benefits of the iframe editor.

Current Situation

Every editor except the post editor — the site editor, the template editor, and all block template, and device previews — has been iframed unconditionally for some time. The post editor was the exception, and until now, whether it was iframed depended on the environment: whether the Gutenberg plugin was active and the blocks in use.

In WordPress 7.0, the decision was based on the block API versions of the blocks actually inserted in the post. If every inserted block was API version 3 or higher, the post editor was iframed; if any lower-version block was present, the iframe was dropped to preserve compatibility.
The Gutenberg plugin has been ahead of core here: since Gutenberg 22.6, when the plugin is active the post editor is forced to be iframed regardless of the theme type or the block API versions in use, so that compatibility issues surface early and can be reported before the change reaches core.

This conditional behavior kept older blocks working, but it also meant the post editor could switch between iframed and non-iframed modes depending on a post’s content.

What’s changing in WordPress 7.1

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.

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 site editor, template editor, and device previews have been iframed for a long time, so much of this ground is already well tested. Even so, please test that your custom blocks — and any plugins that extend blocks — work correctly in the fully iframed post editor. See WordPress/gutenberg#74042 for more details.

The site editor, template editor, and device previews have been iframed for a long time, so much of this ground is already well tested. Even so, please test that your custom blocks — and any plugins that extend blocks — work correctly in the fully iframed post editor.

See WordPress/gutenberg#74042 for more details.

What should block developers do?

Most blocks already work in the iframed editor without any changes. The issues that do come up almost always trace back to the same root cause: the iframe has its own document and window, separate from the admin page where editor scripts run. Code that reaches for the global document or window to touch the editor canvas will be looking at the wrong document.

The usual fixes are:

Get the canvas document from an element inside it, via ownerDocument and its defaultView, rather than the global document/window.
Use useRefEffect to attach and clean up event listeners on canvas elements.

For the full list of things to watch for and how to resolve them, see Technical considerations for the iframe editor.

Props to @tyxla for review.

#7-1, #dev-notes, #dev-notes-7-1

Post editor now always iframed