Blocks: `enqueue_block_editor_assets` not working with the editor's iframe
straightvisions-matthias-bathke opened this issue Β· 9 comments
Description
Actual Status
Site Editor is loading it's own iframe without loading the CSS registered via enqueue_block_editor_assets.
Target Status
enqueue_block_editor_assets should work for site editor iframe, too.
Explanation
While function add_editor_styles seems to be optimized for loading static styles from theme, it's still required for plugins to load (dynamic generated) styles via enqueue_block_editor_assets. Additionally, it won't work for styles loaded from a htaccess-protected website and absolute paths are not supported yet.
Plugins without serving a block are not able to serve styles with "editor_style"-Attribute of "register_block_type"-function.
It would be great to either support absolute paths in add_editor_styles or add support for enqueue_block_editor_assets in site editor.
Step-by-step reproduction instructions
- Register CSS via enqueue_block_editor_assets
- Open Page Edit Screen and check if CSS is loaded, if so then:
- Open Site Editor Edit Screen and check if CSS is loaded in template iframe
- In my tests, CSS is loaded in editor wrapper, but not in iframe of the loaded template (e.g. header), so styles won't be active there
Screenshots, screen recording, code snippet
related: https://wordpress.org/support/topic/adding-styles-from-plugins-to-the-editor/
Environment info
WordPress v6.0.0
Gutenberg v13.4.0
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
i just spent an hour trying to figure out why the block css wasn't loading in the site editor.
Strangely, one of the blocks is loading the stylesheet inside the body tag of the iframe. I have no idea why this block loads the css in the iframe yet the others do not as they are all registered in the same way with the enqueue_block_editor_assets
hook.
For now, this is how I'm doing it until this bug is fixed:
function register_block_assets () {
// wp_register_style ...
}
function register_block_assets_in_site_editor () {
global $pagenow;
if ('site-editor.php' === $pagenow) {
register_block_assets();
}
}
add_action('init', 'register_block_assets_in_site_editor');
add_action('enqueue_block_editor_assets', 'register_block_assets');
See also: #34763 (comment)
Looks like the CSS needs to contain .wp-block
inside the file in order for it to be enqueued inside the iframe.
See: #40603 (comment)
I'm seeing the same issue. From what I understand, enqueue_block_editor_assets is for enqueuing UI styles for the editor's interface, not for content. With that being said, how do we include CSS that isn't tied to a block or that is being globally applied to blocks? What if there is no way to include a .wp-block selector inside the CSS file?
Looks like the CSS needs to contain
.wp-block
inside the file in order for it to be enqueued inside the iframe.See: #40603 (comment)
For example, I'm loading CSS for GDPR Compliant Google Fonts in the block editor but I have no way of adding a .wp-block selector to the style sheet.
@leeshadle did you find out anything on this issue. I'm running into the same thing with google fonts myself.
@mark-c-woodard Unfortunately I have not. Please if you find a way I'd love to know. I've been trying to prevent this issue from arising for 1.5 years with no luck:
Warning when enqueueing styles for a plugin in iframed Full Site Editor
The same issue applies for scripts as well...
Now that the iframed editor is being rolled out for the post editor screen, this might become a general issue with plugins and the block editor (a similar issue caused by the iframe #47983). I updated the title of this issue to reflect that.
@fabiankaegy proposes in #48382 a new utility function that could help with enqueuing scripts for blocks. Itβs probably the best way to resolve the issue discussed here as it would make it possible to explicitly expose such scripts to the iframe when we know they are needed by blocks.
Is there any news on this at all? We need to consider both core & custom blocks as well as third party blocks such as ACF blocks etc. which people use.
Not being able to load relevant JS in the site editor using the current enqueue_block_editor_assets hook is confusing and frustrating when blocks just don't work properly in the site editor.
I would be very keen to see some kind of fix for this.
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.