"editor.css" not included when Gutenberg (block) editor is in the new iframe mode

[mjsarfatti]

Version

10.8.2

What did you expect to happen?

The new Gutenberg (block) editor is now inside an iframe. For this reason enqueueing editor assets using the enqueue_block_editor_assets hook no longer works reliably, and we are recommended to use enqueue_block_assets instead (see: https://github.com/WordPress/gutenberg/blob/trunk/docs/how-to-guides/enqueueing-assets-in-the-editor.md#editor-content-scripts-and-styles).

I expect styles in editor.css to be applied when the editor appears inside an iframe and I use the enqueue_block_assets hook.

What actually happens?

Styles in editor.css are not applied in the following two cases:

1. When using the enqueue_block_editor_assets hook if the editor appears inside an iframe, or
2. When using the enqueue_block_assets hook both when the editor appears inside an iframe and when it appears in page (legacy).

Steps to reproduce

1. Do a fresh install of Bedrock+Acorn+Sage and activate the Sage theme
2. Edit the file web/app/themes/sage-theme/app/setup.php like so:

- add_action('enqueue_block_editor_assets', function () {
+ add_action('enqueue_block_assets', function () { 

3. Add some CSS to editor.css, for example:

.wp-block {
  background: pink;
}

4. Go to edit a page, and see that the background is not applied

System info

No response

Log output

No response

Please confirm this isn't a support request.

Yes

[retlehs]

Both editor CSS and JS are working as expected for me with enqueue_block_editor_assets and enqueue_block_assets

When using the current hook (enqueue_block_editor_assets) there is this warning:

editor/0-css was added to the iframe incorrectly. Please use block.json or enqueue_block_assets to add styles to the iframe.

I'll get a PR up with that change

[AxelDeneu]

Any news on this?

On my side, enqueue_block_editor_assets works only when not previewing in responsive mode (with iframe).
As soon as an iframe is generated, the style doesn't apply.

Changing enqueue_block_editor_assets by enqueue_block_assets doesn't solve the issue as it removes every editor style.

Adding both enqueue_block_editor_assets and enqueue_block_assets with the same bundle('editor')->enqueue(); doesn't solve this issue neither.

May this be an issue regarding the css encapsulation in the editor.js file?

When loading a preview, which triggers an iframe loading, I have the following error :

I hope those informations helps.

[joshuafredrickson]

This one's a bit tricky because as far as I can tell (and please let me know where I'm off-base), there's not a way to determine via PHP whether the editor will be iframed or not. Here's how it's determined in js. Basically, every registered block must be API version 3 in order for the iframe to kick in.

On top of that, there are several plugins that by default don't utilize v3. Meaning, as soon as one is installed/activated, your editor will no longer be iframed. For example, ACF defaults to v2*, Gravity Forms to v1**. Meaning that how editor styles are actually enqueued changes based on the active plugins at any given time.

If your editor isn't iframed, you can determine which blocks are the culprit by running this in the console:

wp.blocks.getBlockTypes().filter(b => b.apiVersion !== 3)

It looks like @retlehs is correct here in that having both enqueue_block_editor_assets and enqueue_block_assets in the theme works with both iframed/non-iframed editors. When using both, the editor/0-css was added to the iframe incorrectly warning disappears.

add_action('enqueue_block_editor_assets', function (): void {
    if (is_admin()) {
        bundle('editor')->enqueue();
    }
}, 100);

add_action('enqueue_block_assets', function () {
    bundle('editor')->enqueue();
}, 100);

Note is_admin in the first action. Without this, editor/0-css gets enqueued on the frontend as well.

That's all just for editor-specific styles. If you also want to load your frontend styles into the editor, then you should include it using editor-styles theme support.

add_theme_support('editor-styles');
add_editor_style(asset('app.css')->relativePath(get_theme_file_path()));

Are there any enqueues I'm missing? 😅

With regards to @AxelDeneu's console error, I'm seeing that as well when running yarn dev with the editor iframed. The message disappears after building.

954cb990-9e56-4e3f-93a5-ffcab5526e46:116 Uncaught TypeError: Cannot read properties of null (reading 'createInfoNotice')
    at handler (editor.js:35:86)
    at Module.load (editor.js:42:20)
    at Module.register (filters.js:9:99)
    at eval (editor.js:14:59)
    at ./scripts/editor.js (editor.js:748:1)
    at options.factory (954cb990-9e56-4e3f-93a5-ffcab5526e46:701:31)
    at __webpack_require__ (954cb990-9e56-4e3f-93a5-ffcab5526e46:113:33)
    at __webpack_exec__ (editor.js:754:48)
    at editor.js:755:139
    at webpackJsonpCallback (954cb990-9e56-4e3f-93a5-ffcab5526e46:1380:39)

---

* Bonus: If you want to force ACF to use API version 3 (which also disables "Preview" mode for blocks entirely):

add_filter('acf/register_block_type_args', function (array $block): array {
    $block['acf_block_version'] = 3;
    $block['api_version'] = 3;
    return $block;
});

Works great in conjunction with acf-composer.

---

** Bonus Bonus: If you want to force GF to use API version 3 (which completely breaks the block during dev but seems to work properly after build):

/**
 * @see {@link https://developer.wordpress.org/block-editor/reference-guides/filters/block-filters/#blocks-registerblocktype}
 */
export const hook = 'blocks.registerBlockType';

/**
 * Filter handle
 */
export const name = 'sage/gravityforms/form';

/**
 * Filter callback
 *
 * @param {object} settings
 * @param {string} name
 * @returns modified settings
 */
export function callback(settings, name) {
  if (name !== 'gravityforms/form') return settings;

  return {
    ...settings,
    apiVersion: 3,
  };
}

[AxelDeneu]

Thanks a lot @joshuafredrickson for this comment as it removes a lot of fog about what's not going as it should in my code.

That's a really big shame on me. As you mentioned, the code solution provided by @retlehs indeed works.
The error was totally on my side, as not any editor.css file where loaded on the editor because there wasn't any previously generated.

For anyone wondering why, yarn dev encapsulate every css inside the runtime, so, not any .css file are loaded in the editor iframe.
The workaround is to run yarn build to get the result as expected. With this command, a css file is generated for every entry in the bud.config.js file. And then, the given file is loaded in every editor (editor preview + iframe preview).