Block Editor: Add filter to enable custom classes in "editor-styles-wrapper"

[CreativeDive]

Why should it be possible to add custom classes to the block editor "editor-styles-wrapper" container?

For themes the add_filter( 'body_class', 'my_body_classes' ); is extremely useful to style templates in certain cases, such as:

if ( ! function_exists( 'my_body_classes' ) ) :
	function my_body_classes( $classes ) {

		if( is_boxed_layout() ) { 
			$classes[] = 'boxed-layout';
                 }

		return $classes;
	}
endif;

add_filter( 'body_class', 'my_body_classes' );

So we can set certain styles, such as:

body.boxed-layout {
    background: #fafafa;
}

If we using add_editor_style(), currently this has no effect on the block editor, because the specific body classes are not a part of the "editor-styles-wrapper" container.

.editor-styles-wrapper.boxed-layout {
    background: #fafafa;
}

How we can handle this? A new filter for theme developers would be great, such as:

if ( ! function_exists( 'my_editor_classes' ) ) :
	function my_editor_classes( $classes ) {

		if( is_boxed_layout() ) { 
			$classes[] = 'boxed-layout';
                 }

		return $classes;
	}
endif;

add_filter( 'block_editor_body_class', 'my_editor_classes' );

Or is there an other way?

[strarsis]

This would be nice - and it would require JavaScript to change the body class interactively.
But one still may want to have extra elements.

@CreativeDive:
There is a solution I am also currently using on sites that need page template specific (block) styling:
https://discourse.roots.io/t/gutenberg-body-class-elements-by-template/15310/1
The tutorial should be nearly identical to themes that aren't based on roots.io Sage starter theme.
The code allows to sync the body class with the page template selection in Gutenberg editor page.
It also allows to dynamically add extra elements, e.g. <img for complex/optimized backgrounds,
as it would be possible in page templates on frontend.

[strarsis]

@CreativeDive: There is also https://github.com/generoi/wp-gutenberg-templates, which can be helpful.

[ndiego]

This issue has surfaced countless times over the years, and I hear this request a lot from theme developers, especially those transitioning from classic to hybrid themes. While there is currently no solution, I believe the comment here hints at a possible solution.

[MadtownLems]

We have run into LOTS of situations where more body classes in the editor would go a long way. Here are just a few examples:

1. Using body classes such as post-type-post or post-type-page to style the editor or blocks based on post type (similar to this question about styling posts different from pages Is it possible to use a dark theme in the editor conditionally? #47856)
2. Using body classes such as theme-THEMENAME to style our blocks differently based on the current theme
3. Some plugins use body classes to pass user preferences to the editor, such as how Wayfinder (https://wordpress.org/plugins/wayfinder/) uses things like 'wayfinder-spacer-outline' to indicate a user's preference for spacer blocks showing their outlines.
4. Using body classes such as page-template-FOO to style things based on the current page's page template.

Themes and plugins have been relying on body classes for years, and bringing those classes - or at least the ability to add them - to the editor feels essential before the page/post editor gets iFramed in 6.2.

[richtabor]

While there is currently no solution, I believe the comment here hints at a possible solution.

Yea, seems that would be the way to do it — instead of selectively adding to the editor.

[richtabor]

Using body classes such as post-type-post or post-type-page to style the editor or blocks based on post type (similar to this question about styling posts different from pages #47856)

The post editor already adds already added post-type-{SLUG} to the body tag — or are you referring to something else?

@MadtownLems I'm curious how much you're styling per template outside of Global Styles? What are the use cases for not using Global Styles/Site Editor for applying styles? And are you using classic themes — or block themes?

[MadtownLems]

The post editor already adds already added post-type-{SLUG} to the body tag — or are you referring to something else?

It currently adds them to the body class, yes. However, starting in 6.2, the page/post is going to be inside an iFrame. As a result, they will no longer be accessible to the blocks. (And the body classes are already not accessible in the Site Editor, as that's already inside an iFrame)

And are you using classic themes — or block themes?

We are using classic themes with FSE-style features such as Template Parts.

[ndiego]

@MadtownLems I'm curious how much you're styling per template outside of Global Styles? What are the use cases for not using Global Styles/Site Editor for applying styles? And are you using classic themes — or block themes?

@richtabor I believe this is largely for classic and hybrid themes that are using the Block Editor and are attempting to make the Editor look more like the frontend. Jason can confirm this. That said, I do see other applications for this functionality for third-party extenders.

[nextgenthemes]

@ndiego No, I need this, and I do not use a classic or hybrid theme. WordPress/GB adds classes to the body based on what template is used. I use those classes to style my theme. Very important styles like body:not([class*="-no-sidebar"]. That way, I style all my templates that do not have a sidebar. But in the editor these do not work and mess up everything.

Why would this "largely for classic and hybrid themes"? WP adds all kinds of classes to the body on the frontend, and they are as relevant in Block Themes as they always were.

[ndiego]

Why would this "largely for classic and hybrid themes"? WP adds all kinds of classes to the body on the frontend, and they are as relevant in Block Themes as they always were.

Yup, there are tons of applications for the functionality. The bulk of the requests I have seen are from classic and hybrid theme developers, but that doesn't mean that it's also not useful for block theme developers as well.

[webmandesign]

I was modifying a block editor layout on a page edit screen using custom admin body class and then targeting the .editor-styles-wrapper in the CSS file using the class.

However, since some current version of Gutenberg (I am using v16.2.1 currently) the page block editor is enclosed within iframe so my admin body class does not affect the .editor-styles-wrapper anymore. (The issue is not present when disabling Gutenberg plugin and only using block editor included with WordPress 6.2.2.)

So, it seems this issue is more relevant than ever:
How can I add custom classes to .editor-styles-wrapper when it is rendered within an iframe?

[ellatrix]

Put this on my to do list. Not sure if we should do this in JS or make a request to the server. 🤔

[mrwweb]

Put this on my to do list. Not sure if we should do this in JS or make a request to the server. 🤔

My initial reaction is ideally both. For example, consider a custom class (or classes) that reflect a custom page template.

• Server-side / PHP: Having the class in the DOM on page load will prevent some Flashes of Mis-styled Content
• Client-side / JS: When selecting a custom page template, the same class(es) should be added to the DOM so a refresh isn't required

Another time I use custom body classes (and what editor classes) is when checking the editor's content for a certain condition like a Post Title block as the first block. Again, I want that available on page load if it's present in the saved content and immediately added if the block is inserted/moved in that position.

[webmandesign]

Put this on my to do list. Not sure if we should do this in JS or make a request to the server. 🤔

I definitely suggest server side (PHP) as it is useful when using plugins. For example, I was modifying block min-width in editor when user was editing WooCommerce "Shop" page content. In such case I can use PHP functions to check whether such page is being edited.

I personally have no usecase for JS class manipulation currently, so I can't really provide feedback for that.

[erikgripestam]

Yes, PHP would go a long way. I've relied on the admin_body_class filter in all my projects. As @CreativeDive mentioned, a block_editor_body_class is badly needed asap.

[DamChtlv]

Any ETA on this? 😅
@ramonjd suggered an idea in #56831, i don't know if that could help tho'

I tried to update editor body classes from outside (enqueue_block_editor_assets) and inside (enqueue_block_assets) the iframe with JavaScript without success sadly and i really need that to make it work with a style variation in my theme (my use case: i add is-style-xyz class when a user set a specific style variation of my theme in body class (body_class and admin_body_class) and i override some library css rules based on that)

EDIT : Found a fix that seems to work for now (atleast for my usecase), load this script using enqueue_block_assets hook and check for is_admin() to prevent loading it on frontend:

((wp) => {
  const { domReady } = wp;

  /**
   *  Update iframe classes
   *  @see https://github.com/WordPress/gutenberg/issues/17854
   *  @see https://github.com/WordPress/gutenberg/issues/56831
   *  @see https://github.com/WordPress/gutenberg/issues/55947#issuecomment-1801105188
   */
  domReady(() => {
    const editorBodyEl = document.querySelector('.editor-styles-wrapper');
    
    // Need to check context because this script will be loaded twice (once in the admin page, once in the editor)
    // @see https://github.com/WordPress/gutenberg/issues/53590
    const isIframeEditorContext = !!editorBodyEl;
    if (isIframeEditorContext) {
      setTimeout(addBodyClassesToIframe, 300); // setTimeout is needed otherwise classes get erased if added too early
    }

    // This add all body classes on the editor iframe (adapt to your needs)
    function addBodyClassesToIframe() {
      const adminBodyEl =
        window.parent.document.getElementsByTagName('body');
      const adminClasses = adminBodyEl?.[ 0 ]?.classList;

      if (editorBodyEl && adminClasses) {
        adminClasses.forEach((adminClass) => {
          editorBodyEl.classList.add(adminClass);
        });
      }
    }
  });
})(window.wp);

[ramonjd]

I just tested that idea out (using the results of get_body_class), but it doesn't do much more than printing out ownerDocument.body.classList.

More so, would we want it to add contextual or template/page-specific classes to the iframed body tag? I mean classnames that are rendered on the frontend, e.g., home blog or page-template-default page page-id-2?

[erikgripestam]

Any updates on this?

[roborourke]

I've hit this issue but in relation to block templates and the new Section Style feature https://make.wordpress.org/core/2024/06/24/section-styles/

I made a section style for a set of post types, but lets say we simplify that down to just the post post type. A basic template example is like the following:

<!-- wp:template-part {"slug":"header"} /-->

<!-- wp:group {"className":"is-style-article","layout":{"type":"constrained"}} -->
	<div class="wp-block-group is-style-article">
		<!-- wp:post-content /-->
	</div>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer"} /-->

is-style-article comes from a section style JSON called /styles/sections/article.json that extends group blocks.

That section style is used to set a bunch of different defaults on the blocks inside the article like margins, typography, spacing etc... This works as you would expect on the front end, but of course in the admin when editing a post the containing group block is missing.

So one solution could be to set the post type template to include the outer group that has the section styling. That's probably what I'll go for in this instance, and it could be the documented approach in lieu of the new functionality around template coming in WP 6.7 https://developer.wordpress.org/news/2024/08/29/registering-block-templates-via-plugins-in-wordpress-6-7/

[roborourke]

Actually looks like section styles don't preview/apply in the editor so maybe not really ready yet.