A way to disable Gutenberg editor in code?

[smp303]

If Gutenberg is to be enabled by default...

For a lot of existing developers who have customised wp-admin editor sections for their clients the ability to not have gutenberg editor enabled by default could be priceless. A simple option like

DEFINE{'ENABLE_GUTENBERG', false);

Would be great. Then we can all safely update our sites without the fear of the admin being "broken" for our clients.

My fear is that if it is enabled by default many people will avoid updating and as such lead to many sites using legacy versions and being open to hacking etc...

Installing a plugin makes the whole task a lot more complex and relying on 3rd party code is a bad idea.

[aduth]

See also:

• https://github.com/WordPress/gutenberg/blob/master/docs/faq.md#will-i-be-able-to-opt-out-of-gutenberg-for-my-site
• https://wordpress.org/plugins/classic-editor/

[smp303]

Hi @aduth updated the title to make more sense - looking for a code options :) thanks

[wpmark]

I think this would be a very useful function to have for a lot of developers. In fact I would go as far as suggesting that I think Gutenberg should only be active on new installs of WordPress that are version 5.0 rather than being active on sites that are upgrading to WordPress version 5.0 - when the merge into core happens.

If this was combined with a way to activate/deactivate in the code then developers could turn it on when ready.

[aduth]

Could you elaborate on why you need to achieve this via code?

If it's an issue of client visibility / control, you could always install the above-mentioned plugin as a "Must Use Plugin": https://codex.wordpress.org/Must_Use_Plugins

[smp303]

Because a code change is quick and easy - enabling a plugin is 1) not my code and 2) not as simple as adding in some code - adding to the list of dependancies is not a practical nor sensible way to approach this issue.

[aduth]

Defining a constant may be your code, but the logic which operates on said constant would be just as much not your code as the officially-maintained "Classic Editor" plugin.

I should clarify that I'm not trying to be argumentative, but rather trying to have a better understanding of why these approaches are appealing, making sure that sufficient options exist, while not also offering so many as to be excessive to maintain.

[smp303]

Why can't the plugin functionality be part of core? Just asking as I am curious :)

[gomezcode]

I'd like to mirror the need for the ability to toggle on/off the Gutenberg editor. My particular situation is that one of my WordPress sites is built upon a theme which has a custom editor (eg: Avia Editor in the Enfold theme).

When Gutenberg is enabled, the workflow for our editors changes. They have to go to All Posts > or Pages > and click "Classic Editor" and then hit the button for the Advanced Layout Editor, which invokes the theme built-in Editor instead of simply hitting "Edit" on the page they want to edit, or from the preview page. We require this editor, because the look and feel of our site is standardized around the templates that we built with that editor.

While the process seems trivial to most, the workflow change for dozens of Editors would cause some support headaches.

My 2 cents.

[youknowriad]

I think the difference is "psychological" only. Having it in Core means we'll have it indefinitely which hurts Gutenberg adoption where having it as a plugin means we'll support it for some time (I think Matt said several years) and at some point we'd stop.

[rosswintle]

I don't know if this needs to be spun off into a separate issue or not, but I'd like to voice my support for @wpmark's idea of only enabling Gutenberg for new installs of WordPress 5.0, and to offer it as an option to people when upgrading (unless the Classic Editor plugin, or some other "disable" feature is used).

If you'd care to read it my rationale for this is given in a blog post I wrote and is a combination of the huge change in user interface for my clients, and the code changes that might be required to support Gutenberg properly (which in the case of my clients there may not be budget for).

It feels like Gutenberg will be great for people new to WordPress installing a new blog and getting going. And it will be great for people that upgrade and think "Yay - new editor - I'll have that please". But to others it will be a huge shock. And in some use cases GB may not be a good interface for editing a custom post type, or "blocks" may not be a good data model for the information being edited.

It also feels like the voices of developers and small business owners need to be heard on this topic. I know a lot of small WordPress development shops and this change is going to be painful for all of the reasons outlined in my blog post. I've not heard one developer or small agency say that auto-enabling GB for updated sites is a good idea. I've heard many recoiling at the idea.

This kind of WordPress user (and development shops like mine are big supporters of and proponents of WordPress, so we really hope you will listen) understands their users well, we know in-depth what we've built on WordPress and whether or not it will fit well into the GB user interface without modification, and we NEED the ability to manage this change on behalf of our clients.

I know we can install the Classic Editor plugin, and we may still need to do so to remove the possibility that our clients enabling GB themselves. And if GB turns out to be optional for upgraded sites it would naturally involve having code to disable it in core. So that would make @smp303 (and others that want a way to disable it in core) happy too!

I hope that the views of developers and small WordPress businesses like mine will be heard as the plan to merge into core is produced. Our livelihoods may be affected by this change and some people feel like this change is being forced upon them too quickly. Please give us more options for managing the transition, and consider that GB isn't going to be the right thing for everyone when it is first added to core.

[lukecav]

A filter in WP core or a constant for wp-config.php, seems like two solid options to be able to have.

[dmje]

Echoing @rosswintle and his excellent blog post linked above: we're one of many, many agencies who use custom fields, metaboxes (ACF in particular) to give a really rich editing experience. "WordPress as platform" was the promise, and that's what we've all been doing for the last few years.

There has to be a way to enable Gutenberg for those who want it but not to enforce it for those that don't. I'm reasonably easy about whether this happens in code or via a plugin - actually, as someone who maintains 50+ WordPress sites using a management console, a bulk plugin install to disable Gutenberg would make more practical sense (if less geek sense), but meh, as long as it can be done. Even a settings option in the dashboard would be ok, IMO - a default of "Gutenberg: off" even better...

Ross' point about backward-fitting sites with Gutenberg is also valid. Virtually anyone who builds for clients knows that the vast majority spend their budget to launch and then don't have any budget after that. Retrofitting Gutenberg, re-training clients, a different interface - thinking anyone will pay for this apart from developers and business owners is fantasy land..

[NewJenk]

Just like to echo the sentiments of @smp303, @dmje and @rosswintle.

Being able to put a simple action in functions.php to disable Gutenberg seems like the simplest, most obvious thing to do.

I can't help but feel that the plugin approach has been taken to make it a little more difficult than it needs to be to bypass Gutenberg.

I know the core team have put loads of effort in to Gutenberg, but its success should be determined by its merits, not by curtailing the ability to avoid it. Moreover, think about WP devs having to develop for a whole new editor, learn react and still develop and maintain legacy stuff - the overhead is HUGE.

[robmcclel]

I would like to echo this as well - I would also like the option to disable the Gutenberg editor via code and not via plugin.

[ntwb]

See also this Trac ticket that was created, and now closed as wontfix: #WP43068

Per @dd32 in https://core.trac.wordpress.org/ticket/43068#comment:6

I don't think we'll be supporting a constant for this, and instead simply directing people towards the plugin and maybe an mu-plugin wrapper for it, simply because the existing plugin isn't just a switch, it's going to involve code that isn't in core being used.

WordPress has been trying to move away from constants, as they're very hard to change later down the track "Oh, I want Gutenberg why is it disabled? Oh, my random SEO plugin (or ex-developer) thought i wouldn't want it and forcibly disabled it, great.. now who can i get to fix this for me" (end-user)

I can see why some people would want to disable it, but I can't see any need for it to be done in such a manner.

I think we can safely close this as wontfix, that may change later (and we'll re-visit this then), but I don't expect it to.

[pento]

Thank you for the feedback, everyone. I understand there's some controversy to the decision to require the Classic Editor plugin for disabling the block editor entirely, so I'd like to chat about what the various options are.

Over the coming years, the "block" concept for managing site data will become the primary method for thinking about, laying out, interacting with, and editing data. The block editor coming in WordPress 5.0 is the first major step in that direction, the Gutenberg Customisation focus this year is the next step, along with the Gutenberg Theme.

Of course, not everyone will be 100% ready for the block editor when WordPress 5.0 ships. That's a practical reality that everyone is aware of, and we have no wish to leave people with no viable way to upgrade to WordPress 5.0. With that in mind, there are a few different ways to disable Gutenberg, depending on your particular use case.

If you register meta boxes that don't work with the block editor, you're able to easily mark that meta box as incompatible.

Similarly, there's discussion on adding a similar flag for CPTs (#2457), so that CPTs that don't require the block editor functionality can opt out of it.

These are the primary two long term use cases for disabling the block editor - situations where it doesn't work, or it doesn't fit the usage patterns.

With these things in mind, let's think about the next few years of how WordPress will potentially evolve (note that I'm very much gazing into a crystal ball here - things on this list won't necessarily happen in this order, timeframe, or even at all - it's just a potential scenario that will depend a lot on how the WordPress 5.0 release ends up going).

• The Customiser uses the block concept for everything. For 99% of new sites, the blocks are the only thing needed for creating entire sites. Block manipulation is how sites are built.
• New themes will evolve around building sites entirely from blocks. The standard WordPress user experience is built with blocks.
• At the same time, wp-admin will start to adopt the JavaScript-app interface that Gutenberg is bringing. Switching to the Classic Editor is still possible, of course, but it doesn't match the rest of the WordPress interface.

I'll reiterate that this is over the course of several years, there will be plugins like Classic Editor to restore the older interfaces, but it won't necessarily be possible for those interfaces to be maintained in Core. While it will be a reasonable option to disable the block editor in WordPress 5.0, you'd be doing a huge disservice to your clients if you got to WordPress 5.5 or 6.0, and were still using the Classic Editor. To pick one example, much as site layout best practices have evolved from table layouts, to several iterations of CSS layouts, and now grid layouts, WordPress development best practices evolve, too.

So, to get back to the original question, a single code-based option to disable the block editor isn't a viable long term solution, it can't expand to give appropriate options for future WordPress Core development, it really does a disservice to everyone here if we were to create this option. The Classic Editor plugin, however, can continue to evolve to fit into whatever paradigm the future brings. It gives a more relaxed environment where it can be developed specifically to meet the needs of the folks to require it, rather than needing to fit into the more general needs of the entire WordPress world.

[robmcclel]

The problem with the Gutenberg editor is not blocks or the concept of blocks - its that the editor itself is not a good one. It is, currently, many times more confusing than the existing editor - which, itself, is very far from perfect. And, as we get closer to go time (expected in April, I guess?) and people voice more and more concerns, the feedback is never "you're right, here's how we plan to address that" its just as you have done above "well, this is happening, so better get on board."

The interest in deactivating Gutenberg, at least my interest, is not the future of blocks vs widgets and the long term roadmap of the customizer - it's that the actual editor really sucks. I don't want to use it. My clients don't want to use. It is not a nice thing to use. And, the reason it is not very good, is the basic concept that every paragraph and piece of text is a "block" and we all hate that.

That is the reason we want to turn this off. Going to Gutenberg is, for many, a highly unpleasant experience and deeply troubling for both clients and development.

I don't care about the future roadmap. I care about losing my clients and my business and so far no one in the Gutenberg team seems to share that concern. What are we supposed to do when the core platform of our income is moving full steam ahead in a direction we don't want to go? And what are we supposed to do when our concerns are brushed aside in the name of "the future roadmap"?

I'm all for replacing widgets, inserts, and shortcodes into a universal block system. It think that's a good idea - I'm behind it. I like trying to give users more control over their site layout - why not?

I'm worried because the actual content creation tool is, currently, a steaming hot mess that not a single one of my clients (over 300) wants to use. They actually look at it in horror, and all of the nice little YouTube demos and videos and recorded WordPress talks are only showing them just how much they hate it.

They don't want to write in blocks! They don't want a block based editor! They all hate that - they want it to work like MS Word or Google Docs, because that's what they normally use to write stuff. That is what they want.

How can I give that to them when all WordPress wants to do is shove blocks down their throats?

The only alternative I have is to turn off Gutenberg. So, I want a reliable method of doing so. At the very least until this development train comes to its senses and creates something that is actually worth using - not as a block mechanism but as an actual damn editor.

I need a functional editor where the text is NOT based on blocks. When will Gutenberg provide that? Answer that and I'll tell you we no longer need a way to disable Gutenberg. Until then, have some actual empathy and care for the millions of WordPress users and businesses and provide a way to turn off Gutenberg that we can have faith in - that means code, not another plugin.

There needs to be a way to deactivate Gutenberg from the code level. Please do us that courtesy. Don't give another platitude answer - just give us a way to turn the damn thing off if it all goes sideways.

[markkap]

@pento, For years there was an easy option per user to turn off tinymce, and while a lot of development was tinymce specific no one had suggested that the option will be removed.

I didn't hear yet anyone suggesting to remove that option as part of gutenberg, and it does not make much sense to me that you will be able to go from gutenberg to text based editor without being able to keep using the current tinymce one. Keeping in mind that tinymce will still have to be supported as part of the text widget and wp_editor API, it do not make any development or UI sense to force people to install plugins to expose actively maintained core APIs.

Even if for whatever reason you do not want to change that user option to include gutenberg related setting, from a software development POV as long as you are going to support turning off gutenberg, it should be an API which is part of gutenberg and maintained as part of its development. As the importer plugin shows, even "core" plugins get out of sync and become unusable mainly because they are not part of the actual core development.

Refusing to maintain such an API as part of core means that there is no commitment to let people disabling gutenberg even in 5.1, a release which will probably be in 2018. You can not expect people to be able to make any medium term plans with such uncertainty.

[rosswintle]

@pento Thanks for the long and detailed response. I don't think this is just an issue about HOW to disable Gutenberg, but also about if and how it will be enabled by default. I think your answer covers both but it also troubles me.

I for one am very surprised that the implication both here and elsewhere is that the classic editor will be removed from WP and the "Classic Editor" plugin will add it back in. Is this a correct understanding? This seems like a really bad idea to me but I can't articulate why right now.

@markkap also makes a good point about the text widget and wp_editor API - how will these be kept in core if TinyMCE is removed?

And editing meta_box/CPT code to prevent Gutenberg loading is fine, but actually, I'm a lone freelancer that's probably build around 60-80 sites for clients. I'm not about to go editing all that code and many of those small clients won't want to pay me to do so. I would MUCH prefer this to be opt-in than opt-out: Gutenberg should be turned on when I declare support for it. The default here is, again, backwards. You are forcing people to make a change to prevent things from changing/breaking (I'm happy to raise a separate issue for this if needed).

you'd be doing a huge disservice to your clients if you got to WordPress 5.5 or 6.0, and were still using the Classic Editor

(Also using my crystal ball) I don't think I necessarily agree with this. I think it's impossible to say that Gutenberg and blocks will be a better editing experience for all use cases going forward.

I also find myself being a bit confused here about the nature of "blocks". This is probably a terminology thing, but it implies that one or more of the following are true:

• There's a paradigm shift that I'm struggling to make or I've mis-understood something
• The new paradigm isn't being communicated very well
• The ways in which WordPress is used by developers like myself to build content management tools for clients are not well understood
• The ways in which WordPress is used by developers like myself to build content management tools for clients are well understood and are being ignored

You have said:

Over the coming years, the "block" concept for managing site data will become the primary method for thinking about, laying out, interacting with, and editing data.

This scares me a little and I'll come back to it.

The Gutenberg page at https://wordpress.org/gutenberg doesn't seem to agree with this description. It calls blocks "content blocks" and explains that:

[blocks] are a unified way to style content

Note: I'm a back-end developer and I think very much in terms of data: what data exists in a system, what properties data items have, how data items are related and how data is queried and manipulated.

My understanding is that "blocks" are sections of content that can be used to comprise a post, page, whatever. They are primarily stored inside post content in the database using HTML comments for backwards compatibility, but you can also configure blocks to save data to other places like post_meta. (Note: this feels like a hack to keep people like me happy with putting meta data into blocks - it does not feel like a well-thought-out design decision about the nature of blocks)

Your implication in what you say is that blocks are to drive everything. They are how "site data" will be managed. This, and other things you've said, imply that blocks are not just sections of content, but some kind of user-interface device that can be hooked up to anything: site options, customisations, meta data about posts, widgets, menus, user profile fields, everything.

So I think we need clarification around the nature of a "block".

If what you're implying is correct then I think this represents a fundamental mis-understanding of how WordPress is used by people like myself. And I think this approach will be what pushes me to hop off the WordPress train and find an alternative CMS for some projects. WordPress will be for blogs and magazines, but many of the opportunities presented by custom post types will go away.

Meta-data in WordPress is as described: data about data. It's information that gives additional properties to items of content. Meta data is NOT content. And, IMO, is not suited to being placed in "blocks" as I understand them Some of the post types I create have no content other than a title: they only have properties/fields/meta data.

If what you describe here is true then I wonder why isn't post status a block? Why aren't categories and tags blocks? Why isn't the excerpt a block?

I, personally, don't think that these are "blocks" as I understand them because they are not content, they are information about the content. Their location in the UI is important. How the user interacts with these bits of information is important.

Some of the post_meta that I create is the same.

I (think I will) like Gutenberg and blocks for creating posts and pages. But either I mis-understand "blocks", or the project has mis-understood how people use data that will not be suited to "blocks".

I'm happy to have this clarified and I'm willing to be persuaded. But having blocks as "the primary method for thinking about, laying out, interacting with, and editing data" doesn't not seem to fit with the things I build in WordPress.

And, pulling this back to the primary issue here, this is why I don't believe the classic editor should be removed from core, and it's why I don't want my users to automatically have Gutenberg turned on when I upgrade them to v5.0.

[wpmark]

@rosswintle you have summed that up absolutely perfectly in every way and pretty much every developer I have spoken to feels the same way. I just hope that someone is listening to these concerns and we can find a solution for everyone.

[joffff]

Adding my +1 for making Gutenberg the default editing experience for new installs only.

As @rosswintle has said, there are hundreds of thousands of WP developers with clients that will not be interested in paying for time to revert to the Classic Editor. Let existing sites continue as-is (of course make the new editor available but also switch back if it's not as they expected) and roll Gutenberg out with new installs.

Think of all the small business owners with WP sites. Sites that were developed years ago that are just ticking along nicely with no new development. Suddenly these users are having Gutenberg forced upon them and not only do they need to learn a new interface (these users may not be very tech-savvy in the first place and Gutenberg may or may not be more intuitive to them) but it might prevent them from editing their site content.

There's also the reputation of WordPress to consider, where we're still trying to shake off the opinion that WP is full of security vulnerabilities. @wpmark and I even had a random conversation with someone earlier in the week where one of the first things they mentioned once they knew we developed with WordPress was "how do you secure your sites".
Is there a risk that users might find their sites broken or difficult to work with? How will that affect WP's reputation in years to come?

I definitely think new sites should be Gutenberg-enabled, and this can be a big feature that is shouted from rooftops during the 5-minute install, but please let legacy sites continue as-is.

[polevaultweb]

I didn't want the question of only turning Gutenberg on for new installs to get lost in this also valid concern about ease of disabling. Here's a specific issue for it #4423

Please add your thoughts, votes and feedback to that one. @joffff @wpmark @rosswintle @markkap @dmje

[benfurfie]

Spot on @rosswintle.

Gutenberg should be turned on when I declare support for it. The default here is, again, backwards. You are forcing people to make a change to prevent things from changing/breaking (I'm happy to raise a separate issue for this if needed).

Couldn't agree with this more if I tried. I don't think the guys and girls pushing Gutenberg understand this.

Just to add to what Ross has said from an enterprise angle (he covered the small freelancer side of things well): the sites I manage for a multinational PLC are like oil tankers. Fundamental changes like this take a very long time to be implemented. Through testing has to be conducted and even then, they need to be slotted into a weekly release schedule, which is part of a detailed code review and approval process.

This is going to cause a massive headache for myself and my team. In fact, chances are, we'll probably end up staying on 4.9.x until we've been able to throughly check Gutenberg's impact after the final RC for 5.0.0 has been released. This could take weeks or even months. This is not a quick fix.

I also find myself being a bit confused here about the nature of "blocks". This is probably a terminology thing, but it implies that one or more of the following are true:

• There's a paradigm shift that I'm struggling to make or I've mis-understood something.
• The new paradigm isn't being communicated very well.
• The ways in which WordPress is used by developers like myself to build content management tools for clients are not well understood.
• The ways in which WordPress is used by developers like myself to build content management tools for clients are well understood and are being ignored.

I absolutely feel that it's the latter. I have no doubt that those on the Gutenberg team know and understand how most professional developers build sites using WordPress.

However, that approach is wholey incompatible moving WordPress towards a site-builder approach, which Automattic needs it to for WordPress.com to continue competing against the likes of Squarespace, Wix et al.

WordPress can't be a site builder and a professional CMS at the same time. It just can't be done. It's walked a fine line between the two, allowing users to move it in either direction through plugins. (Towards a site building using Beaver Builder, Divi et al and towards a professional CMS with plugins like ACF and CMB). However, now it's clear that the CMS is moving firmly in the direction of site builders. Sites that use custom fields be damned.

Finally, your point about blocks and the database is spot on.

I think it's indicitive of many problems that the WordPress team should be tackling first before looking at things like Gutenberg:

• Updating the min-version of PHP
• Implementing native semantic data (through custom fields) and amending the DB structure to account for it.

As a final note, the guys over at Statamic have demonstrated how this should have been handled with their new Bard fieldtype. An optional editor interface that solves the same issues as Gutenberg, but in a much more intelligent and less disruptive way.

[eirichmond]

There is no point me iterating over my opinions, they have already been voiced above. I'm in agreement with the general consensus - it should be a considered option to enable Gutenberg not mandatory in the move from 4.x to 5.0.

As most developers here I service a number of clients, some very tech savvy, some not so but pushing them in this direction I'm guessing is only going to cause confusion for the majority.

In terms of anything that might break; from a client's perspective, they have already created and spent a budget for the solution provided, they are not going to appreciate they may need another budget for support or to fix issues caused by something not of their or my making.

Between the developer/designer or provider of the carefully considered solution given to them, the client and provider, should choose when to enable such a major change not have to comply with something mandatory.

[benfurfie]

Just to throw it out there. Although WordPress doesn't strictly follow the semantic versioning approach, version 5.0.0 is a breaking change.

If Automattic are unwilling to change its strategy concerning Gutenberg – and let's be honest, that would be the right thing to do – then the only other option is making 4.9 a LTS version.

That way, security patches could be applied to 4.9 for the next – say – 5 years. That's plenty of time for website developers to migrate their sites to Gutenberg or away from WordPress entirely (which I suspect is going to be the most popular option).

[pento]

Well, everyone sure does like writing long comments here. 😉 It's evening for me, so I won't be addressing everything, but I would like to touch on a few issues.

I for one am very surprised that the implication both here and elsewhere is that the classic editor will be removed from WP and the "Classic Editor" plugin will add it back in. Is this a correct understanding?

That's not correct. I mentioned in my previous comment that meta boxes and CPTs can fall back to the Classic Editor automatically - they wouldn't be able to do that if the Classic Editor code was removed. 🙂

TinyMCE is used by Gutenberg to power the editable text blocks - that's not going anywhere. Functions like wp_editor() can be relatively easily maintained in Core without needing to be moved off to a plugin - I would expect them to continue to work indefinitely.

Your implication in what you say is that blocks are to drive everything. They are how "site data" will be managed. This, and other things you've said, imply that blocks are not just sections of content, but some kind of user-interface device that can be hooked up to anything: site options, customisations, meta data about posts, widgets, menus, user profile fields, everything.

That's exactly what I'm saying. Well, meta data isn't a block, though it might inform how a block is used or displayed.

So I think we need clarification around the nature of a "block".

Sure. A block is a lump of HTML that fits together with other blocks. There are a bunch of APIs that make working with blocks nice and easy, but that's what it comes down to.

A block is not:

• A lump of HTML stored in post_content (though some blocks use that storage method).
• Static (though some blocks are).
• Dynamically generated (though some other blocks are).

@rosswintle, you mentioned meta data a few times, and I'd like to clarify what you're referring to there. Could you give me some examples of what you consider to be meta data?

If what you describe here is true then I wonder why isn't post status a block? Why aren't categories and tags blocks? Why isn't the excerpt a block?

[eirichmond]

Just a suggestion and I'm not sure if it is or should be a theme option but why not under add_theme_support() as most newly developed functionality has been in the past?

[pento]

That way, security patches could be applied to 4.9 for the next – say – 5 years.

Given that WordPress 3.7 was released a little over 3 years ago, and its most recent security release was 6 weeks ago, I think it's reasonable to assume that WordPress 4.9 will be getting security patches for a long time to come.

[JAW-Dev]

Well, I hope they at least release the plugin before the update so we can have it installed and activated so the user experience isn't disrupted.

I mean the meta box support is still broken in 2.0 and I'm not really confident it'll ever work at this point.

[rosswintle]

The plugin already exists: https://wordpress.org/plugins/classic-editor/

[bobbingwide]

To answer @smp303's original question.

1. In wp-config.php add

define( 'ENABLE_GUTENBERG', false );

2. In a file called my-hacks.php in the mu-plugins folder, which you may have to create code

<?php // (C) Bobbing Wide 2015-2018
if ( defined( "ENABLE_GUTENBERG" ) && !ENABLE_GUTENBERG ) {
	add_filter( 'gutenberg_can_edit_post_type', '__return_false' ); 
}	

props @tomjn @wpmark

You can do this today without having Gutenberg or the classic-editor installed.
But be warned that the filter name may change when the code is merged into core.
... at which point someone will be writing docs, and then you can add another line.

Notes: The file called my-hacks.php was introduced in 2003 and deprecated in 200x.
But there's nothing stopping you from implementing it as a must use plugin in mu-plugins.

If you want to see how hard it is to remove deprecated code, including the option field associated with it
see WordPress TRAC #33741 - Remove references to my-hacks.php and the hack_file option

[bobbingwide]

Even easier...in wp-config.php

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

[colomet]

I think the concept of block is wrong. In my opinion, a block should be a post. So if we need several content in a post, we have to be able to have child posts. Like twitter, where a page is made by many independent tweets.

Inside of a post we just need a text editor.

We have not budget to do an update of all of our pages. If wp do not offer long term compatibility, many of use we will just change in the future to a more stable community as the door would be open to new companies.

Now wordpress is cool because of the community. 5.0 means to start from 0. So, as any other framework.

Two lines of development could be a good idea instead of deactivating or not. WP normal and WP Gutenberg. At least for the next 5 years. Then, Gutenberg would have time to be stable and to have a community too, so as WP.

[TomDesign]

It would be nice if many of you as developers have a problem why not just get in and go on
Github with a ticket that proposes a working method to solve your problem rather then just writing endless why you cannot help build a solution with the current Gutenberg project.

Bring your programming skills to helping solve the problem.

I am a visual designer and currently making plans to help two of my clients with moving the editing processes to Gutenberg and I am current designing and building out a new site for a client with a twenty plus year old site they cannot maintain.

Jump in and help move WordPress.org forward as site building tool.

[markkap]

@TomDesign have you even tried to read the discussion? GB team do not want the functionality as part of the plugin so unless in "Bring your programming skills to helping solve the problem" you mean that someone should hack their accounts to add a code they do not want, I am not sure how writing code is even remotely relevant here.

[bobbingwide]

@TomDesign I raised the requirement to have a Viable Migration Plan in #4981
I pointed out that it will be a lot of work. And it's something that I feel is necessary.

I'm sure there are quite a few developers would like to be able to use our programming skills to ensure a smooth migration. But we don't want to waste our time developing something that will get rejected out of hand. In my opinion, migration deserves a Project in its own right, with each requirement evaluated logically. It's important enough to have a well documented proposal that will get us there in the long term.

Simon's original request was a short term fix to a long term problem.
I believe the content migration process will last years.

[unCommonsTeam]

Hi guys,
Reading the comments I think this is the right place to share a good plugin about Gutenberg.
I would like to present you a free plugin that allows you to manage the Gutenberg editor.
It's called Gutenberg Manager and allows you to enable / disable the editor in the various post types (pages and posts included). It has more features but I leave them to you.

We have read tons of posts of people complaining about the future implementation of Gutenberg within the core in WP 5.0 and this has led us to find a simple solution.

Gutenberg Manager solves this problem and allows for example to continue using Elementor, Visual Composer, Siteorigin Builder or Cornerstone without any problem even after WP 5.0.
From the first user feedback on WP.org the plugin seems to be apreciated :)

For this reason I would like to introduce you to Gutenberg Manager -> https://wordpress.org/plugins/manager-for-gutenberg/

The plugin can be used by developers in their own themes and plugins thanks to some useful hooks. There is an hook to HIDE the plugin option panel so the final user will not see it in WP backend (great feature for the devs that want to include Gutenberg Manager in their projects).

We are also making arrangements with the teams of most famous Builders to activate partnerships and collaborations. In this way we hope to make the transition to Gutenberg a little less traumatic!

Thank you all for your attention,
Good job.

[wpmark]

@unCommonsTeam can I ask how you are disabling the Gutenberg editor in the plugin, when for example that options is selected in your settings screen?

[unCommonsTeam]

Sure @wpmark,

take a look on the row 79 -> https://github.com/unCommonsTeam/gutenberg-manager/blob/master/inc/core.php

Best

[wpmark]

@unCommonsTeam thanks for coming back to me. I am probably wrong here, but having looks it looks like the plugin is just removing all the things added by the Gutenberg plugin. This is something I suggested above by using:

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

However was informed by @pento that was not a robust solution as it does put an editor back in to WordPress. See #4409 (comment)

[unCommonsTeam]

@wpmark yes that function remove all the things added by Gutenberg plugin but the function is only called in specific backend pages not for all backend.. For example if you decide to disable Gutenberg editor in the Pages but you want to use it in the Posts.. So I think it's acceptable.

Best

[wpmark]

@unCommonsTeam it looks like a great plugin, but I think it would suffer from the same issues as my solution, in that it really needs to add an editor back into WordPress.

From what @pento was saying was that removing the Gutenberg additions, it only states that the block editor is not wanted, but you should replace that with something - which is what the classic editor plugin does.

As @pento stated:

This filter just means "don't load the block editor", it doesn't mean "use the classic editor". It works for the moment, but is not guaranteed to work in the future.

Therefore I think (and I stand to be corrected of course) that your plugin is doing the same (but of course much better and with lots of cool options for flexibility etc) than my attempt above.

Another thing I was thinking about is, is the name Gutenberg going to be hanging around when the project gets merged into core, or for example are those function (e.g. gutenberg_init) going to be renamed to (for example) block_editor_init.

[unCommonsTeam]

@wpmark you're right. We hope that in WP 5 they will leave the classic editor there. However we could try to add an option to include the classic editor via plugin. If WP's dev team will decide to remove the classic editor, we think our plugin will become really popular :)

About the gutenberg naming you're right, probably we will have to fix our plugin replacing the names of the hooks.

Moreover our plugin will offer other features based on Gutenberg editor (enable/disable specific blocks, new blocks, etc). So we think it will be useful for the people that use the Gutenberg editor too.

Cheers

[codebard]

This may be a good idea that will settle almost all the stampede and debate:

If Gutenberg comes default disabled in the core, along with classic editor still maintained, this could save the ~$1 billion WordPress theme and plugin market and vast swath of internet a lot of trouble, monetary loss, support incidents, along with saving WP a lot of prestige and trust loss as a platform.

Gutenberg, though a more modern editor, seems to be crafted for the necessities of WordPress.com and similar outlets which provide blogging/hosting services using WordPress. This is all good and well. However it shouldnt lead to a shock and a kick in the balls to the rest of the ecosystem. A vast swath of internet, people's websites, their livelihood are going to be affected with the current direction.

WordPress.com can have Gutenberg default on, whereas WP comes with it being default off, hence providing the best of worlds to entire ecosystem.

[WebTrooper]

I have to agree with codebard, that gutenberg be disabled by default and the classic editor continue to be maintained. I currently have automatic updates disabled for exactly this reason -- I don't want bloggers on my multisite network to suddenly be presented with this "page builder" type of editor, and I certainly don't want the classic editor to be completely replaced with gutenberg.

At the very least, we should be able to disable gutenberg with a define statement such as define('DISABLE_GUTENBERG', true); One big issue with having a plugin to disable gutenberg is that we would then be dependent on the developer to maintain and update the plugin, when needed. What would we do during the days or weeks when the plugin stops working because the developer is on vacation or otherwise too busy to update the plugin. There is also the issue that people using the plugin will have to update the plugin on their end.

It seems forcing gutenberg onto us and then finding workarounds to disable it as an afterthought is a really backward way of doing things. Please make gutenberg disabled by default. Many of us who just want a simple blog are finding it harder and harder to use wordpress as it seems to be evolving into a website builder.

Another note, in the case of multisite networks, the network admin should be able to decide if gutenberg should be made available across the network.

[chrisvanpatten]

@WebTrooper the Classic Editor plugin is maintained by the WordPress developer team (the same folks who maintain Core) and Gutenberg Ramp is maintained by Automattic, so both should be immune to the "developer on vacation" or "too busy" factors.

[tomjn]

Note that VIP has a commitment to the Gutenberg Ramp plugin, which is in use on our clients site and our own sites. Being on vacation or too busy if things broke could mean broken customer sites which is the last thing VIP wants.

I would also note that these plugins can be forked, Automattic and the authors and of the classic editor plugin don't possess any secret knowledge that enabled them to build those plugins, nor are they technically large or complex. There are hundreds of agencies across the world with developers capable of maintaining either plugin.

---

As an aside, a lot of people argue for the disabling of gutenberg by default, but I've noticed regardless of the merits of those arguments, they all fail to say when exactly GB should be on by default. The logical conclusion is a perpetual classic editor situation.

It's 2934, the galactic empire has jumped into the system, 300 battle cruisers. The local planetary news network has fired up the classic editor to pen a report for the local denizens. Nobody told them about Gutenberg before they started building the site

[rosswintle]

I’ve always suggested it be on by default for NEW installs.

But for existing installs I’d suggest a user-led approach, allowing people to opt in to Gutenberg, try it, keep it if they like it and revert to classic editor if they don’t. WordPress could then collect stats and feedback if/when people switch back to help with development and documentation for the change.

When some kind of critical mass of active sites with it on is reached then you could enable it by default. And no, I’m not going to pick a number out of the air. But we could measure usage and act appropriately.

Alternatively, April 12th 2020 will do. 😉

This is happening for old PHP versions, right? WordPress has been tireless in its backwards compatibility of PHP 5.2 because people still use it, in many cases probably without knowing or caring. WordPress is carefully analysing stats; putting a lot of effort into coordinating with hosts and so on; and gently guiding people on an upgrade path. And presumably the project will, at some point, act on the usage data it has to make a decision.

Yet with a whole new user interface for editing which users do know and care about the approach is to force it upon them?

As much as I’m actually starting to now advocate for Gutenberg in some cases, I really hope the merge proposal takes on board the concerns of people like me who manage lots of sites for end users, many of whom have poor IT skills, are not confident with technology, and will be confused and disoriented by Gutenberg.

[codebard]

I think Gutenberg should be off for NEW installs as well, due to the below important reasons:

• There exists an almost infinite amount of tutorials, resources, how-tos and whatever you can imagine, all based on the existing editor. These make entry of people to WordPress VERY easy.

• This ease of entry is very important, since because they start so easily like this, people have an understanding that 'WordPress is easy', and readily have a warm perception of the platform, a more accepting and confident attitude towards learning it more

• All these combine into perception of 'WordPress just works', and they comfortably recommend it to their peers. This is how we were able to grow to encompass 30% of internet.

• Consistency of information is important. And there is no way that each and every one of the resources on internet will be updated to reflect gutenberg, even into the future. It will create a lot of confusion. And most unfortunately, the reaction of ordinary user will be 'i installed it, but it DOESNT WORK', just because s/he cant find how to do things and things dont look the same as the tutorial he or she uses. Make no mistake, no amount of update effort will clear this confusion regarding resources, tutorials and so on.

Therefore, Gutenberg should be optional and toggle-able to keep 'backwards compatibility' not only in terms of themes, existing page-builder built content plugins etc, but also in terms of the resources we have online. A platform is not 'so easy' and you cant recommend it to people saying that 'just install it and google...' when google brings up many differing obsolete and up-to-date resources mixed. And if you have any seo experience, you know that it will be...

With Gutenberg, we can tap the allegedly rising 'site builder' market (wix, squarespace etc), and the potential 'easy blogging' market (a la medium etc). But, if we break even a fraction of 30% of internet, or the ~$1 billion themes/plugins market while doing so, it will be a massive, massive kick in the balls which we may not recover from in a decade.

[tomjn]

You can't install a classic PHP plugin, so the comparison to PHP isn't relevant, those are millions of sites that would be guaranteed to break, with no WP based solution that would solve that, hence the careful analysis. Also keep in mind the next release has a prompt that installs the classic plugin, users aren't just being prompted to install the Gutenberg plugin.

Either way, this issue was closed, decisions were made. A closed issue is a poor place to try and change an approach being planned elsewhere.

But keep in mind that Gutenberg is toggle-able, there are plugins for both enabling and disabling it. It's been years since GB was started, with plenty of time to test so far, time to train clients, time to install the classic editor plugin, etc. This isn't some newfangled thing being forced on people overnight

[rosswintle]

I've noticed regardless of the merits of those arguments, they all fail to say when exactly GB should be on by default.

And, it seems, even if the people making those arguments had made some suggestion about when this should happen, it would be dismissed anyway. So why bring it up?

I know how closed tickets work. You made a quite-sarcastic aside here. So I tried to offer something constructive in response.

[polevaultweb]

@tomjn I'll echo @rosswintle here by saying yes we have suggested it should be on only for new installs by default - #4423. This is another closed issue, closed without real any discussion of the point.

[smp303]

They are not willing to listen, there is a plugin, blah blah blah, this is closed. Move along nothing to see here. Its all about .com no one cares about .org there is no money for Automatic there.

[tomjn]

@smp303 can you please identify who they are?

@rosswintle No sarcasm was intended, Gutenberg 0.1.0 was released 14 months ago, and the only way to avoid sites running on 5.2 from breaking is to support them and try to get them to upgrade. Sites who's Post edit screen would break with Gutenberg can install the classic editor plugin without requiring server level changes, the comparison is not fair

[ghost]

They are not willing to listen, there is a plugin, blah blah blah, this is closed. Move along nothing to see here. Its all about .com no one cares about .org there is no money for Automatic there.

I have to agree. Whether here or in WordPress support forum, seems they seemingly don't care at all even though many people in the community against this. Since WordPress is an open source, I would like to suggest anyone create a petition regarding this matter. I personally believe and suggest that GB should be a plugin like Jetpack rather than merging it into the core.

On the side note: @karmatosed Since you unable to reply and answer my question at one of the comments in WordPress forum regarding Gutenberg, I wonder why my comment suddenly disappear. Nice move!

[pento]

This thread has taken a turn from discussing why there isn't a code-based option to disable Gutenberg, into implied or outright personal attacks from sockpuppet accounts.

I appreciate that some people feel quite passionate about this topic, and it's unfortunate that this thread has gone this way, but the decision isn't going to change.

The Classic Editor plugin is the option for reverting to the classic editor across an entire site. It's being advertised prominently in the upcoming WordPress 4.9.8 release as an option to install now, in preparation for WordPress 5.0.

If you're a site builder who wishes to opt your clients out of the block editor, installing the Classic Editor plugin (and contributing with bug reports or fixes) is the best long term solution to ensure the classic editor will continue to be available.

For metaboxes, it's already possible to opt-out of the block editor, this API will be merged into Core. For CPTs, the gutenberg_can_edit_post_type filter will be renamed when it's merged (probably to block_editor_can_edit_post_type, or something of that nature), but will also be available as a code-based option.

To avoid this thread devolving further, I'm going to lock it.

Everyone involved in this discussion is absolutely welcome to continue participating in getting Gutenberg ready for WordPress 5.0, but please be mindful that personal attacks are absolutely not welcome, and will result in issues being locked, or accounts being banned.