1. Overview
2. Current Situation
3. What's changing in WordPress 7.1
4. What should block developers do?

Previous posts on this topic:

• Iframed Editor Changes in WordPress 7.0 (February 2026)
• Preparing the Post Editor for Full iframe Integration (November 2025)
• Blocks in an iframed (template) editor (June 2021)

For several releases, WordPress has been moving its editors into an iframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser., 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.

Every editor except the post editor — the site editor, the template editor, and all block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. 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 The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. was active and the blocks in use.

• In WordPress 7.0, the decision was based on the block API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. 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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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.

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.

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 (and super 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