Skip to content
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

enqueue_block_editor_assets doesn't work for scripts in Iframed preview #44945

Closed
wpsoul opened this issue Oct 13, 2022 · 14 comments
Closed

enqueue_block_editor_assets doesn't work for scripts in Iframed preview #44945

wpsoul opened this issue Oct 13, 2022 · 14 comments
Labels
[Package] Block editor /packages/block-editor [Type] Enhancement A suggestion for improvement.

Comments

@wpsoul
Copy link

wpsoul commented Oct 13, 2022

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

  1. Add any script to enqueue_block_editor_assets hook (or any other)
  2. Open Site editor or Mobile preview
  3. Scripts are not loaded inside Iframe

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

@kathrynwp kathrynwp added [Type] Enhancement A suggestion for improvement. [Package] Block editor /packages/block-editor labels Oct 17, 2022
@Mamaduka
Copy link
Member

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 Mamaduka closed this as not planned Won't fix, can't repro, duplicate, stale Oct 18, 2022
@Mamaduka Mamaduka added the [Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed label Oct 18, 2022
@wpsoul
Copy link
Author

wpsoul commented Oct 18, 2022

@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

@Mamaduka
Copy link
Member

Sorry, my mistake, @wpsoul.

@Mamaduka Mamaduka reopened this Oct 20, 2022
@skorasaurus skorasaurus removed the [Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed label Dec 13, 2022
@ellatrix
Copy link
Member

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?

@wpsoul
Copy link
Author

wpsoul commented Dec 21, 2022

@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:

  1. 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

  2. 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

@ellatrix
Copy link
Member

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.

@wpsoul
Copy link
Author

wpsoul commented Dec 22, 2022

@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

@leeshadle
Copy link

leeshadle commented Jan 17, 2023

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?

@wpsoul
Copy link
Author

wpsoul commented Jan 17, 2023

@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.

@lkraav
Copy link

lkraav commented Feb 9, 2023

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.

@ellatrix
Copy link
Member

ellatrix commented Apr 7, 2023

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.

@hasanirogers
Copy link

@ellatrix Any updates on this PR? I'm looking to use Web Components on the Frontend and in the iFrame editor like lkraav.

@sitestudioapp
Copy link

@hasanirogers Same. Stuck looking at a broken UI when in FSE with no way of fixing until scripts can be loaded inside the iframe.

@t-hamano
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Package] Block editor /packages/block-editor [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

10 participants