Post editor: always iframe #74042
Open
Post editor: always iframe #74042
+15
−56
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ellatrix
added
[Package] Edit Post
t-hamano
reviewed
Dec 16, 2025
Contributor
t-hamano
left a comment
t-hamano
left a comment
There was a problem hiding this comment.
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.
|
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 Unlinked AccountsThe 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. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Contributor
|
Maybe |
|
Size Change: -195 B (-0.01%) Total Size: 3.1 MB
ℹ️ View Unchanged
|
Member
Author
|
@t-hamano Yeah, I'm aware, I'm intentionally letting them fail once so I can catch them all at once |
Member
Author
|
Oh wow, I didn't know there's no many cases of |
Member
|
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. |
Contributor
|
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?
|
Member
Author
|
Yes, let me clean up the e2e test and let's get this in trunk asap. |
ellatrix
force-pushed
the
remove/iframe-condition
branch
from
d8eac59 to
2127944
Compare
Contributor
|
It can be done separately but there is some styling to update or remove. Mostly to do with the class name added here: Also, I think a few private components in the editor package have related props that can be removed. |
ellatrix
force-pushed
the
remove/iframe-condition
branch
from
2127944 to
98f7dd5
Compare
This was referenced Jan 26, 2026
ellatrix
force-pushed
the
remove/iframe-condition
branch
from
98f7dd5 to
3d665d0
Compare
ellatrix
force-pushed
the
remove/iframe-condition
branch
from
3d665d0 to
428790e
Compare
Member
Author
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. |
|
Flaky tests detected in b9b2b4e. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/21361868362
|
Contributor
I think what @stokesman is talking about is not the gutenberg/packages/edit-post/src/style.scss Lines 22 to 24 in b9b2b4e gutenberg/packages/edit-post/src/components/layout/style.scss Lines 126 to 128 in b9b2b4e gutenberg/packages/editor/src/components/visual-editor/style.scss Lines 32 to 34 in b9b2b4e |
Contributor
|
Another concern is that the iframe post editor forces new meta boxes, which has caused a lot of user backlash over the UI. See #69923 for more details. From what I understand, the biggest complaint for many users is that they can no longer access meta boxes by scrolling. I remember @stokesman doing some interesting work on this. #69923 (comment) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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