Gutenberg: Generate body class for Gutenberg pages & provide helper function

[maddisondesigns]

Issue Overview

I think that it's pretty obvious by now that there's a large portion of the WP community that are still going to need to continue to use the classic editor once WP5.0 ships. Not only that, when providing themes in the .org Theme Directory, it's going to be important that the theme supports both the classic editor as well as the new Gutenberg markup.

I know it's been mentioned (briefly) in the past on a ticket somewhere, but that discussion never went anywhere. I think it's important that WP adds a new gutenberg body class to any pages that are rendered by Gutenberg. The styles required to render content from the classic editor and also from Gutenberg, are going to be significantly different and we need a way to know what editor is rendering the page.

Likewise, it would also be good to have a helper function so that our PHP can know what editor is being used for the current page. Something like is_gutenberg(). This will be helpful if people want to enqueue different stylesheets or scripts, depending on what editor is being used.

I think it's important that these are supported core functions as well, rather than just adhoc code snippets that we have to manually add to each of our themes to get this sort of functionality.

[pm-hiroshi]

Hi to @maddisondesigns .
I was looking for is_gutenberg() too.
Then I found existing gutenberg_post_has_blocks() which works as is_gutenberg() so far.
Actually this code did the job. ( $post can be either post object or post_id. )

function is_gutenberg( $post ) {
    return gutenberg_post_has_blocks( $post );
}

I am sorry if you knew gutenberg_post_has_blocks() exists.

PS
This is my very first comment to WordPress repositories.
And sorry for my bad English.

[maddisondesigns]

@pm-hiroshi Thanks for that. I wasn't aware that gutenberg_post_has_blocks() existed, so I appreciate you letting me know. That'll be very useful

[pm-hiroshi]

We used to think that is_some_kind_of_condition() always exists.
So I still wish that is_gutenberg() exists.

[mtias]

I think a has-blocks class or similar would be better as part of post_class in index pages and body class for singular.

[maddisondesigns]

@mtias That would be fine. Thanks. It obviously makes sense to get away from the name 'Gutenberg' so as long as there's something that we can use, both in php and css, I don't really mind what it's called.

[obenland]

Can you help me better understand what that body class is for?

The styles required to render content from the classic editor and also from Gutenberg, are going to be significantly different

Do you mean the HTML/CSS class structure here or displaying a gallery differently?

[maddisondesigns]

@obenland Yep, the html/css. The html/css that is output on the front-end is significantly different when using Gutenberg, compared to using the Classic Editor. As someone who has themes on .org, we're now going to need to support both editors in our theme so it would be great if Gutenberg added a body class so as to help us style for the different editors.

Likewise, it would also be good to have a helper function so that our PHP can know what editor is being used for the current page. Something like is_gutenberg() or is_block_editor() . This will be helpful if people want to enqueue different stylesheets or scripts, depending on what editor is being used.

[obenland]

it would be great if Gutenberg added a body class so as to help us style for the different editors
Wouldn't the differently structured html/css itself giving it away? CSS classes starting with wp-blocks-* are also a good giveaway. If the only difference between two versions is the body class, the body class would be obsolete.

I'm just having reservations when it comes to adding a Core body class because that class will have to be supported for the rest of time. And with a future so close where every post will be made out of blocks, having a has-blocks class floating in there doesn't feel very useful.
A theme can do whatever it wants, including adding any body class it needs, I'm just not sure it should be Core-provided.

This will be helpful if people want to enqueue different stylesheets or scripts, depending on what editor is being used

Gutenberg currently comes with the enqueue_block_editor_assets action for that. In case that doesn't get ported over, additional scripts/styles could be enqueued based on what wp_script_is( 'wp-edit-post' ) and such returns.

[maddisondesigns]

And with a future so close where every post will be made out of blocks, having a has-blocks class floating in there doesn't feel very useful.

There are going to be tens of thousands of sites that aren't using blocks and will be using the Classic Editor. For our Themes on .org. it's also imperative that they continue to support the Classic Editor whilst adding new features for Gutenberg.

With that said, this issue was raised almost 7 months ago and obviously a lot has changed since then. I've been able to get around the lack of a body class so far, so it's probably not quite as important anymore.

Gutenberg currently comes with the enqueue_block_editor_assets action for that.

As far as I'm aware, enqueue_block_editor_assets is just for loading assets in the Dashboard/Editor. I was hoping to get something like is_gutenberg() or is_block_editor() for the front-end. i.e. So we can enqueue different assets depending on whether the page is being rendered by Gutenberg or by the Classic Editor

[webmandesign]

I was actually implementing similar body class in my theme a week ago. Then it occurred to me and I'm with @obenland in opinion on such class.

We shouldn't actually apply any class just because the Gutenberg is used on the post/page. Gutenberg will become standard and what will we do with the class then...? ;)

If anybody really needs such a class, just implement the functionality into your theme. But for making your theme future proof, I'd suggest using negative class, something like:

function themeprefix_body_class_blocks( $classes ) {
    if ( is_singular() && ! has_blocks() ) {
        $classes[] = 'has-no-blocks';
    }
    return $classes;
}
add_filter( 'body_class', 'themeprefix_body_class_blocks' );

Then you can apply specific styles to Gutenberg pages using body:not(.has-no-blocks) CSS selector.

But than again, once you update your theme for Gutenberg in the future, you will most likely rewrite the CSS, so it's really up to you if you use has-blocks or has-no-blocks class B-)

[mtias]

Leaving this is in user land seems good for now. It can always be added later if the need becomes more clear.