A better way to disable Gutenberg (with and without a plugin)
The Classic Editor and Classic widgets plugins are officially recommended for disabling Gutenberg. Both are popular* and highly rated, but aside from having two plugins to install, the Classic Editor does not remove Gutenberg’s styles and recently added SVGs.
Although the performance impact is not huge, it’s more things Google wants us to improve as part of their Core Web Vitals. Certainly, since I have been monitoring it the amount of unused Gutenberg output has doubled, but fortunately, it’s easy to fix.
As this is part of my series on how WPCodeBox is helping me to reduce my WordPress dependencies I’m sharing the (complied) code snippet I’m using. Suggestions for improvement are always welcomed and, of course, you don’t need WPCodeBox. You can add it to your child theme functions.php .
* Active installs of the Classic Editor are unknown as the counter stops at 5 million. It’s probably closer to 10 million.
WPCodeBox – 25% off coupon
Just enter “beaverjunction” to get the best discount available.
The Disable Gutenberg Plugin
First, I want to mention an excellent plugin by Jeff Starr called Disable Gutenberg. It does all that the snippet here does and is most likely the better route if you needed to Disable Gutenberg by post type and post/page ID.
Although my aim is to reduce plugin dependencies, it’s a response to a general shift in WordPress towards DIY users. Disable Gutenberg is a developer run plugin. It’s unlikely to be sold to a hosting company or start displaying annoying adverts.
Plus the author is something of a hero of mine since 2011 when I read his “Digging into WordPress” book written with Chris Coyier (founder of CSS trick and CodePen). This is a plugin I trust.
My compiled code snippet
I started using a snippet partly because at the time Disable Gutenberg plugin was not removing all of Gutenberg’s styles. It does now and has been responding to other additions such as the inline SVGs added in WordPress 5.9.
The other reason was, I was finding myself in the WPCodeBox UI regularly. It was convenient being able to switch on and off the snippet and better for my understanding of what was going on.
Until there is a way to alter WPCodeBox snippets across multiple sites I am likely to keep the Disable Gutenberg plugin on client sites, but I like this option for my sites.
The video below shows what Gutenberg adds to regular sites. Excluded are the additional styles for WooCommerce. In order they are the:
- Inline SVGs.
- Inline Global styles.
- Inline block library theme styles (presently an external file in the Gutenberg plugin).
- External block library styles (this is the largest. Presently at 100kb uncompressed).
Hopefully, the snippet here is self explanatory. I have commented out the action that removes the WooCommerce styles . You could comment out what you do not need.
// Disable Gutenberg for posts/pages.
add_filter('use_block_editor_for_post', '__return_false', 10);
// Disable Gutenberg for other post types.
add_filter('use_block_editor_for_post_type', '__return_false', 10);
// Disables the block editor from managing widgets.
add_filter( 'use_widgets_block_editor', '__return_false' );
// Remove Gutenberg CSS.
add_action( 'wp_enqueue_scripts', function() {
wp_dequeue_style( 'wp-block-library' ); // External CSS
wp_dequeue_style( 'wp-block-library-theme' ); // Inline CSS
wp_dequeue_style( 'global-styles' ); // Inline CSS
// wp_dequeue_style( 'wc-blocks-style' ); // Remove WooCommerce block CSS
}, 20 );
// Remove SVGs.
remove_action( 'wp_body_open', 'wp_global_styles_render_svg_filters' );
Note: The WPCodebox repository also has this snippet to return Classic Widgets if using the Gutenberg plugin
add_filter( 'gutenberg_use_widgets_block_editor', '__return_false' );
There is also this which I assume allows users of the block editor to remove duotone support
remove_action( 'render_block', 'wp_render_duotone_support', 10 );
WPCodeBox conditionals
I don’t need it here, but wanted to see what I could do. I could assign the snippet to WordPress roles, but I learned we would need extra php conditionals to assign it to individual posts. For those who can wrangle code here is what Ovidiu (from WPCodeBox) told me: The post type or post conditions only work on the frontend if you are on that post’s page. If you want to check this on the edit page, you would need to do something like this:
function my_func_to_enqueue_scripts() { global $typenow; if( 'page' == $typenow ) {} }
or you could do something like this in a custom php condition:
<?php global $typenow; $typenow === 'page';