Editor styles not loading in WP6.3 with bud dev

sage
,
1

When I run yarn build --clean editor styles work fine. Minimal test case of bumping up the h1 and using Helvetica / font-sans:

image

But when running bud dev it doesn’t work at all - Times font and default WordPress sizes:

image

I know since WordPress 6.3 there is now different markup in the editor, using an iframe… wondered if it was related, but I guess not since it does work fine when I run an actual build.

Stumped by this one. Any help gratefully received.

"devDependencies": {
    "@roots/bud": "6.15.0",
    "@roots/bud-tailwindcss": "6.15.0",
    "@roots/sage": "6.15.0"
  },

WordPress 6.3. Installed clean yesterday using composer create-project roots/bedrock and composer create-project roots/sage

2

Do you mean the frontend styles that should be used by the editor?

This example may be helpful:

3

Hi @strarsis - thanks…

I don’t want to load my frontend styles, just the content of editor.css - but none of those styles are taking effect when running bud dev, only when I run a build with yarn build --clean

I can also tell you that loading the full frontend styles by this method doesn’t work for me either when running bud dev - I just tried it. Same thing - no styles are loading in the new iframe editor canvas of WordPress 6.3

5

Thanks @AlexHay but that’s not correct. It has always worked in the past.

Some elements do style as expected when I make changes, but it appears that WordPress 6.3, in introducing an iframe for the “editor canvas” breaks the behaviour.

Example - I have got some container styles.

image
image2116×800 151 KB

When I change this - changing background colour and padding (just for a quick dirty demo), the editor screen does update in real time when running yarn dev and viewing on localhost:3000

image
image1886×716 123 KB

But no fonts are loading - if I apply font-sans it should make the text a sans font across the editor but that is not firing at all.

7

It seems in WP 6.3 the enqueue_block_editor_assets hook no longer works when the editor is loaded in an iframe. which sounds quite likely to happen on a fresh install:

The post editor will be iframed if all registered blocks have a Block API version 3 or higher and the editor has no classic meta boxes below the blocks.

See:

You could try using the enqueue_block_assets hook combined with the is_admin() function instead to load editor only assets (or add_editor_style() for CSS only) eg:

add_action('enqueue_block_assets', function () {
    if(is_admin()) {
        bundle('editor')->enqueue();
    }
}, 100);
2 Likes
8

Thanks @devben - your suggestion doesn’r work unfortunately, although I can see you have followed the steps provided by WordPress:

It’s also worth noting that enqueue_block_editor_assets should not be used to add stylesheets for editor content. Please use enqueue_block_assets instead. If you don’t want styles to load on the front-end, you can use an is_admin() condition.

They also say this:

To make adoption easier, all assets (styles and scripts) added through the enqueue_block_assets PHP action will now also be enqueued for the iframe.

But this just doesn’t seem to be the case. These styles just stubbornly refuse to load in the iframe.

Anyway - thanks - it’s a step in the right direction to figuring this out.

9

@raffjones in your Tailwind CSS example I think .edit-post-visual-editor is now a parent of the iframe in which the CSS file is being loaded, and therefore out of scope. Try replacing .edit-post-visual-editor with .editor-styles-wrapper in your CSS file eg:

.editor-styles-wrapper {
    @apply bg-black;
}

This changed the editor background colour to black for me when using the enqueue_block_assets hook with is_admin() but it doesn’t work with bud dev for me either, just bud build.

1 Like
10

thanks @devben - but again no success.

I have found no problem getting container styles to load, but anything inside the iframe is just not working.

I tried a really specific selector:

.editor-styles-wrapper .edit-post-visual-editor__post-title-wrapper h1 {
  @apply font-sans text-4xl font-bold;
}

but it did not work. Still Times text, default sizes.

11

That’s strange, I just tested with your sample css and it changed the title font on a fresh install with sage 10 loading the editor stylesheet like this in setup.php:

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

Here’s my editor.css file :

@tailwind base;
@tailwind components;
@tailwind utilities;

.editor-styles-wrapper .edit-post-visual-editor__post-title-wrapper h1 {
    @apply font-sans text-4xl font-bold text-red-500;
}

And then running bud build.

In my case I did need to use the @tailwind import format to get the css file to build rather than @import

1 Like
12

@devben I can confirm your example works perfectly… but I have not had a problem getting it to work with bud build - the problem is that it just won’t work on bud dev - that was my original issue which remains unsolved.

If you run bud dev and look at the backend via localhost:3000 you will find it just resets completely to the default. Some changes will be picked up - as long as the styles apply to the elements outside the iframe - but anything inside the iframe is ignored.

I have no idea why. But sure the advantage of having a hot reloading theme is that the backend can reflect front-end theme changes?

I’m lost as to why it just won’t work in dev mode.

1 Like
13

I think bud’s hot reloading’s not working when the post editors loaded it an iframe in WP 6.3. The roots theme / bud will probably get updated to handle that in the future. In the meantime if hot reloadings important I think you can get it to stop using an iframe for the content editor by registering a custom block using apiVersion 2 or activating any plugin that registers custom meta fields on the editor page (like Yoast SEO). Either of those should switch it back to use the non-iframed editor (might need to go back to loading your editor stylesheet with the enqueue_block_editor_assets hook again in that scenario)

2 Likes
15

@devben Thanks. I think I will use this as a workaround. I wasn’t able to work out why older sites which I upgraded to 6.3 were still working fine with dev mode… but it’s because they had blocks registered with api v2. I also noticed those sites didn’t have an iframe in the editor at all - now I know why. Thanks for your help on this.

2 Likes
16

Hi guys - are there any updates on if / when Sage / Bud will support hot reloading of styles in the iframed editor?

I’m still using the workaround of using an API v2 block but would like to avoid having to use this hack.

17

Not sure if this will help but I had forgotten to set my public path in bud.config.js

// bud.config.js

// app.setPublicPath('/app/themes/sage/public/'); // boilerplate path
  app.setPublicPath('/app/themes/mycooltheme/public/'); // updated for my theme

No other config was necessary, including enqueue_block_assets

Sincerely hope it helps,
Jess

18

Thanks but that’s not the issue here. My public path was / is set correctly :slight_smile:

19

Hi @raffjones,

It sounds like you have add_editor_style() set up correctly, as the prod build works.

WordPress is now processing and inlining <style> tags in the iframe body itself. This process relies on a CSS file being on disk. Bud / Webpack will not emit assets to disk in dev mode, and instead produces JS chunks which allow for hot module reloading. This is where the issue you’re experiencing stems from.

There are a couple of solutions:

  • Use a Webpack plugin like mini-css-extract-plugin to emit CSS assets in dev
  • Use a more specific approach to target styles and emit CSS assets. I wrote a Bud extension a while ago which attempts to handle this - bud-wp-editor-query

Either way, to my knowledge, there is no way to enable HMR inside the FSE editor iframe. The design approach taken by WordPress to inline the styles prohibits this.

2 Likes
20

Hi @talss89 - thanks for the thorough explanation. Now I understand what’s actually happening here. I’ll have a look at the plugin & extension.

21

Hi! I’m having the same issue, with styles not showing in the editor after running yarn dev. I was wondering if you had any success with the plugin or extension? I’m hoping to avoid the block hack as well.

1 Like
22

I noticed that when using Design → Site editor style isolation is achieved purely by using an iframe, while on post/page editor the styles are still isolated by post-processing the CSS. Well, that is what I think I noticed in current WordPress core version.

So when you edit the site (and posts/pages) using Design → Site editor, does the hot reloading maybe work then somehow?