Like the blog? Get the book »

How to Disable Gutenberg: Complete Guide

How to Disable Gutenberg: Complete Guide

Gutenberg soon will be added to the WordPress core. This is great news for some, not so great for others. With 99.9999% (estimate) of all WordPress sites currently setup to work without Gutenberg, the massive changes barreling down the pike are going to affect literally millions of websites. And as swell as the whole “Gutenberg” experience may seem, the simple truth is that a vast majority of site owners will not be prepared when it finally hits. Nor will many small business have time or budget to test and update client sites to accommodate ol’ Gut’.

Note! To help save time, I may refer to Gutenberg as G7G or g7g throughout this article (e.g., in code snippets). Just faster than typing it out every time :)

*You* have the power..

If that sounds like your situation, you basically have two options:

  1. Buck up and fork out your time and money to test and update all existing client sites for Gutenberg.
  2. OR, simply disable Gutenberg until you are ready for it.

From the WP peeps I’ve heard from, only a handful are full on-board ready to sacrifice whatever amount of time and money it takes to implement and support Gutenberg. Most folks I’ve heard from are confused and/or just plain unaware of the huge changes in store for them and their WordPress-powered sites. Let alone have the resources to retroactively implement G7G support.

So for folks in that second camp, where it’s just not feasible to immediately drop everything and re-learn how to develop with WordPress using JavaScript, this post explains numerous ways to disable Gutenberg, including disabling Gutenberg via plugin, and then also a bunch of methods to disable Gutenberg programmatically, just FYI.

Tip! If Gutenberg is disabled on your site, you can always conditionally enable it for any post, page, template, user role, post type, and so forth. To learn how, check out our DigWP tutorial on how to selectively enable Gutenberg.

Disable Gutenberg via Plugin

The easiest way to disable Gutenberg is to install my free plugin, Disable Gutenberg. It is a simple plugin focused on one thing: disabling Gutenberg and restoring the default classic WP Editor screen. Just enable the plugin, choose your options and done. Options include:

  • Disable Gutenberg completely (all post types)
  • Disable Gutenberg only on specific post types
  • Disable Gutenberg for specific user roles
  • Disable Gutenberg for any theme templates
  • Option to hide the “Try Gutenberg callout nag
  • Option to hide the Gutenberg menu item

So it’s flexible yet simple, and super easy to use. Under the hood, it works the same way as the Classic Editor plugin, but can do MUCH more. Check out the documentation and homepage for more details.

Disable Gutenberg via Code

Fortunately, there are numerous ways to disable Gutenberg programmatically. Let’s look at each of them.

Disable Gutenberg Completely

Update! New way to disable Gutenberg

As expected, Gutenberg is changing constantly. As of now, you can use either of the following filter hooks to disable Gutenberg completely on your entire site:

// disable for posts
add_filter('use_block_editor_for_post', '__return_false', 10);

// disable for post types
add_filter('use_block_editor_for_post_type', '__return_false', 10);

Again, either of these hooks will suffice; no need to add both (although technically it won’t hurt anything). The idea is that the different hooks enable you to identify both single posts and archive views. These hooks work for Gutenberg plugin version 4.1 or later, and WordPress 5.0 (beta) and later. For older versions, use the code below.

Older versions of WP/Gutenberg

To completely disable Gutenberg on older versions, add either of the following filter hooks via functions.php or custom plugin (or even a must-use plugin!):

// disable for posts
add_filter('gutenberg_can_edit_post', '__return_false', 10);

// disable for post types
add_filter('gutenberg_can_edit_post_type', '__return_false', 10);

Again, no need to add both of these lines, either will work to disable Gutenberg everywhere on your site (i.e., for all posts and post types). These filters are the recommended way of disabling Gutenberg. They work with Gutenberg plugin version less than 4.1, and WordPress versions less than 5.0 beta.

Conditional technique

In case it is useful for anyone, here is an example of how to conditionally disable Gutenberg/Block Editor depending on which version of WordPress is running.

// Disable Gutenberg

if (version_compare($GLOBALS['wp_version'], '5.0-beta', '>')) {
	
	// WP > 5 beta
	add_filter('use_block_editor_for_post_type', '__return_false', 10);
	
} else {
	
	// WP < 5 beta
	add_filter('gutenberg_can_edit_post_type', '__return_false', 10);
	
}

Here we use version_compare() to see if WordPress is running at 5.0 (beta) or better. If so, then we disable Gutenberg using the new filter. Otherwise, WordPress is running older version so we disable using the latest filter.

Disable Gutenberg for Custom Post Types

Update! New way to disable Gutenberg

For newer versions of Gutenberg (4.1+), and WordPress 5.0 beta, here is how to disable Gutenberg for specific post types:

function digwp_disable_gutenberg($is_enabled, $post_type) {
	
	if ($post_type === 'book') return false; // change book to your post type
	
	return $is_enabled;
	
}
add_filter('use_block_editor_for_post_type', 'digwp_disable_gutenberg', 10, 2);

This is the same as the older method, the only thing that has changed is the hook. Compare with the code used for older versions..

Older versions of WP/Gutenberg

Here is how to disable Gutenberg on specific post types for older versions of Gutenberg (less than 4.1), and WordPress versions less than 5.0 beta.

The Gutenberg editor is active only on WP posts where it is enabled. By default, this includes WP Posts and Pages. Other post types can be disabled using the same filter, gutenberg_can_edit_post_type. For example:

function digwp_disable_gutenberg($is_enabled, $post_type) {
	
	if ($post_type === 'book') return false; // change book to your post type
	
	return $is_enabled;
	
}
add_filter('gutenberg_can_edit_post_type', 'digwp_disable_gutenberg', 10, 2);

Here we are disabling Gutenberg only for the book post type. So it will only affect books and no other post types. To disable for a different post type, replace book with the name of your post type.

Disable when registering post types

It’s also possible to disable G7G when registering your Custom Post Types. This method only makes sense for CPTs that do not make use of the post editor, as it basically disables the editor panel entirely. To do so, simply omit editor from the supports parameter when registering your post type. Here is an example:

$args = array(
	'label'    => __('Books'),
	'labels'   => $labels,
	'supports' => array(
		'author',
		'custom-fields',
		// 'editor', // <-- do not add this param
		'title',
		'thumbnail'
	),
	'has_archive' => false,
	'hierarchical' => false
);
register_post_type('books', $args);

Because we excluded the editor parameter, the books post type will not include the post editor, and thus will not include any Gutenberg stuff.

Disable when registering post types (via REST API)

Another way to disable Gutenberg when registering custom post types is to disable REST for your post type. This can be done by setting the show_in_rest parameter to false, for example:

$args = array(
	'label'        => __('Books'),
	'labels'       => $labels,
	'show_in_rest' => false, // set to false to disable G7G
	'supports'     => array(
		'author',
		'custom-fields',
		'editor', // works even when editor is supported
		'title',
		'thumbnail'
	),
	'has_archive' => false,
	'hierarchical' => false
);
register_post_type('books', $args);

So even if your post type supports the post editor, it’s still possible to disable Gutenberg by disabling the REST API, because Gutenberg requires the REST API in order to work.

For more information about registering post types, check the WP Codex.

Disable Gutenberg for Meta Boxes

Some of my plugins make heavy use of meta boxes, and it’s gonna require significant time to rework everything. Fortunately, there is a way to disable the Gutenberg editor on any screens that make use of your meta box:

__block_editor_compatible_meta_box

We can pass that as an argument when adding the meta box, for example:

add_meta_box('metabox_id', 'Metabox Title', 'metabox_callback', null, 'advanced', 'default', array('__block_editor_compatible_meta_box' => false));

Notice in the seventh parameter, $callback_args, we are passing the __block_editor_compatible_meta_box argument as an array item. For more details about adding meta boxes, visit the WP Codex.

The “old” way..

This method is not recommended, but worth mentioning as it sheds light on what’s possible. Simply add the following line to your site’s wp-config.php file, just before the line that says, “That’s all, stop editing”:

$_GET['classic-editor'] = true;

After doing this, Gutenberg will be disabled and the Classic Editor screen enabled on all “Edit” screens. But again, this is an older way of disabling Gutenberg. Please use one of the previous methods instead.

Note about Custom Fields

If you are working with Custom Fields and the Gutenberg editor, you will notice that the “Custom Fields” meta box is not displayed on G7G screens by default.

To help with this, I wrote a plugin that restores display of the Custom Fields meta box: Custom Fields for Gutenberg. A lot of my plugins use custom fields, so this plugin ensures that users will be able to see them on Gutenberg-enabled screens. Thank you, me! :)

Bonus!

The above solution is straightforward enough, however you may want to go a bit further and hide the “Try Gutenberg” nag across admin screens. To do so, you can install the Dismiss Gutenberg Nag plugin.

Disclaimer

Gutenberg technology is constantly changing. So be sure to test the above code methods with the latest version of WP/G7G before implementing on a live site. And of course, the Disable Gutenberg plugin will be kept up-to-date and always current with latest G7G functionality. Cheers people.

Translations

29 responses

  1. Thanks Jeff for sharing these code snippet on disabling Gutenberg.

  2. Perhaps at least some of the fear of Gut that we (what is beginning to feel like the “silent majority” of us) feel is due to a very substantial lack of understanding of what the thing ACTUALLY IS and/or what “greater good” the thing is actually thought to accomplish.

    Perhaps the fear/wariness/distrust we feel is, as you allude to, not knowing precisely what damage the “new regime” will do our sites.

    Perhaps our distrust/angst is because the so-called “enhancement” comes from the same programmers who’ve for years shown us that simple programming courtesies such as saving and replacing cursor states before and after “saves” are too menial to be considered.

    Me? In health care I’m used to trying to understand what you might call the “back-story” of sorts. I’m having a hard time getting my head around what must be either the incredible short-sightedness and/or arrogance that keeps pushing this type of rollout forward (not even considering the actual product). Did I blink and miss when the “programmers” became more important than the actual “users”?

    At any rate, I’m glad there is at least one “voice in the wilderness.” Thanks

    • You are not alone, DJ! I follow Gutenberg pretty closely on social media, and can assure you that there are plenty of voices sharing their concerns about g7g.

      Unfortunately, the JavaScript kiddies pretty much are claiming WordPress as their own. And why wouldn’t they? Instead of putting in the hard work and building their own CMS from the ground up like everyone else, it’s much easier to just hijack a project that’s already successful. It’s the same thing that happens all the time in politics, business, et al. No surprise it’s happening to the world’s #1 CMS.

  3. You really are the man!

    Can we go ahead and activate your Disable Gutenberg plugin now so we’re ready or are we supposed to wait till G launches?

    Thanks!

    • Fine to add now (pre-v5.0) or wait until Gutenberg is merged into core (v5.0+). Just nothing will happen pre-5.0 without the Gutenberg plugin also active. Cheers!

  4. Thank you!

  5. Any chance the’Disable’ plugin and the ‘Dismiss’plugin will be combined into one? Like adding a ‘Dismiss nag’option in the’Disable’plugin?

    Thank you by the way!

  6. Thank you for this detailed article. I knew about the add_filter('gutenberg_can_edit_post_type', '__return_false'); filter, but some of the other methods are new to me. Way to fight “software communism !!!”

  7. I had already used some of your plugins, and I am really grateful that you have developed one for disabling Gutenberg. Good to know that the plugin can already be installed before v. 5.0.

    I moved all my sites (about ten of them) to WordPress over the past two years: months of work, and thousands of dollars spent when I needed professional help for specific tasks/sites. I am open to changes—and to Gutenberg. On some of my sites, I will probably use it. But on at least four sites, I face a major challenge: they include a number of articles with footnotes, converted into WP articles with endnotes thanks to the excellent Mammoth Docx Converter plugin.

    The logic of blocks characteristic of Gutenberg runs counter articles with interactive endnotes. I am aware that this is a niche market, but I hope that some tool will be developed that will allow users to keep working endnotes with Gutenberg. Otherwise, in the long run, I may regret the many sleepless nights spent on moving all those hundreds of articles to WordPress, after hearing so much about retrocompatibility…

    • Thanks for the comments, Jean-Francois. I also have many sites with existing content, and lots of code snippets with angled brackets and other special characters, etc. Unfortunately the last time I checked, Gutenberg completely mangles code snippets by converting characters to their HTML equivalents, which means I won’t be using Gutenberg ever on sites like DigWP.com, PerishablePress.com, WP-Mix.com, and many others. Just too unpredictable.

      Like you suggest, maybe for new projects I might try Gutenberg, but it’s got a loooooong way to go before I will feel comfortable using it for anything serious. And that is sad, especially considering how much work has gone into making the WP writing/editing experience so awesome; but now all that is disappearing thanks to Gutenberg.

      • Thank you for sharing those experiences. Your comments indeed confirm my fears.

        I definitely won’t be using Gutenberg on my main websites. But the question is: how long will it be possible to use WP without using Gutenberg? Going without it is presented as a transition rather than as a long-term option (admittedly, several years – but a few years are gone fast, and I want my pre-Gutenberg content preserved for more than a few years, I want it to remain accessible in 20 or 30 years).

        There seem to be no serious prospects for a WP forking—and anyway this would probably not be a very realistic option. Thus we can only hope that post-Gutenberg WP will develop in such a way that our pre-Gutenberg content can at some point flow smoothly into the Gutenberg environment. Considering how large the WP community is, and how varied the needs, we may reasonably hope that acceptable ways will be found.

        In the meantime, I will definitely install and activate your plugin on several of my sites. This sounds better than sticking to pre-5.0 WP once the Gutenberg era WP comes. Thank you once again!

  8. Thanks SO MUCH for this.

    We use WP for several hundred small business sites, and was dreading having to retrain hundreds of people on how to edit their sites. While the old editor may not be perfect, the fact that my clients thought it was like using Word really helped. Gutenberg would give them no common ground to even associate with.

    Do you know if it presents any problems to use it on Multisite?

    • Awesome Jon, glad to hear. Should work fine on Multisite, although to be honest I have not yet tested. I should mention the latest version includes options to disable the “Try Gutenberg” nag, and hide the plugin menu item. So you can disable Gutenberg and hide all traces of it, to keep your clients safe and happy.

  9. Rahul Mukherjee

    Hi Jeff,

    To be honest I even didn’t knew about the integration of Gutenberg is already in the process. I was just installing and reaging about your “Head Meta Data”, plugin. Here I found about the game. Really surprised to know about the integration as we are not even interested in installing Gutenberg, then how come they just dab into the codes! As you already mentioned hijacking the worlds no. 1 CMS, well this cannot be any fair rule to integrate this things while there are lots of Critical important functions not only I but everyone will appreciate…Thanks again for your article and the plugin, I have bookmarked your page for future readings.

  10. Hi Jeff,
    You just took a huge load off my mind. I’m manage a bunch of PlugIns and Gutenberg has become a bit of a concern. It doesn’t play as smoothly with some of our PlugIns as we would like. In five minutes you just solve one of my biggest concerns. Much thanks and buckets of gratitude ;-)
    Cheers,
    -jc mailen

  11. I have already bookmarked this page! Really appreciate it! There will likely be many who do not like Gutenberg in the beginning. I just saw it has a 2.7 star rating on wordpress.org. Not very good. Thank you very much for these options!

  12. Hi Jeff,

    Great post. What with Brexit (over here), GDPR (over here) and Gutenberg (everywhere), good solutions are really welcome! Regarding the filter to disable Gutenberg completely, is your understanding that post editing will default to the TINYMCE editor, which for the time being will still be included in core? Then, later, if it is removed, we would need to install the Classic Editor plugin?

    • Yes that sounds correct. With the disable plugin/technique, the “classic” editor is used for all post types (can choose to enable/disable each post type in plugin settings). If they remove TinyMCE at some point, I’ll add a method to include the classic editor by default. I’ll need it for all of my sites, else Gutenberg would destroy hundreds of meticulously formatted posts. Not even going to take a chance with it.

  13. Hey Jeff,

    Awesome articles with good solutions as always from you. My journey in WordPress was begun by reading ‘Digging into WordPress’.Just love it.

    I have a question, some of my client’s website is running with page builder, which are conflicting with Gutenberg.Although gutenberg is now in plugin form, but clients are worried about their site, when gutenberg merged with core.Probably lack of experience I can not fully convince them.If you don’t mind I just want to know your thought regarding this issue.

    Thanks.

    • Hi rameen,

      Thanks for the great feedback :)

      Honestly I’ve never used any “page builder” plugin in 15+ years working with WordPress, but can advise that if any page builder plugins are used on a site, it probably is best to disable Gutenberg to prevent any conflicts or weird behavior. Just because such plugins and G7G are targeting the same thing: post content, post meta, and so forth.

  14. Hi Jefff

    Thank you for creating the plugin. I am going to use it now with my main site.

    Jeff i have question.

    I understand that gutenberg will be with core in 5.0 my question is this

    After 5.0 hits and i am going to create a new website powered by wordpress

    Can i still download your Disable gutenberg plugin so that i can disable any gutenberg 5.0 site and revert the Editor back to the Tiny MCE editor?

    I like the idea of Tiny MCE i need to learn gutenberg first before i will use it.

    The idea of havin ayone to create their own website as easy as all the website builder is just madness.

    They should let those unwanted boastful kids to create their own website from the ground up and not a 123 finish procesa

    What happen to hard work and dsicipline.

    Thank you Jeff.
    Aulliver

    • I could not agree more. The JS kids currently pushing G7G should have built their own CMS instead of hijacking WordPress. And to answer your question, yes you can disable G7G anytime before or after WP 5.0, just install, activate, and done.

  15. I actually like the concept of “blocks” that Gutenberg introduces, which gives me more control of my content especially in terms of structure and styling.

    Having said that, its UI is far from perfect. And I agree that it should be developed as just a plugin instead of being integrated into the WordPress core. Its shocking 1-star reviews on WordPress plugin repo simply say the truth that Gutenberg is just not ready yet for everyone.

Comments are closed for this post. Contact us with any critical information.
© 2009–2024 Digging Into WordPress Powered by WordPress Monzilla Media shapeSpace