Warning when enqueuing styles for a plugin in iframed Full Site Editor

[leeshadle]

Description

There is a warning in the iframed Full Site Editor when enqueueing a stylesheet that isn't associated with a block.

I build a lot of plugins that use block filters only to enhance core blocks, which don't require creating custom blocks.

For plugins, the warning suggests using the block API's style or editorStyle:

I'm creating this issue b/c I'm concerned that there may not be a way to properly enqueue stylesheets in the iframed editor without being associated with a block.

Step-by-step reproduction instructions

1. Enqueue stylesheet for a plugin in the Full Site Editor:

function enqueue_editor_styles() {
  // Enqueue editor only styles.
  wp_enqueue_style(
    'my-plugin-block-editor',
    plugin_dir_url( __FILE__ ) . 'build/index.css',
    array(),
    '1.0.0'
  );
}
add_action(  'enqueue_block_editor_assets', 'enqueue_editor_styles'  );

2. Go to Site Editor
3. Open browser console to see warning

WordPress information

• WordPress version: 5.7.2
• Gutenberg version: 10.9.1
• Are all plugins except Gutenberg deactivated? No
• Are you using a default theme (e.g. Twenty Twenty-One)? No

Device information

• Device: Desktop
• Operating system: macOS Catalina
• Browser: Chrome 91.0.4472.114

[ndiego]

I was literally just about to report this, thanks @leeshadle.

We need a safe/official way to enqueue styles that are not necessarily "part" or a block or theme. This use-case will only increase as more and more developers build for the Full Site Editor.

[gziolo]

@ellatrix, is it something on your radar? How does it fit into the roadmap published recently: #33346?

[ellatrix]

Ideally we should be using add_editor_style. It is on the roadmap in terms of making this API more flexible to allow WP dependencies. Would that solve this use case?

[ndiego]

Presumably add_editor_style would work as long as it can be called from a plugin without issue. I have only been using it in my demo block-based themes. Also I would assume with this approach functions like wp_add_inline_style would no longer function for stylesheet added via add_editor_style, right?

[exstheme]

Presumably add_editor_style would work as long as it can be called from a plugin without issue. I have only been using it in my demo block-based themes. Also I would assume with this approach functions like wp_add_inline_style would no longer function for stylesheet added via add_editor_style, right?

@ndiego
It seems that inline styles will not work.
I'm also using inline styles to print my own CSS variables for colors that user can choose in the Customizer, but it is not possible for the iframe editor and it is very bad.

Here is discussion about this issue:

https://make.wordpress.org/core/2021/06/29/blocks-in-an-iframed-template-editor/#comment-41512

[leeshadle]

@ellatrix

Ideally we should be using add_editor_style. It is on the roadmap in terms of making this API more flexible to allow WP dependencies. Would that solve this use case?

@ndiego

Presumably add_editor_style would work as long as it can be called from a plugin without issue. I have only been using it in my demo block-based themes. Also I would assume with this approach functions like wp_add_inline_style would no longer function for stylesheet added via add_editor_style, right?

I tried using add_editor_style to enqueue styles from a plugin - but I haven't been able to get this to work ( perhaps I'm referencing the wrong directory since I'm trying to do this from a plugin? ).

With that being said, using add_editor_style to enqueue styles in a plugin feels a bit hacky to me. Also, if the editor is going to be iframed, do we even need to worry about wrapping editor-styles? Since it's iframed, why couldn't we just enqueue styles/scripts in the iframed editor using something similar to enqueue_block_editor_assets?

@exstheme

It seems that inline styles will not work.
I'm also using inline styles to print my own CSS variables for colors that user can choose in the Customizer, but it is not possible for the iframe editor and it is very bad.

Here is discussion about this issue:

https://make.wordpress.org/core/2021/06/29/blocks-in-an-iframed-template-editor/#comment-41512

This is the case for me as well. I'm also using inline styles to print my own CSS variables and it doesn't work in the iframed editor. I created an issue for this here if you want to follow along:
#33333

[ellatrix]

Also I would assume with this approach functions like wp_add_inline_style would no longer function for stylesheet added via add_editor_style, right?

It would if we add support for passing WP dependency handles in addition to passing a URL.

With that being said, using add_editor_style to enqueue styles in a plugin feels a bit hacky to me.

Why? :)

Also, if the editor is going to be iframed, do we even need to worry about wrapping editor-styles?

You should normally never have to worry about that.

Since it's iframed, why couldn't we just enqueue styles/scripts in the iframed editor using something similar to enqueue_block_editor_assets?

You can, through add_editor_style or block registration. But like I said, we'll need to add support to add_editor_style for adding WP dependency handles just like we do for block registration.

add_editor_style is the official way to add styles to the editor. This was even already the case in the classic editor.

[ndiego]

Thanks for the clarifications @ellatrix. Do you envision enqueue_block_editor_assets just used for scripts and all styles being added via add_editor_style as you indicated?

[leeshadle]

Thank you for talking through all of this @ellatrix!

Again, all of this only becomes an issue when the block editor is iframed. Otherwise, everything works as expected.

With that being said, using add_editor_style to enqueue styles in a plugin feels a bit hacky to me.

Why? :)

Using add_editor_style to enqueue styles in a plugin feels hacky to me b/c:

• based on the documentation it looks like it's meant to be used for a theme's editor styles, not for enqueueing assets for a plugin
• it's looking for styles in a theme's root directory
• in the block editor, it transforms the editor styles by selectively rewriting or adjusting certain CSS selectors - ( what if I don't want styles rewritten or adjusted and just want to enqueue a stylesheet? )
• enqueue_block_editor_assets looks like the official way for plugins to add scripts/styles to the block editor, without those assets being associated with a block
• in the classic editor we could simply enqueue scripts and styles in the editor, without them being transformed or re-written

Further, I've tried using add_editor_style from a plugin and I haven't been able to add styles to the block editor ( am I passing the wrong directory to add_editor_style? ):

function theme_support () {

// trying to enqueue style.css by passing the correct directory to add_editor_style using plugin_dir_url()
add_theme_support( 'editor-styles' );
add_editor_style(  plugin_dir_url( __FILE__ ). 'build/style.css' );

// trying to enqueue style.css by passing correct directory to add_editor_style using plugin_dir_path()
add_theme_support( 'editor-styles' );
add_editor_style( plugin_dir_path( __FILE__ ) . 'build/style.css' );

}
add_action( 'after_setup_theme', 'theme_support' );

Ultimately though, if all block editor instances are going to be iframed, is there any possible way we can continue to use enqueue_block_editor_assets and wp_add_inline_style in the iframed block editor in the same way we have been using them since the launch of Gutenberg ( I'm on my hands and knees begging here )? It feels so much cleaner, easier, open, and gives developers more control over what they're enqueuing than using add_editor_style. I have to imagine there are more people than just those of us on this thread using enqueue_block_editor_assets in a similar way...

[ellatrix]

No, enqueue_block_editor_assets is for scripts and styles for the block editor UI, not the content of the editor. add_editor_style is for content styles. Even before the iframed editor this was the official way to add content styles, and .editor-style-wrapper would automatically be added. It was even used before Gutenberg for content styles in the TinyMCE editor. This is mainly used by themes, but plugins can use it too. All that said, we do realise that add_editor_style has some limitations (no inline styles and dependencies), so we should make the API a bit more flexible. This has been an issue for a long time: you could not add inline styles in the TinyMCE editor, and without the iframe you can add the styles, but you have to add .editor-style-wrapper yourself, which is hacky. In the iframe, we will remove this rewriting because it's no longer needed.

I will make work of fixing add_editor_style to support WP dependency handles, which could probably be shipped in a minor release, and if not, next WP release.

[ndiego]

No, enqueue_block_editor_assets is for scripts and styles for the block editor UI, not the content of the editor.

Ahh that is very helpful info, thanks. I definitely missed that. 95% of my CSS is for the block editor UI and the remaining 5% touches the content of the editor. That must be why I am getting the error that was originally reported by Lee. I will strip that 5% out and try adding it separately with add_editor_style.

[ellatrix]

The error is there because there's a compatibility layer loading the stylesheets in the iframe if it detects "wp-block" or "editor-styles-wrapper" in a selector in the stylesheet. So the styles will load in the iframe, but they're not added as they should be.

I'll add an integration test for add_editor_style to see what changes we need to make.

[leeshadle]

Ahhh interesting... so it sounds like I should have been using add_editor_style instead of enqueue_block_editor_assets for enqueueing content styles...

In the iframe, we will remove this rewriting because it's no longer needed.

If you remove the rewriting in the iframe, would it enqueue the stylesheet, or would it inline the styles as it currently does? I ask b/c I often enqueue styles for scripts that add functionality to editor content - imagine something like adding flickity slider or masonry functionality in the editor where you need to enqueue scripts and styles. It'd be great if those styles can be cached and not inlined.

I will make work of fixing add_editor_style to support WP dependency handles

Does this mean this might look something like, we would use wp_register_style to add the dependency handle and then use add_editor_style to enqueue that dependency?

In the meantime, how would I go about using add_editor_style from a plugin right now? I've read through the documentation and I've tried this multiple ways but I just can't find a way to get it to work:

function theme_support () {

// trying to enqueue style.css by passing the correct directory to add_editor_style using plugin_dir_url()
add_theme_support( 'editor-styles' );
add_editor_style(  plugin_dir_url( __FILE__ ). 'build/style.css' );

// trying to enqueue style.css by passing correct directory to add_editor_style using plugin_dir_path()
add_theme_support( 'editor-styles' );
add_editor_style( plugin_dir_path( __FILE__ ) . 'build/style.css' );

}
add_action( 'after_setup_theme', 'theme_support' );

[ellatrix]

If you remove the rewriting in the iframe, would it enqueue the stylesheet, or would it inline the styles as it currently does? I ask b/c I often enqueue styles for scripts that add functionality to editor content - imagine something like adding flickity slider or masonry functionality in the editor where you need to enqueue scripts and styles. It'd be great if those styles can be cached and not inlined.

Does this mean this might look something like, we would use wp_register_style to add the dependency handle and then use add_editor_style to enqueue that dependency?

That's what I mean, yes. Currently styles are inlined, but it doesn't have to be like that in the future. The styles had to be rewritten because there was no iframe. Ideally the API would look something like:

add_action(
  'init',
  function() {
    wp_register_style( 'my-plugin-style', url, dependencies ); // Don't enqueue, only register.
    wp_add_inline_style( 'my-plugin-style', css );
    add_editor_style( 'my-plugin-style' ); // Loads everything for you in the iframe.
  }
);

This is currently not possible yet. Behind the scenes, add_editor_style adds styles to the settings, so you could extend the settings instead. They are inline for now, but if we allow passing handles it wouldn't be.

add_action(
  'block_editor_settings_all',
  function( $settings ) {
    $settings['styles'][] = array( 'css' => 'p { border: 1px solid red }' );
    return $settings;
  }
);

[leeshadle]

Thank you for taking the time to clarify all of this @ellatrix!

That's what I mean, yes. Currently styles are inlined, but it doesn't have to be like that in the future. The styles had to be rewritten because there was no iframe. Ideally the API would look something like:

add_action(
  'init',
  function() {
    wp_register_style( 'my-plugin-style', url, dependencies ); // Don't enqueue, only register.
    wp_add_inline_style( 'my-plugin-style', css );
    add_editor_style( 'my-plugin-style' ); // Loads everything for you in the iframe.
  }
);

Love this - doing something like this would be great - flexible, clean, easy to migrate to, non-hacky ;)

[ellatrix]

No problem! Thanks for the feedback!

[ellatrix]

May I ask what kind of styles you're looking to registering for blocks that you don't register without being a theme? I'm just curious and want to learn more about use cases.

[bfintal]

May I ask what kind of styles you're looking to registering for blocks that you don't register without being a theme? I'm just curious and want to learn more about use cases.

Hey @ellatrix for my case, my plugin provides new blocks that have their own looks. Then I have a separate css file that's only loaded in the frontend that serve as common styles across all our blocks. Is that what you were asking about?

[ndiego]

I have a plugin called Block Visibility that allows users to conditionaly display blocks on the frontend of their website. When a block is conditional, I am adding a dashed outline around the block and adding some opacity. This greatly helps users know what is conditional in the editor when working with a large page full of blocks. Admittedly the implementation needs some fine tuning and there are a few issues with certain blocks.

I know I am not the only one doing this and I envision other untility plugins adding styles to blocks in the editor. I am guessing Yoast SEO might be doing this with their Readability Analysis, but I am not 100% sure. The Readability Analysis highlights block content in purple, which is obviously not displayed on the frontend.

[exstheme]

@ellatrix
Hello, Ella!

I'm adding inline styles for the editor for my custom colors that user can choose in the Customizer.
This is done with following code in the 'after_theme_setup' hook (I guess that I will use theme.json for this later, but now it is like this:)

// Gutenberg block editor
add_theme_support(
    'editor-color-palette',
    array(
        array(
            'name'  => esc_html__( 'Light', 'exs' ),
            'slug'  => 'light',
            'color' => 'var(--colorLight)',
        ),
        ...
    )
);

Then I'm registering my custom CSS for the dashboard and adding inline styles for it on the 'admin_enqueue_scripts' hook and here is a result:
https://i.imgur.com/XmmiNHy.png

And now I can use these color values for any of the editor elements:
https://i.imgur.com/fHCqw4z.png

I really do not want to promote my theme here but you can check my code in it:
https://wordpress.org/themes/exs/

adding colors in the /inc/setup.php on line 152
printing inline styles in the /inc/static/ on line 245

Thanks for your attention to this really important issue.

[leeshadle]

May I ask what kind of styles you're looking to registering for blocks that you don't register without being a theme? I'm just curious and want to learn more about use cases.

Generally, I try to avoid creating custom blocks and use block filters with core blocks whenever possible. This typically requires enqueuing styles that apply to the editor content.

Some examples of how I've done this:

• I have a plugin that turns the core/image-gallery block into a slider using flickity - so I'll enqueue the scripts for the slider functionality and enqueue styles for the editor content to preview the slider
• I have a plugin that adds an off-canvas menu trigger to a core/button block - so I'll use block filters to add attrs to the core/button block and add an off-canvas menu preview to it's edit function, and then enqueue styles to the editor content to preview the off-canvas menu

[ndiego]

In the meantime, how would I go about using add_editor_style from a plugin right now? I've read through the documentation and I've tried this multiple ways but I just can't find a way to get it to work:

@leeshadle did you ever get this working?

[leeshadle]

@leeshadle

In the meantime, how would I go about using add_editor_style from a plugin right now? I've read through the >documentation and I've tried this multiple ways but I just can't find a way to get it to work:

function theme_support () {

// trying to enqueue style.css by passing the correct directory to add_editor_style using plugin_dir_url()
add_theme_support( 'editor-styles' );
add_editor_style( plugin_dir_url( FILE ). 'build/style.css' );

// trying to enqueue style.css by passing correct directory to add_editor_style using plugin_dir_path()
add_theme_support( 'editor-styles' );
add_editor_style( plugin_dir_path( FILE ) . 'build/style.css' );

}
add_action( 'after_setup_theme', 'theme_support' );

@ellatrix

This is currently not possible yet. Behind the scenes, add_editor_style adds styles to the settings, so you could extend the settings instead. They are inline for now, but if we allow passing handles it wouldn't be.

add_action(
  'block_editor_settings_all',
  function( $settings ) {
    $settings['styles'][] = array( 'css' => 'p { border: 1px solid red }' );
    return $settings;
  }
);

@ndiego no, this isn't currently possible. For now, @ellatrix suggested extending the block editor settings instead. I haven't tried doing this, it doesn't really make sense for my use case as I've got a lot of styles being compiled into a stylesheet...

[ndiego]

Is there any update on this? After upgrading to 11.4, I am now seeing this in the Block Editor as well as the Site Editor.

[richtabor]

I'm running into this as well, within the Site Editor as well as with patterns loaded within the iFramed BlockPreview component (that's how I first noticed it). Seems like a bigger deal for third-party tools that extend core functionality that should be prioritized before 5.9 imo.

[leeshadle]

@richtabor @ndiego @exstheme there is some chatter around this issue:
#32510 (review)

[aristath]

Just a note, these errors are now warnings (see PR in #35914)

[priethor]

Hi there! A PR that provides a solution to avoid these warnings, #37466, is ready for review. We are close to Beta 4, so testing and feedback is more than welcome 🙏

[ndiego]

That's great @priethor, I am happy to test. Are there any recommended testing steps for #37466. It's a bit unclear to me.

[richtabor]

I'm not 100% sure, but I think this is related to the background color styles not being properly reflected TwentyTwentyOne's patterns, as the theme is using enqueue_block_editor_assets() to add CSS variables to the editor.

[t-hamano]

What about a way to tie wp_add_inline_style to the core handle?
Like this:

function add_inline_css() {
  wp_add_inline_style( 'wp-edit-blocks', 'p{background: red;}' );
}
add_action( 'init', 'add_inline_css' );

I have confirmed that the inline CSS is output in the iframe.
We will be able to output customizer values as CSS properties or inject arbitrary CSS from plugins that do not have blocks using this approach.
Is there anything wrong with relying on the core handle in this way?

[markhowellsmead]

Running Core 5.8.3 and plugin 12.4.1, I'm enqueuing block CSS with a theme I'm working on using add_editor_style. This works fine in the post/page editor.

However, this file isn't loaded in the new site editor, meaning that none of the blocks there have any of my own CSS applied. If I enqueue it using wp_enqueue_style, as I have since 2018, then the CSS is applied everywhere, but I get the console warning mentioned above.

What is the correct way to enqueue block CSS from one file in both the post/page and site editors?

[markhowellsmead]

Update: the warning isn't thrown when using the latest 5.9 release candidate.

[htmgarcia]

Update: the warning isn't thrown when using the latest 5.9 release candidate.

@markhowellsmead notice the same here, however wp_enqueue_style didn't worked for the iframe, so added add_editor_style to fix it.

[richtabor]

@markhowellsmead notice the same here, however wp_enqueue_style didn't worked for the iframe, so added add_editor_style to fix it. No?

You were able to add styles from the plugin with add_editor_style()?

[htmgarcia]

@richtabor we use add_editor_style() with success through our PublishPress Blocks plugin.

[markhowellsmead]

@richtabor I've attempted to enqueue a stylesheet from the theme I'm building. It doesn't work when using add_editor_style on the after_setup_theme hook. It does work with wp_enqueue_style on the admin_enqueue_scripts hook. Until 5.9, this threw a warning, but the warning is no longer visible.

[markhowellsmead]

Addendum: add_editor_style doesn't work on the admin_init hook either. I've taken the use of the after_setup_theme hook from the Automattic FSE themes.

[leeshadle]

@richtabor @markhowellsmead it looks like I'm able to enqueue styles in the iframed site editor ( without a warning ) via a plugin using enqueue_block_editor_assets. However, I am not able to enqueue scripts inside the iframed site editor using the enqueue_block_editor_assets hook.

[maffi-git]

I'm also having trouble to dynamically inject my color-variables to the iframes. enqueue_block_assets just doesn't do the trick. Is there any way to append/inject my styles to any of the other styles loaded inside the iframe? I can manage to load a css-file, but no inline-styles.

I'm also seeing an empty <style>-tag after the last link-resource.

[markhowellsmead]

I have the same issue as @maffi-git across all my sites.

[ellatrix]

Is this issue still relevant after the 6.3 release. See https://make.wordpress.org/core/2023/07/18/miscellaneous-editor-changes-in-wordpress-6-3/#post-editor-iframed for more information about handling styles in the iframe.

[t-hamano]

I believe this problem was solved in WordPress 6.3. For example, if some plugin wanted to apply a style to the editor content, including iframe editor instances, it could be accomplished with code like this:

function my_stylesheet() {
	if ( is_admin() ) {
		wp_enqueue_style( 'my-style', plugins_url( 'my-style.css', __FILE__ ) );
		wp_add_inline_style( 'my-style', '.editor-styles-wrapper p { color: red;}' );
	}
}
add_action( 'enqueue_block_assets', 'my_stylesheet' );

[jordesign]

@t-hamano My understanding is also that this is resolved with WP6.3 and that approach. Accordingly I'll close this issue.