Post editor: iframe: check inserted rather than registered block versions#75187
Merged
Post editor: iframe: check inserted rather than registered block versions#75187
Conversation
|
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 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. |
|
Size Change: +46 B (0%) Total Size: 3 MB
ℹ️ View Unchanged
|
Member
|
If we want to do this check only on actual insertion, we could expose Pros: The check will run less often, not on page load, not when blocks are moved around, etc. |
github-project-automation
bot
moved this to 🔎 Needs Review
in WordPress 7.0 Editor Tasks
Contributor
|
My gut feeling is that this approach may be more confusing, one reason being meta boxes, which change the UI depending on whether the editor is an iframe or not. 958c1ebdf9c4cb224548624e6a80899e.mp4The legacy meta box UI depends on whether the editor is an iframe or not, which means that inserting or removing blocks from v2 or lower will change the meta box UI. If it is difficult to proceed with #74042 at this time, is it possible to take a more conservative approach and relax some of the conditions? For example, if the Gutenberg plugin is enabled, always force the iframe editor. diff --git a/packages/edit-post/src/components/layout/use-should-iframe.js b/packages/edit-post/src/components/layout/use-should-iframe.js
index 4da4f43fe93..f100d7e5b13 100644
--- a/packages/edit-post/src/components/layout/use-should-iframe.js
+++ b/packages/edit-post/src/components/layout/use-should-iframe.js
@@ -22,11 +22,8 @@ export function useShouldIframe() {
const { getBlockType } = select( blocksStore );
return (
- // If the theme is block based and the Gutenberg plugin is active,
- // we ALWAYS use the iframe for consistency across the post and site
- // editor.
- ( isGutenbergPlugin &&
- getEditorSettings().__unstableIsBlockBasedTheme ) ||
+ // If the Gutenberg plugin is active, we ALWAYS use the iframe.
+ isGutenbergPlugin ||
// We also still want to iframe all the special
// editor features and modes such as device previews, zoom out, and
// template/pattern editing.cc @stokesman for visibility |
Member
Author
|
@t-hamano Yes, we can be be more strict for Gutenberg, but this PR was specifically with 7.0 in mind. In that case, I think we might have to make the meta box UI the same, I'm actually not sure what this isn't currently the case? Otherwise, we'll just have to warn the user when insertion of specific blocks will trigger some changes in UI. @Mamaduka What's your concern with the current selector? |
Contributor
We have tried in the past to unify the meta box UI whether the canvas is an iframe or not (#66706). However, this attempt received backlash from users and was reverted before the official WP release (#69958). I understand that the biggest reason for the backlash was that the meta box could no longer be accessed with just a mouse wheel. I believe this issue will be resolved by #75220 |
Member
Author
What do you mean? This is only the case for non-iframe, so the backlash was specifically for non-iframe? I'm not sure I understand. In most cases, the iframe will be there? |
ellatrix
force-pushed
the
update/iframe-check-inserter-block-versions
branch
from
5f335fe to
889bdfd
Compare
Member
Author
Member
|
No big concerts regarding the current selector. It was a general suggestion that, if we wanted the editor to react to actual block insertion rather than block existence on the canvas. After 3ed79cd, we always display non-legacy metaboxes in the canvas. Is that correct? We could give this metaboxes behavior a try, but I'm not very optimistic about user feedback 😞 cc @stokesman Update I noticed that canvas isn't displayed correctly after inserting a block with the old API version. ScreencastCleanShot.2026-02-10.at.15.25.45.mp4 |
Member
Author
|
@Mamaduka Hm strange, I'm not seeing that (see my video). Can have a look again later for different screen sizes.
yes, we currently show them collapsed for iframe and uncollapsed for non-iframe, which is completely random. Most people will have the iframe and non-collapsed version. So if you install a plugin and it has a v2 block, you'll suddenly get uncollapsed meta boxes. And if that plugin updates their blocks to v3, you now get collapsed meta boxes again. We should have one consistent experience. |
Member
Member
Author
|
It's the same for enforcing the iframe everywhere: everyone will get the collapsed meta boxes. It's unavoidable. And yes, I mentioned we can attempt the mouse wheel thing, I think it's even ok to add that as a bug fix after Beta. Either way is fine to me |
Contributor
|
I'm seeing the same layout issues, but more "broken": 
Happening on macOS Sequoia, same across Safari, Firefox and Chromium (Brave). Deleting the v1 block restores the layout correctly: iframing-layout-restore.mov |
Member
Author
Contributor
|
I gave this a quick test and saw the layout issues. If we're going to always use the split view, I suggest we use the prior work on that initially done in #66706. To that end, I made a branch [UPDATE: deleted branch and link] from this PR which reapplies them by reverting 06e66d8. Hah, which is now not quite based on this branch because it just got pushed to. I’ll retest this one. |
Member
Author
|
@stokesman Thanks, I don't quite understand why we need |
Contributor
|
I retested and didn’t spot any issues.
To make it work even for device previews. I guess that’s not the point here though. |
Member
Author
|
Ah right, I wouldn't mind if we attempted device previews in a separate PR to reduce the surface to test. For device previews I think there need to two scrollable areas to match what the iframe does. But to be honest, I'm not sure why we need the meta boxes for device previews in the first place 🤔 |
Mamaduka
approved these changes
Feb 11, 2026
Member
There was a problem hiding this comment.
This works well for me now, and I can no longer reproduce the broken layout issue. I'm pro merging this early for better testing and then working on follow-ups like #75220 and device previews.
Maybe we could even arrange an early call to test, instead of just mentioning the changes in the Dev Notes. cc @marybaum
Contributor
I just noticed #75121 seems to side-step the concern. The resizable editor not having a fixed height means the top area doesn’t have to be scrollable I think. |
ellatrix
added
the
Needs Dev Note
Member
Author
|
Let's try it |
github-project-automation
bot
moved this from 🔎 Needs Review
to ✅ Done
in WordPress 7.0 Editor Tasks
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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?
Alternative to #74042.
Rather than always enabling the iframe (post editor), check what blocks are inserted in the canvas rather than checking the registered blocks (what we currently do).
A slight downside is that it will remount the whole editor when inserting an incompatible blocks, but this should happen much more rarely than when we first added the iframe.
We could potentially add a notice somewhere that mentions that the editor is in a compatibility mode and there may be some issues, with a list of the block names causing the compatibility mode, though it doesn't seem ideal to show this to users.
Why?
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.
How?
We check the blocks in the canvas rather than the blocks registered.
We also adjust the meta boxes for non iframe mode to be collapsed at the bottom, exactly the same as iframe mode so that there's no shift in layout.
Testing Instructions
Activate a classic theme. Insert a v1 or v2 block. You can check the e2e test for an example:
Testing Instructions for Keyboard
Screenshots or screencast
Screen.Recording.2026-02-10.at.11.45.05.mov