-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Iframe the editor content #21102
Iframe the editor content #21102
Conversation
Size Change: +732 B (0%) Total Size: 1.28 MB
ℹ️ View Unchanged
|
Getting pretty close 😄 |
842a623
to
b49c215
Compare
Should now work with all themes! (Tested Twenty Twenty and Twenty Nineteen.) |
Everything should be working well, it's almost done. Biggest things remaining is fixing the embed sandbox and adjusting the remaining e2e tests. |
packages/block-editor/src/components/block-navigation/dropdown.js
Outdated
Show resolved
Hide resolved
@ellatrix Do you think it's doable? This would make it a lot easier to have proper responsive previews and styling and make Gutenberg a truly Wysiwyg |
Yes, I think it would work. The only blocker is that some blocks using non-React libraries may be using the wrong window/document. To solve this we could still preview the save version in the editor and allow editing through a modal loaded in the parent window. And of course encourage these blocks to update to the right window/document, or the library that it uses. So it kind of depends how much we would mind and how many blocks there would be like this. |
@ellatrix do you mean that 3rd party libraries using |
It may cause problems. It is possible to use window and document correctly if it's based on the block node ( How would you proxy? You have two different windows, of which the block needs to use different things. You cannot combine these. And we cannot predict what the block needs. |
After chatting with some people, we're thinking it may be interesting to try this for full site editing and block previews, but leave the post editor alone for now to give blocks some time to make their blocks work in iframe mode (full site editor and previews). If we use the iframe for the post editor now, we may need some fallback mechanism for blocks that have problems loading. I'm not sure how we'd detect these problems though. E.g. a block may be using some jQuery library to render the content. |
Considering the current state of theme support for the block editor, I really want to see this land. Combined with the ongoing removal of editor-only block wrapper |
72f3936
to
8ce248c
Compare
It would be great to get an update and hear how things are going @ellatrix Thanks! |
Going through and testing this, and it's looking good so far, thank you! I noticed that this PR could use a refresh/rebase, and haven't yet tested it out with trunk. |
Sounds great Mike! |
I'm doing some preparatory work still, like #29573. Ideally after this we enable the iframe in the template editor and maybe add an option for the post editor. |
#31375 iframes the template editor. |
We plugin authors need a guide on what you mean by the correct window |
Hi @saas786 can you take a look to see if you can help land this? Watch out for getting into a rabbit hole, though, it's OK to bow out in favor of more reachable targets. |
Tried to test out this PR via try/iframe branch. There is conflict with WordPress 5.9.3 like:
So will be nice if you rebase try/iframe so can test it out. Also when tried to edit page via Template Editor: I found WooCommerce Memberships plugin blocks broke the page. Deactivating the plugin resolves the issue. So plugins incompatible with Iframe based solution includes at least:
|
Is rebasing this beyond our own current team ability? |
It involves 1.5 years worth of commits, say about 6103 commits behind trunk. So that will take quite a bit of effort & time. @ellatrix is the right person to rebase it safely, as I am sure lots of APIs have changed since too. So code will not only need rebasing, but updating too. |
Refresher discussion in #core-editor. There's at least these blockers, if not more:
For iframed Site Editor, this worked out, because we don’t support classic blocks or meta-boxes from the start. For post editor, it would be a big breaking change. Of the above, meta boxes probably cannot be negotiated. Currently not sure what could be next, but my company is still interested in sponsoring someone skilled enough to try to figure these things out. Find me on #core-editor. |
Update: I will soon create a new PR that adds the iframe to the post editor if a theme is a block based theme. Seems like the best way to move forward is in small steps, so enabling it only for block based themes is prudent. |
Also, if we detect any meta boxes or classic editor, we can avoid the iframe for now. |
Let's continue in #46212. |
Description
Fixes #20797.
Fixes #21193.
Fixes #6156.
See #25775 for FSE.
How has this been tested?
Screenshots
Types of changes
Checklist: