Gutenberg: Dequeue theme.css

[samikeijonen]

Is your feature request related to a problem? Please describe.
At the moment it's pretty hard to dequeue theme.css from the editor. See comment from issue 5360.

With that comment I think I need to replace the original theme.css with empty one:

add_action( 'enqueue_block_editor_assets', function() {
    // Overwrite Core theme styles with empty styles.
    wp_deregister_style( 'wp-core-blocks-theme' );
    wp_register_style( 'wp-core-blocks-theme', asset( 'styles/theme.css' ), null );
}, 10 );

But I feel this is not the best practise, or there might be better way of doing this?

Describe the solution you'd like
To be honest I haven't looked the decencies that deep so that I could suggest solution. But I'd hope we look into this more.

[mtias]

cc @brandonpayton

[brandonpayton]

Thanks for the cc!

Hi @samikeijonen, it turns out that styles can be registered with an empty source, so you can use that instead of an empty file:

add_action( 'enqueue_block_editor_assets', function() {
    // Overwrite Core theme styles with empty styles.
    wp_deregister_style( 'wp-core-blocks-theme' );
    wp_register_style( 'wp-core-blocks-theme', '' );
}, 10 );

This appears to work well today to omit theme.css, and the WordPress style dependency code acknowledges sourceless styles here. Does this address your concern?

When I originally added theme.css, my impression was that we didn't want theme.css to be optional in the editor, so the above solution seemed like the furthest we should go in allowing the file to be omitted. I may be wrong though. What do you think, @mtias?

[samikeijonen]

I'm OK with the solution by @brandonpayton. But perhaps add_theme_support() rule could be better.

This is my current setup for the editor and works just fine:

Edit: using hook enqueue_block_assets

After plugin version 5.5.0 we need to use hook enqueue_block_assets.

add_action( 'enqueue_block_assets', function() {
    // Overwrite Core block styles with empty styles.
    wp_deregister_style( 'wp-block-library' );
    wp_register_style( 'wp-block-library', '' );

    // Overwrite Core theme styles with empty styles.
    wp_deregister_style( 'wp-block-library-theme' );
    wp_register_style( 'wp-block-library-theme', '' );
}, 10 );

Old way before 5.5.0

add_action( 'enqueue_block_editor_assets', function() {
    // Main block styles.
    wp_enqueue_style( 'uuups-blocks', asset( 'styles/editor.css' ), null, null );

    // Overwrite Core block styles with empty styles.
    wp_deregister_style( 'wp-block-library' );
    wp_register_style( 'wp-block-library', '' );

    // Overwrite Core theme styles with empty styles.
    wp_deregister_style( 'wp-block-library-theme' );
    wp_register_style( 'wp-block-library-theme', '' );
}, 10 );

[BinaryMoon]

Just a quick note that the handle for deregistering _theme.css_ is now wp-block-library-theme

[samikeijonen]

I updated code snippet.

[aduth]

As best I can tell, there are no actionable tasks remaining here? Proactively closing until told otherwise.

[BinaryMoon]

I think the request is to make it easier to dequeue theme.css from the editor since the current method is not the standard WordPress way. Normally you would just dequeue the style, but we have to deregister it and then register a non existent file in its place. Not the sort of thing that can be found easily so I think it should either:

1. Be changed so the styles can be dequeued in the traditional way
2. Have good documentation that explains the process so that theme developers can easily learn how to do it.

[aduth]

Thanks for clarifying the actionable tasks. I'll reopen.

[aduth]

Based on how the wp-block-library styles are enqueued, at least for this stylesheet shouldn't it be sufficient to wp_dequeue_style( 'wp-block-library' ); on the enqueue_block_assets action?

https://github.com/WordPress/gutenberg/blob/5800ed3b4d282d4508a63bb773558ca3bde74782/lib/client-assets.php#L1001-L1040

[BinaryMoon]

Looks like that would work for wp-block-library however I would like to dequeue wp-block-library-theme, and that is loaded as a dependency for wp-edit-blocks which is why the funky deregister re-register dance is needed.

https://github.com/WordPress/gutenberg/blob/5800ed3b4d282d4508a63bb773558ca3bde74782/lib/client-assets.php#L660-L671

[samikeijonen]

Also noting that we are talking how dequeueing styles in the editor using enqueue_block_editor_assets hook. In front-end there is no issues.

[persianturtle]

I am developing a custom theme with Gutenberg and am having trouble dequeueing/degrestering the styles added by:

wp_register_style( 'wp-block-library', gutenberg_url( 'build/block-library/style.css' ), current_theme_supports( 'wp-block-styles' ) ? array( 'wp-block-library-theme' ) : array(), filemtime( gutenberg_dir_path() . 'build/block-library/style.css' ) ); wp_style_add_data( 'wp-block-library', 'rtl', 'replace' );

in client-assets.php

I've tried all of the code snippets listed in this thread and I'm not able to remove the following:

<link rel='stylesheet' id='wp-block-library-css' href='https://agendia.lndo.site/wp-content/plugins/gutenberg/build/block-library/style.css?ver=1536503482' type='text/css' media='all' />

What am I missing?

[samikeijonen]

@persianturtle Check this code from this answer.

[persianturtle]

@samikeijonen The code from that answer doesn't work for me. I've tried it both with and without:

add_theme_support( 'wp-block-styles' );

Is this part:

wp_enqueue_style( 'uuups-blocks', asset( 'styles/editor.css' ), null, null );

important?

[vguerrerobosch]

@persianturtle I think you are trying to dequeue gutenberg stylesheet in the front-end but this thread is about removing it from the editor. In the front-end the classic solution will do just fine (at the moment). Something like this should work.

function custom_theme_assets() {
    wp_dequeue_style( 'wp-block-library' );
}

add_action( 'wp_enqueue_scripts', 'custom_theme_assets', 100 );

[vguerrerobosch]

btw, i think this statement in gutenberg handbook is not how it is actually working in version 3.7.0:
https://wordpress.org/gutenberg/handbook/extensibility/theme-support/#default-block-styles

[mattheu]

I have run into this issue also.

I think it would be good to clarify the intent for what site developers are expected to do here.

Consider the following situation:

• If a developer is NOT using add_theme_support( 'wp-block-styles' ); and instead they are providing all the styles for core gutenberg blocks on the front end.
• Also they are providing an editor stylesheet to make Gutenberg look more like the front end of their site.

Then what is the expectation? Should they be removing this stylesheet from Gutenberg? Or should they be wrestling with conflicting CSS and trying to overwrite these styles in their theme?

If the expectation is that this should be removed, then it should be made easier to do so. The script wp-block-library-theme should be enqueued independently and NOT be a dependency of the 'wp-edit-blocks' style.

[gerlandotermini]

+1

[hacknug]

Can anyone help me understand what's the point of having add_theme_support( 'wp-block-styles' ) if this stylesheet is still enqueued by default? Why doesn't this respect my decission to opt-out of the default styles?

[hacknug]

#wp-block-library-css is also enqueued in another website where I don't use Gutenberg at all and have the Classic Editor plugin installed.

Any reason to enqueuing it even when it's (apparently) not used at all?

[samikeijonen]

Any reason to enqueuing it even when it's (apparently) not used at all?

You're correct, there is no point. I'd consider this as bug in Classic Editor plugin.

[edadams]

I personally think this is a Classic Editor plugin concern and not something Gutenberg should have to deal with.

The rationale, in the words of a contributor to the Classic Editor plugin, is:

I'm reluctant to add it to this plugin as it may cause problems with themes that expect these styles, and it seems there will be more and more themes like that.

Just so we're clear about the fact that it's not a "bug". If the Classic Editor team isn't interested in it, then it's not like removing the CSS file from the front- and back-ends ourselves is really the worst thing, especially if you do it as an mu-plugin. Should we have to? Ideally, no... but 🤷‍♀️