editor-style.css not working anymore + revert property overriding block styles

[pablo-miralles]

Description

I've updated to 5.9 in a WordPress theme that editor and content where 1:1 thanks to the editor-styles.

Now, I have the following issues:

1. editor-styles support not working anymore

I had this added to the theme: add_theme_support('editor-styles'); and editor-style.css was used automatically to add styles to the editor. Now it doesn't work (the file is not enqueued). I've tried doing this:

add_theme_support('editor-styles');
add_editor_style( 'editor-style.css' );

but it didn't worked.

2. The revert issue Maybe is related to the first one, but I've notice that now the gutenberg editor has reverts in a lot of properties. This makes blocks look terrible, because font-sizes are reverted, font-families too (to a "sans-serif"), font-weights... etc. Making the editor looks awful. Some example of this code could be:

html :where(.editor-styles-wrapper) h1,
html :where(.editor-styles-wrapper) h2,
html :where(.editor-styles-wrapper) h3,
html :where(.editor-styles-wrapper) h4,
html :where(.editor-styles-wrapper) h5,
html :where(.editor-styles-wrapper) h6,
html :where(.editor-styles-wrapper) select {
    font-size: revert;
    margin: revert;
    color: revert;
    line-height: revert;
    font-weight: revert
}

Could you tell me if this is fixeable by the user (developer) or it has to be fixed in an update?

Thank you!

Step-by-step reproduction instructions

1. Create a WP theme (child or parent) to add the functions mentioned below (in environment info)
2. Create the css/js files mentioned above (in environment info).
3. Add theme support for editor-styles
4. Try if it has been called using the element inspector of your favourite browser
5. To see the revert values, just inspect any heading (h2, h3...) in the content of the editor

Screenshots, screen recording, code snippet

Environment info

• WordPress 5.9. I'm using that version of Gutenberg.
• Theme used: Custom theme with no more than this 2 functions:

function mwm_style_wp_admin() {
    wp_enqueue_style('blocks', get_template_directory_uri().'/blocks.css', array(), '1.0.0');
}
add_action( 'enqueue_block_editor_assets', 'mwm_style_wp_admin' );

function mwm_scripts_wp_admin() {

    wp_register_script( 'mowomo_scripts', get_template_directory_uri() . "/blocks.js", array(), "1.0.0", true );
    wp_enqueue_script( 'mowomo_scripts' );

}

add_action('admin_enqueue_scripts', 'mwm_scripts_wp_admin');

and of course the editor-styles theme support

• Browsers: All (Chrome, Firefox, Safari...)
• Devices: Desktop with windows 10, macbook air M1 13' with OS Monterey

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

[Jugibur]

This is the same with my installation (regular theme) after updating to 5.9 - even if I add a theme.json for testing. Gutenberg-Plugin installed and de-installed for testing. All other plugins are deactivated.

I added the editor styles with:

add_action( 'after_setup_theme', function() {
    $version = 3;
    add_theme_support( 'editor-styles' );
    add_editor_style( get_asset_fileuri('styles/wp-admin/admin-editor.css?v=' . $version) );
});

The the tab network resources shows that no stylesheets are loaded in the admin area except my admin.css for the UI - but not the editor-styles.css.

[tedw]

@pablo-miralles I’ve used this code in the past to remove just the reset styles. Hope it helps!

admin.php

/**
 * Custom block editor script
 * https://developer.wordpress.org/block-editor/tutorials/javascript/extending-the-block-editor/
 * https://soderlind.no/hide-block-styles-in-gutenberg/
 */
add_action('enqueue_block_editor_assets', function () {
    wp_enqueue_script('gutenberg.js', asset_path('scripts/gutenberg.js'), ['wp-blocks'], null, true);
});

gutenberg.js

// Remove WP reset styles from the dynamically-generated admin stylesheet, load-styles.php (WP 5.8)
//
// Note: The href contains all of the individual partials that are concatenated into a single CSS file.
//       All we have to do is remove “wp-reset-editor-styles” from the href. However, updating the
//       href will cause a long FOUC, so we’re adding a new stylesheet and then disabling
//       the original once the new one has loaded.
//
// Note: We can ignore <link> tags with IDs since this one doesn’t have one.
let linkTags = document.querySelectorAll('link[rel="stylesheet"]:not([id])');
// There should only be one matching link tag but we’re using forEach() just to be safe.
linkTags.forEach((tag) => {
  let href = tag.getAttribute('href');
  if (href.indexOf('load-styles.php') > -1) {
    // Create new stylesheet without the “wp-reset-editor-styles” styles
    // You can preview those styles using this URL
    // /wp-admin/load-styles.php?c=1&dir=ltr&load%5Bchunk_1%5D=wp-reset-editor-styles&ver=5.9.1
    let link = document.createElement('link');
    link.media = 'all';
    link.rel = 'stylesheet';
    link.type = 'text/css';
    link.href = href.replace('wp-reset-editor-styles,', '');
    // Disable the original stylesheet on load
    link.onload = function() {
      tag.disabled = true;
    };
    // NOTE: We’re adding this stylehseet right after the original link
    //       tag to avoid specificity issues.
    tag.after(link);
  }
});

FWIW I haven’t had any issues so far with the new reset styles in 5.9 thanks to the lower specificity of :where() (this is a great post about it for anyone who stumbles on this issue in the future https://www.matuzo.at/blog/2022/heres-what-i-didnt-know-about-where/) but obviously this will vary for everyone depending on how the theme styles are written.

[strarsis]

@Jugibur: The styles added by add_editor_style should be actually front-end styles. Gutenberg will postprocess those styles, wrapping the selectors into .editor-styles-wrapper selector to isolate the styles from the rest of the editor page UI. The styles to be added by add_editor_style are postprocessed by JavaScript in the browser that runs the Gutenberg editor - but the styles are not fetched by the browser, instead the styles are fetched on the server-side (loopback HTTP request) and then injected as a string that is used by Gutenberg in the browser.

1. (server-side PHP) add_editor_style
2. (server-side PHP) Server-side HTTP fetch (loopback) of that file. Fetched CSS of the file injected as JavaScript variable.
3. (browser-side JS) Postprocessing of the CSS in browser and adding the processed styles inline.

Are you using Docker containers or some other networked setup between a HTTP server (e.g. httpd/nginx) and PHP (php-fpm)? Loopback requests (HTTP requests by WordPress to itself) must work in order for add_editor_styles to successfully add frontend style files.

[muzKore]

I discover this issue recently when the CSS classes mentioned above are actually removing the colour of the block text and the heading. When you add a paragraph, you have to go and set the colour for that paragraph individually. Crazy.

[itsamoreh]

Are you using Docker containers or some other networked setup between a HTTP server (e.g. httpd/nginx) and PHP (php-fpm)?

Thanks for this comment @strarsis. I was having the same problem with editor styles not loading when using wp-env for local development.

I found a solution over here - https://github.com/WordPress/gutenberg/issues/20569#issuecomment-1224280280

I was enqueuing editor styles like this:

add_editor_style( get_template_directory_uri() . '/style.css' );

To fix this in my wp-env setup I removed get_template_directory_uri():

add_editor_style( '/style.css' );

[strarsis]

@itsamoreh: Please ensure that this style of path does not break the post-processing by Gutenberg of the editor styles, which should rewrite stylesheet-relative URLs to absolute ones (as there is no stylesheet for a base-URL anymore, the post-processed styles are added as inline styles by the Gutenberg editor). See this issue: https://core.trac.wordpress.org/ticket/55728#ticket