Post editor: always iframe

[ellatrix]

What?

Consistently iframes the post editor. Fixes #54095. Fixes #65172.

Why?

We're sort of in a "damned if you do, damned if you don't" scenario.

Themes and plugins are used to having content appear in an iframe and often don't consider both iframed and non-iframe editors, which causes a lot of frustration when an editor suddenly switches to a non-iframed if the user installs a plugin with a API v1 or v2 block. For example: https://x.com/thekevingeary/status/1803760573718397081.

On the other hand we might cause some breakage for some blocks that don't render or function well in an iframe. Out of caution we disable the iframe when there any plugin adds any block that is less than version 3, even though they might function fine. (We check for installed blocks rather than inserted blocks because we don't want to flip this mid editing.)

We're probably at a point where far more breakage is caused by the inconsistency than blocks not functioning well with iframe.

Let's enforce the iframe early in Gutenberg so that we get early feedback about the non functioning blocks. That way we can work on one of the back-compat techniques described in #73138 (comment).

Note that in Gutenberg, we are already enforcing the iframe in the post editor when a theme is block-based. So within Gutenberg, this PR changes it so it's also enforced when a plugin installs non-v3 block AND there's a classic theme. Again, note that we already iframe when there's a classic theme and there's only v3 blocks (fresh install).

How?

Remove the conditions.

Testing Instructions

Testing Instructions for Keyboard

Screenshots or screencast

Before	After

[t-hamano]

It's going to take some courage for me to merge this, but let's try it as soon as possible 😅

P.S. Some E2E tests may fail, so we'll need to fix them. Try searching for // To do: run with iframe. or switchToLegacyCanvas() for tests.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @chimok, @tcmulder.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: chimok, tcmulder.

Co-authored-by: ellatrix <ellatrix@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: annezazu <annezazu@git.wordpress.org>
Co-authored-by: stokesman <presstoke@git.wordpress.org>
Co-authored-by: joedolson <joedolson@git.wordpress.org>
Co-authored-by: kubiqsk <kubiq@git.wordpress.org>
Co-authored-by: USERSATOSHI <tusharbharti@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[t-hamano]

Maybe switchToLegacyCanvas() should be deprecated - it does nothing anymore.

[github-actions]

Size Change: -313 B (0%)

Total Size: 7.61 MB

📦 View Changed

Filename	Size	Change
build/scripts/edit-post/index.min.js	52 kB	-227 B (-0.43%)
build/scripts/editor/index.min.js	489 kB	-36 B (-0.01%)
build/styles/edit-post/style-rtl.css	3.48 kB	-6 B (-0.17%)
build/styles/edit-post/style-rtl.min.css	2.11 kB	-7 B (-0.33%)
build/styles/edit-post/style.css	3.48 kB	-6 B (-0.17%)
build/styles/edit-post/style.min.css	2.12 kB	-6 B (-0.28%)
build/styles/editor/style-rtl.css	30.9 kB	-6 B (-0.02%)
build/styles/editor/style-rtl.min.css	26.2 kB	-6 B (-0.02%)
build/styles/editor/style.css	31 kB	-8 B (-0.03%)
build/styles/editor/style.min.css	26.2 kB	-5 B (-0.02%)

_{compressed-size-action}

[ellatrix]

@t-hamano Yeah, I'm aware, I'm intentionally letting them fail once so I can catch them all at once

[ellatrix]

Oh wow, I didn't know there's no many cases of editor.switchToLegacyCanvas

[Mamaduka]

Thank you, Ella!

Besides fixing the e2e tests, we should probably scan the WP.org directory for blocks that are still using the old API versions and send them a friendly notification with a migration guide.

IIRC, this has been done before, so there will be folks who can help us. Let's coordinate this effort after the holidays.

[annezazu]

It's after the holidays and we're a month away from beta 1. @justintadlock could you potentially help with this kind of review above?

we should probably scan the WP.org directory for blocks that are still using the old API versions and send them a friendly notification with a migration guide.

[ellatrix]

Yes, let me clean up the e2e test and let's get this in trunk asap.

[stokesman]

It can be done separately but there is some styling to update or remove. Mostly to do with the class name added here:

gutenberg/packages/editor/src/components/visual-editor/index.js

Line 408 in 8c7f99a

'is-iframed': ! disableIframe,

Also, I think a few private components in the editor package have related props that can be removed.

[ellatrix]

Also, I think a few private components in the editor package have related props that can be removed.

I'm not sure if we should remove it from the block editor's canvas component. We should still allow third party developers to build editors without an iframe. Some use cases may not require style isolation etc.

[t-hamano]

All dead code has been removed.

[Mamaduka]

Thanks, @t-hamano!

There should be no blockers. I think we can proceed with this PR, but I just wanted to suggest a more cautious approach in #79819.

I understand. IMO, all past cautions and changes were leading to this. We'll have to make a final decision at some point.

P.S. It would be good to share this with others in the release squad for a (extra) thumbs-up.

[t-hamano]

@annezazu @joedolson @ellatrix @youknowriad @Mamaduka @mcsf @stokesman

I am pinging the release lead for version 7.1, the tech lead, and everyone who contributed to this effort. With this pull request, we propose to force an iframe for the post editor in the 7.1 release.

Please refer to this document for background information:

• https://github.com/WordPress/gutenberg/blob/remove/iframe-condition/docs/reference-guides/block-api/block-api-versions/block-migration-for-iframe-editor-compatibility.md#when-will-the-post-editor-work-as-an-iframe
• https://make.wordpress.org/core/2026/02/24/iframed-editor-changes-in-wordpress-7-0/

This PR might cause issues for blocks that do not yet support iframes, but we have been urging testing in the iframe editor for years. Furthermore, since the iframe editor has been enforced for several months whenever the Gutenberg plugin is active, any problems should have been reported on WordPress.com where the Gutenberg plugin is enabled.

The more cautious alternative in the 7.1 release is #79819. This approach enforces the post editor only for block themes.

[annezazu]

I assume if we proceed with this approach ahead of beta 1 and a lot of feedback is given after beta 1 that there are issues, we can move to the softer approach. Assuming that is correct, I am okay proceeding as is. I agree we've given this a lot of time. @justintadlock can I lean on your folks to get the word out here and start preparing content around this?

[t-hamano]

Based on the reactions and comments, I believe we have received generally positive feedback on this PR. If there are no further objections, I intend to merge this next week before Beta 1.

[joedolson]

I will test further after this is merged. I don't believe that anything has changed from the accessibility perspective; the iframe is an undesirable change, but not an inaccessible change no matter what the mechanism of implementation is. But once it's merged I'll explore whether there's anything we can do to mitigate those annoyances.

[t-hamano]

For now, let's merge this, and if the impact is too significant, we can try a more conservative approach.

[ellatrix]

Sounds good, when we get reports of issues, we can figure out ways to move forward from there instead of working with hypotheticals

[t-hamano]

I learned that @ryanwelcher has released a great repository to demonstrate how forcing an iframe can affect custom blocks. This repository will be very useful for developers who want to prepare for an iframe editor.

https://github.com/ryanwelcher/iframe-editor-examples