enqueue_block_editor_assets support in 6.3RC

[vyskoczilova]

Description

Hi, I just tested 6.3RC2, and I am scared about all my client’s sites that use Gutenberg. enqueue_block_editor_assets hook is fired. However, the style is not loaded inside the iframe as it supposes to be. This hook is super essential – most of the time other CSS (and WP itself) CSS mess it up, or you need to add just a little bit more to be able to style UX etc. (for example different REM size or what so ever, so you can’t reuse blocks/styles CSS 1:1).

Don’t release it as it is right now; this is not an unbreakable change. I’ve seen already some ways to go through the issue – for example including a block with apiVersion 2 etc.

Best regards,
Karolina

P.S. Reposted from: https://wordpress.org/support/topic/enqueue_block_editor_assets/

Step-by-step reproduction instructions

Create a simple plugin that adds CSS into the Gutenberg editor
Compare WP 6.2 and 6.3 outputs

Screenshots, screen recording, code snippet

Example working inside 6.2 but not on 6.3 (written as a two file plugin), file editor-assets-test.php

add_action('enqueue_block_editor_assets', function () {
    wp_enqueue_style('editor-assets-test', plugins_url('style.css', __FILE__));
}, 999);

Content of style.css file:

h1, h2, h3, h4 {
    color: red !important;
}

Environment info

• WP 6.3RC
• nothing else

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

[wpsoul]

I had the same issue. I was forced to move all style files in block meta, because all other hooks don't work, even suggested enqueue_block_assets

[ndiego]

Hi @vyskoczilova, thanks for reporting this. The situation with enqueue_block_editor_assets has been the same, I believe, since before 6.0. It just wasn't apparent if you were not using Gutenberg or testing your custom styles in the Site Editor.

The move to iframing the Post Editor in 6.3 does exacerbate the situation, but there is a workaround if you want to continue using enqueue_block_editor_assets. The key is you need to include wp-block somewhere in the stylesheet for it to get included. So if you update the styles to the following, it should work. Not ideal of course...

.wp-block {};

h1, h2, h3, h4 {
    color: red !important;
}

You can also use the new enqueue_block_assets option, which is likely the more appropriate method. But note that you will need to prefix your styles with .editor-styles-wrapper to make sure they are properly applied. The styles would then look like this.

.editor-styles-wrapper h1, 
.editor-styles-wrapper h2, 
.editor-styles-wrapper h3, 
.editor-styles-wrapper h4 {
    color: red !important;
}

Let me know if you run into any issues with either of these approaches. Thanks!

[ndiego]

@ellatrix @oandregal would either of you be able to provide a more detailed synopsis on the appropriate hook to use here?

[oandregal]

That's correct, Diego, though the only nuance is that the enqueue_block_assets approach doesn't need the style wrapper. Let me unwrap what I saw.

I've tried the test case and this is how it looks like:

6.2	6.3

This is what happens: when the post editor is iframed, stylesheets loaded via enqueue_block_editor_assets that don't contain the .editor-styles-wrapper or .wp-block* classes are not enqueued, while before they did. This is expected. When you write styles not bound by .editor-styles-wrapper or .wp-block* they leak everywhere (editor affordances such as sidebar, etc.) and that's a bug we want to fix.

This is how styles and hooks should be used (edited to include Ella's comment):

1. enqueue_block_assets: use to enqueue styles that target the content and should be present both in the editor and the front-end. No matter the style rules of the stylesheet (no need for .editor-styles-wrapper, etc.).
2. enqueue_block_assets: this could be used to enqueue styles ONLY to the editor. It can be done by using is_admin().
3. enqueue_block_editor_assets: use to enqueue styles that target the editor affordances (sidebar, components, etc.).
4. enqueue_block_editor_assets: you can use this hook to enqueue styles that target ONLY the content in the editor, but not the front-end. In that case, all the style rules in the stylesheet should contain .editor-styles-wrapper or .wp-block*, otherwise, the styles will leak to other areas. This is a mechanism introduced for back-compatibility.

The way forward would be to make sure CSS doesn't leak to the editor affordances by using 1, 2, or 4.

[ellatrix]

Previous comments are correct, the enqueue_block_editor_assets has never fired for iframed post content. The alternatives above are good. You should use enqueue_block_assets if possible, and if you don't want to render styles on the front-end, use is_admin().

[oandregal]

ah, forgot about the is_admin() trick: added it to my comment above for completeness.

[ndiego]

@oandregal @ellatrix thank you both for this context 🙏 I am going to work on a guide for the Block Editor Handbook next week.

[vyskoczilova]

Thanks everybody for stepping in and helping me out! And it has also been helpful for somebody else in quite a short time.

@ndiego - the code I provided was working in 6.2 since there was no iframed editor for Gutenberg editor in pages etc., so it's a misunderstanding, but I saw it in many places - the last in the Fränk Klein newsletter I received got a couple of days ago... P.S. If you ping me, when the handbook is done, I'll could give it a read

Anyways, I've tested it and can confirm that:

• enqueue_block_editor_assets action and prefixing every selector by .editor-styles-wrapper works as expected. (and somehow, it looks like when I add .wp-block {}` once into CSS, it gets registered and loaded even when I remove it; however, I need to figure out how long.
• mentioned wp_enqueue_block_assets action doesn't seem to be fired or exist
• instead, the enqueue_block_assets action (both with and without .edtior-styles-wrapper class prepended, the result is different on the frontend, of course), using is_admin() inside the hook, so this will be my preferred action

Thanks a lot! ❤️

---

Just the updated code for reference, if it helps somebody else - loading styles only in the admin inside the editor (styles.css as usual):

add_action('enqueue_block_assets,' function () {
 if (is_admin()) {
    wp_enqueue_style('editor-assets-test', plugins_url('style.css', __FILE__));
 }
}, 999);

[ndiego]

If you ping me, when the handbook is done, I'll could give it a read

Will do!

[oandregal]

@vyskoczilova the names for the hooks were wrong, sorry. Updated my comment to remove the wp_ prefix.

[wpsoul]

@oandregal Wordpress changes how hooks are working almost every major update. I use next hack

1. I register in init hook my style file via wp_register_style
2. I use block.json of one of registered block and add style handle in editorStyle

Benefits.

1. It's working everywhere: in FSE, in mobile preview, without iframe in editor.
2. It's working for panels in Inspector and for toolbars in content area
3. You don't need to use "editor-styles-wrapper"

Currently, this solution is working for me, I hope will work in future

[ellatrix]

I added some extra info to the iframe dev note: https://make.wordpress.org/core/2023/07/18/miscellaneous-editor-changes-in-wordpress-6-3/#post-editor-iframed

[wpsoul]

@ellatrix Is any way to load scripts ONLY in iframe. Looks like enqueue_block_assets duplicates everything twice and this creates problems if I use it for scripts

[vyskoczilova]

@wpsoul my code doesn't work for you? #53236 (comment)

[wpsoul]

@vyskoczilova Your code is correct and it's working but it's not solving my question. It loads everything twice, but I need to load script ONLY in iframe or ONLY outside iframe. It's related to problem which is described in

#53590

[vyskoczilova]

@wpsoul I see, got it now. Hope there will be a fix.

[ellatrix]

Since the original question has a solution, let's close this issue. Let's discuss the loading twice issues further in #53590.

[nazmulhq]

I had the same issue with loading styles for editor using 'enqueue_block_editor_assets'. Using .wp-block {}` once into CSS helped me to make it work. @vyskoczilova thank you, it worked for me.