Closed wpsoul closed 1 year ago
Thanks for contributing, @wpsoul!
There's already a similar issue in the repo. See #41821.
I'm going to close this one as a duplicate.
@Mamaduka I don't think that it's similar. in #41821 report is about CSS, I have no problem with CSS, it's loaded inside iframe. My report is about scripts
Sorry, my mistake, @wpsoul.
I have added the ability to add block scripts to the iframe in #31873. It's true that there's no general API for adding scripts to the iframe except for blocks through block.json. Scripts added through enqueue_block_editor_assets
should not be added to the iframed content because these scripts are for editor UI. We shouldn't mix them.
May I ask what your use case is for adding a script to the editor content? You mention "scroll, position, drag, animation". Could you share a plugin, or some code?
@ellatrix I agree that we don't need to mix scripts in enqueue_block_editor_assets. But we need to have hooks to add something in iframe like we do in admin_head.
Examples:
We have option for animation in our plugin which is based on GSAP library. So, we need to track scrolling of window. But problem is that iframe is not even presented on page, it's loaded via scripting in Wordpress, so library simply can't detect iframe window. Even placing script in block doesn't help. Library just requires to be loaded directly in window which we want to track and we can't change this
The same for drag library. We have option to make absolute position in editor via simple drag of elements. Works good in post editor but not working properly in Site editor because iframe is loaded via scripts and after other scripts.
And mobile preview even worse, because we need to switch all logic how scripts are working between regular view and mobile preview. So, making everything in iframe is good step, but it must be followed with enough options for developers to hook inside iframe
The same for drag library. We have option to make absolute position in editor via simple drag of elements. Works good in post editor but not working properly in Site editor because iframe is loaded via scripts and after other scripts.
Ok, so is this dragging as in an edit action, or can you drag also on the front-end. Scripts in the iframe should be limited to scripts that would also be loaded on the front-end. If you're adding scripts for editing the content, then something is wrong.
If you're a block, it's easy to add drag listeners because you have access to the block element. Do you have a use case where you want to add drag listeners for blocks that are not your own?
Similar for the animation. Is this a script you're loading on the front-end? Could you point me to the libraries you're using and some example of how you're using them.
I just want to make sure that plugin authors don't start to abuse the ability to add scripts to the iframe for editing purposes.
@ellatrix Drag is working only in editor. I can't use it as part of block, because this feature is existing as component for many blocks. I don't agree that iframe must have things for frontend. For frontend we have a lot of hooks and frontend has no iframes, so, it's not a problem to modify frontend view. Problem is only in Editor, because it has complex layout where part of things (like styles) are loaded inside iframe, part of things are in main window + iframe is loaded not directly on page but via scripts, which makes many conflicts related to order of loading and scripts which make DOM manipulation.
Here is library
First, I want to apologize for my tone. This issue has not been adequately addressed in years and, at least for me, it has been a major stumbling block.
I'm hoping I just haven't discovered the way to load scripts and styles in iframed editors. Please let me know if there is a way.
Otherwise, I'm seeing the same issue as @wpsoul. I'm enqueueing scripts and styles in iframed page/post/site editors that are no longer being loaded in the iframed editors.
@ellatrix Drag is working only in editor. I can't use it as part of block, because this feature is existing as component for many blocks. I don't agree that iframe must have things for frontend. For frontend we have a lot of hooks and frontend has no iframes, so, it's not a problem to modify frontend view. Problem is only in Editor, because it has complex layout where part of things (like styles) are loaded inside iframe, part of things are in main window + iframe is loaded not directly on page but via scripts, which makes many conflicts related to order of loading and scripts which make DOM manipulation.
Here is library
I also don't agree that the iframe must have things on the frontend. I'm dynamically ( via JavaScript ) loading Tailwind CSS styles on the backend and statically ( CSS file ) loading styles on the frontend.
I've also created a plugin that allows Gutenberg users to use any Google font ( GDPR compliant google fonts via Bunny Fonts ) in the block editor, which no longer works due to the inability to load scripts and styles in block editors.
There needs to be a way for plugin authors to add scripts and styles to the iframe without being associated with any blocks. Unless, once again, is there a way of doing this that I'm missing?
@ellatrix Unfortunately, this issue is even more complex than I thought.
I made some plugin settings via
const { PluginSidebarMoreMenuItem, PluginSidebar } = wp.editSite;
Recently I found that this code is conflicting with Post Editor Template system. After investigation, I found that problem is in dependencies. If I have wp-edit-site dependency in script, it breaks wp-edit-post scripts. Ok, the solution can be to load script only for site editor. But guess what? Yes, we still have no any hooks or options to load scripts for site editor. I didn't find also any Gutenberg function to check if the current page is site editor or not.
Ok, so is this dragging as in an edit action, or can you drag also on the front-end. Scripts in the iframe should be limited to scripts that would also be loaded on the front-end. If you're adding scripts for editing the content, then something is wrong.
In our case, we would be loading a web components JS bundle both in block editor IFRAME, and on frontend.
It is the only way to get matching editor / frontend UX.
Hi! #49655 should be able to address this issue. This PR will load anything enqueued through enqueue_block_assets
to the iframe and adds a new action enqueue_block_editor_content_assets
for anything that you want to add to the iframe but not the front-end (editor content specific styles).
The reason we can't add assets enqueued through enqueue_block_editor_assets
is because this is meant for editor UI styles and scripts. We don't want to add those to the iframe. Ideally you should use enqueue_block_assets
if your style or script should be added to both the front-end and editor content, and enqueue_block_editor_content_assets
for only the editor content without front-end.
Hopefully we can merge #49655 soon so it can be tested in the plugin.
@ellatrix Any updates on this PR? I'm looking to use Web Components on the Frontend and in the iFrame editor like lkraav.
@hasanirogers Same. Stuck looking at a broken UI when in FSE with no way of fixing until scripts can be loaded inside the iframe.
I believe this issue has been resolved with the merging of #49655 as well as #41821. I would like to close this issue, but if I have missed something, please feel free to comment.
Description
I checked latest Field Guide 6.1 and I still can't see anything related to issues which are reported by many times over few years.
All scripts are loaded outside Iframe and there is no solution to load scripts or code inside iframe. This makes all script libraries related to scroll, position, drag, animation as broken.
And even worse, regular post editor uses Desktop without iframe and mobile view as iframe, which closes all Inspector panels when we switch to iframed view. This is extremely reducing productivity.
Step-by-step reproduction instructions
Screenshots, screen recording, code snippet
No response
Environment info
No response
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Yes