Gutenberg: A way to disable Gutenberg editor in code?

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/

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

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.

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

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.

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.

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

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.

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.

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.

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

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..

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.

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.

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.

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.

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.

@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.

@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.

@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.

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.

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 https://github.com/WordPress/gutenberg/issues/4423

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

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.

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.

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).

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?

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?

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.

@eirichmond: add_theme_support() might be needed for the Gutenberg Customisation focus, but most themes will support block editor-based content without any modifications.

add_theme_support() might be needed for the Gutenberg Customisation focus, but most themes will support block editor-based content without any modifications

@pento What exactly is the Gutenberg Customisation focus please? What does that mean? You mention _most_ themes will support block based content, can you indicate therefore why a theme would not support it?

I see themes with sidebars not supporting certain blocks because the block indicates that it is full width e.g. cover image.

What exactly is the Gutenberg Customisation focus please? What does that mean?

Matt spoke about it in the State of the Word - the three focuses for this year are:

• Gutenberg editor
• Gutenberg customisation
• Gutenberg theme

Gutenberg editor is the thing coming in WordPress 5.0. Gutenberg customisation is just starting to get underway, and is looking at site customisation, and how that works in the block paradigm. The Gutenberg theme will be this year's default theme, and will likely get underway later in the year.

can you indicate therefore why a theme would not support it?

Hopefully, all themes will just work. 🙂 Some blocks do have some CSS associated with them (cover images are a good example there), so there's the possibility of something not looking exactly right. There's nothing that would cause a theme to stop working, though.

Can I remind people that Gutenberg is not an Automattic project, lets not devalue the efforts and work of non-Automatticians who contribute

I'm also still unclear as to why a plugin is unsufficient, the arguments I've seen all argue that people don't like Gutenberg, or that they have a workflow already setup, all issues that have been mentioned before, and all fixed by installing and enabling the classic editor plugin.

Keep in mind that there is precedent too in the links plugin.

But anyway, lets be constructive:

I upgraded to WP 5.0 and Gutenberg replaced my Custom Editor/I don't like it/I need more time with clients

What do I do?

Install the classic editor plugin and enable it, problem solved. Now Gutenberg is replaced with the classic editor we have in 4.9

Downsides?

You won't get any of the newer Gutenberg features, and new features in the future might not make sense in the classic editor. E.g. if row and column blocks arrived in 5.1, I don't see how that makes sense in the classic editor

I have a lot of clients sites, I'm not installing and activating on every site, what if a client deactivates?

Use it as an MU plugin:

• Put the plugin folder in wp-content/mu-plugins
• Put a file in your mu-plugins folder that contains the following:

<?php
require( 'classic-editor/classic-editor.php' );

Now the plugin is always loaded, and can't be deactivated. No additional steps other than placing the files are required. You can then upload the file and folder to every site once and not have to worry about it again.

Lessons From The Classic Editor Plugin

There are a lot of helpful functions in this plugin for things such as detecting if Gutenberg is activated, and the bulk of it is actually removing hooks and replacing them.

It even adds a settings area with an option to opt in to the 'classic editor links' so that rather than replacing Gutenberg, you get what you see with the gutenberg plugin activated of the 'classic editor' link in the posts screen, so that gives you 3 not 2 options.

I strongly recommend people actually take a look at the plugin, test it out, and see how it's built.

Remember, we're a community, not the subjects of an Automattic product team. If it breaks, we have a whole WP release cycle during which to test it and fix it. I see plenty of stakeholders in this thread who have the technical skill to fix the plugin and then some. If it's really that big of a deal then I'm sure somebody will step up, just as the people working on core stepped up

@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?

@pento Sure:

Country example:

A "Country" post type that has a name (title), description (content), and then:

• population
• URL of flag image
• ranking (and other factors, possibly encoded in some way)
• related "communities" (relationships to posts of another type)

See: http://peoplesunderthreat.org

Real Estate example:

A "property" type that has:

• price
• type
• number of rooms
• date of construction
  etc.

Event example:

An "event" type that has:

• date
• time
• recurrence details
• location
  etc

There are many.

Having enabled and played with it a bit I have some major concerns... I will concentrate on the main one for now:

WooCommerce completely breaks... like its not even there when editing a product. And I imagine many more plugins will completely break as well. So what is the plan to help the community be compatible? And how long will we get?

@tomjn

the arguments I've seen all argue that people don't like Gutenberg, or that they have a workflow already setup

"don't like" is possibly the wrong term. I think people are making good arguments for Gutenberg not being suitable for many of WordPress's use cases. It's not a case of preference or taste, it's a case of suitability.

And developers just want options for doing this. I can toggle other major features like debugging, the code editors, multisite, auto-updates and post revisions in wp-config.php. Some features get enabled only by themes that support them using add_theme_support. Why can't we have in-code options to toggle Gutenberg in the same kind of way so that developers can use a workflow that suits them for such a major change?

One of the problems here is that developers (not me necessarily, but others) don't feel they are being listened to as they express concerns about Gutenberg. Adding this as a token gesture to help them out would help you get them on side a bit more. Even if for some philosophical reason of your own you don't agree it's the right thing to do, see it as an olive branch that can be offered to developers that aren't happy.

Keep in mind that there is precedent too in the links plugin.

The links plugin is a bad example here. It preserved existing functionality in core if you were using it and only removed the functionality for new installs (or if you weren't using it).

I LIKE this precedent.

This is what is being argued for in #4423

The thing that really gets me is that the core developers and Matt are assuming that the whole world is just going to completely adopt the "Blocks" concept and the Gutenberg editor without question. I guess it's all well and good but this "our way or the high way" approach they are using with Gutenberg is not only not user-friendly but it can seriously impact the state of WordPress as a whole.

There have been a lot of really great ideas throughout the ages that just didn't stick because they simply didn't get adopted by the masses. Betamax was a far superior format but it just did stick and VHS won. What if Gutenberg and blocks just don't stick? What will happen to WordPress then?

Then there's the trust factor. The far majority of WordPress users don't even understand what WordPress is. They just use it because of the brand WordPress is popular, and no matter how you look at it WordPress for most people is just a brand. Brands live and die by consumer trust.

When the 5.0 update finally rolls out and a million of WordPress sites suddenly change this dramatically how are those end users, who don't follow anything about the WordPress world, are going to react?

Most of my clients are as one put it "Barely able to turn on a computer" or just want what they paid for to work as promised. These are the people who trusted WordPress to do what it promised to deliver. If one day that promise is broken because of totally new format for managing their site's content suddenly changes. Then their trust in WordPress will be broken and people WILL just up and drop something if they no longer trust it.

This, I believe, is where most of the concern that developers have is coming from. We build great custom WordPress sites that work exactly who our clients want it and now it's all going to "broken" because of Gutenberg, and we are being given no option to prevent what could be a huge disaster.

The sole purpose of Gutenberg is to increase the WordPress Marke share, but it can very easily do just the opposite. It can actually drive people away from WordPress. Gutenberg could become the New Coke for WordPress, and WordPress isn't as big as Coke that it could just recover like Coke did. People will move on to something else and not look back.

You keep going on about "It would impact the future of Gutenberg adoption, blah, blah, blah", but it's really this simple. Either everyone will love it and the need to remove it either via code, or plugin, or whatever will become irrelevant, or Gutenberg will just become some weird feature that no one really uses like Press This.

As it stands now, the direction taken will either be that Gutenberg will be a success or WordPress as a whole could fail. We, the developers with the concerns, are only trying not to completely mess up a great tool for content management. We know better than anyone how our clients approach and use WordPress. The core devs and Matt are only looking at statistics and Market shares, and you know what that got us? The Ghostbusters reboot.

We really do want to work with you to make this happen, but it would be better if we can control how this is introduced to the world rather than forcing it on unsuspecting users. All we are asking for is a way for us to ease our clients into the new editor. It's really not a lot to ask for.

If Gutenberg is really going to be the innovation it promised to be, then great! Everyone hop on the Gutenberg train. If not, then we just ask for the option to not make it a huge disaster.

It's like you know it's not going to be well received and you want to make this happen so badly that you feel the only way it even possibly succeed is if it's just forced on everyone. It's like how politicians tell you a bold faced lie about how a tax bill that will benefit everyone to get it passed when in reality only the super rich will actually benefit from it.

It's like what the great Dr. Cox once said.

Help me to help you.
Help me to help you.
Help me to help you.
Help me to help you.

WooCommerce completely breaks... like its not even there when editing a product. And I imagine many more plugins will completely break as well. So what is the plan to help the community be compatible?

@smp303 Not the place to discuss this, but we're working on WooCommerce + Gutenberg compatibility right now. Keep an eye on the WooCommerce dev blog.

Perhaps a better analogy than "New Coke" is Windows 8.

That was a bold new vision for a more mobile computing mindset that backfired terribly because it changed too many base use assumptions. Yes, deep in the settings a user could reclaim much of their previous Windows experience, but unless they were up on the tech journals, users had no idea how to do that. The result was a catastrophe for Windows.

Gutenberg is heading very quickly down the same path. It is making a monstrous change, completely driven by the company and not the community, and it is leaving (I suppose, few details on this I can see) a fairly obscure path via an external plugin to going back to the traditional editor for those who don't like this new methodology.

I think that if Automattic/WordPress doesn't provide a means in the Settings to disable Gutenberg for the millions of casual WordPress users, they are going to deeply regret it. Gutenberg is a tremendous change. There is going to be a LOT of push back from users.

In this thread we are trying to warn you against this and advise that an external plugin is NOT going to be sufficient. You need to provide users with an "out" to Gutenberg, even if only to allow them a period of adjustment. If we can activate it into our existing Themes via code, we can possibly head off a disaster.

We are trying, desperately, to help here. An external plugin is NOT going to be enough. An option to revert to the Classic editor needs to be built in. Either do it as part of the release or provide a way for us to do that via code we can build into our themes.

From a logic standpoint, I'm trying to understand the philosophy of allowing devs to declare a metabox, within the add_meta_box() to NOT support Gutenberg which then causes the editor screen, anywhere that metabox is used, to show the "classic version" of the editor screen. Why then are some devs opposed to a constant defined in the wp-config.php file? If I can declare the Gutenberg stuff NOT be used in one area of code, why can't we declare it to be used in other areas like we currently set define statements?

Keep in mind that for a constant, the classic editor plugin would need to be bundled with WordPress, with a custom loader, and remain there in perpetuity. It could still be there in 10, 15 years time when whatever Gutenberg is replaced by comes along.

Even then, for those who need or want both editors, the plugin is still required anyway.

Don't forget that you can still install and setup the plugin in v4.9 in anticipation of Gutenberg arriving.

I think that if Automattic/WordPress doesn't provide

@robmcclel Automattic is not WordPress, WordPress.org != WordPress.com, one is an open source community, the other is a paid 3rd party service. Automattic doesn't release versions of WordPress, WordPress isn't an internal Automattic product, and neither is Gutenberg. There are a lot of non-Automattic contributors, release leads, etc doing things outside of Automattic.

"Even then, for those who need or want both editors, the plugin is still required anyway."

Actually, from what has been discussed here and elsewhere, if a custom post type or metabox declares that it does not support gutenberg, the editor screen automatically falls back... without the need for the "Classic Editor" plugin. This is one of the issues many have with the current state of the gutenberg project, there are many opinions/statements about what happens in certain situations and many times those statements/opinions differ from others.

Keep in mind that for a constant, the classic editor plugin would need to be bundled with WordPress, with a custom loader, and remain there in perpetuity.

@tomjn Wait! So are you saying that the whole meta box system is being stripped out of core?

No, I made no mention of metaboxes at all. But keep in mind that metaboxes exist in Gutenberg, to suggest they're being stripped out implies you've not tested Gutenberg, and ignores that a huge portion of the ecosystem relies on them. That would be a huge issue for wordcamp.org, wordpress.org etc

For reference, I am not a member of the Gutenberg team, I simply observe and apply common sense. Just because I work at Automattic doesn't mean I have special powers with Gutenberg. I have just as much a say as everybody else here, and if I wanted to change that I'd do it by contributing code and fixing issues, just as anybody else would.

@tomjn So then what you said doesn't make any sense to me. The "Classic Editor" is basically just an admin page with meta boxes on it and functionality for saving and such. That means that in order to be able to switch between Gutenberg and Classic there must be code built into core that would allow the two options and the all the code for the Classic functionality would remain in place.

So that would mean that the Classic plugin would be nothing but a way to trigger the switch. It seems like it would way easier to just build a constant or theme support type thing in core rather than having to build and maintain a plugin.

If everything for Classic is still in core why make a plugin just to activate it?

And so what if it has to remain in place. There's a ton of old and deprecated code already in WordPress core. A built-in Classic trigger wouldn't really make much difference at all in the grand scheme of things.

Let's not be disingenuous here Tom. Automattic is very much the driving force behind Gutenberg. No amount of 'but it isn't' coming from Automattic employees is going to change the fact that it's as obvious as the sun in the sky on a clear day.

Gutenberg is very much Matt's baby; as is Automattic. He's driven the project. He's been its biggest cheerleader.

Gutenberg has serious operational benefits for Automattic – namely giving it a product to level the playing feel with its biggest competitors. The same can not be said for the rest of the community.

Yes, many WordPress users make use of page builders through plugins. However, another large portion makes heavy use of custom fields through plugins like ACF and CMB (and its many forks). That part of the community has been crying out for years for the WordPress project to implement custom fields as a native feature.

However, it's failed to come to fruition because the funding hasn't been there to make it happen and every time it's brought up, it's suffered that oh-so-common open source problem of death-by-committee-debate.

Many other much more pressings issues have also suffered the same fate – such as bumping the min-PHP version to something that hasn't been end-of-life for over 7 years.

Those are just a handful of examples of things that should have been done years ago that still haven't been achieved because the project's primary funder hasn't supported it.

Automattic has thrown its weight behind Gutenberg – largely as a direct result of Matt being in the driving seat. A huge number of business hours have been dedicated to making it a reality. That translates to direct funding from the WordPress project's primary funder – Automattic.

I don’t see how this is relevant to the ticket?

@rosswintle This is very relevant. There are a lot of developers that want an easy way to choose to turn off Gutenberg. It's pretty obvious that the powers at don't want to give us this and to make it as inconvenient as possible to turn off Gutenberg.

The driving force behind this decision is the agenda of Matt and Automattic to increase their market share in the DIY website space. It's clear that the communities concerns are not being addressed because of Matt's and Automattic's influence over the project. This is where 100% of the communities frustration about Gutenberg is coming from.

Since the direction of the Gutenberg project being largely influenced by Matt and Automattic, it is relevant in this discussion as in all discussions about the project.

@tomjn

As of Gutenberg and this upcoming release, WordPress is a product of Automattic. To believe anything else is foolishness. .Com or .Org doesn't matter - the WordPress program is now a product of Automattic. Developers and such working on it now are no more than unpaid interns for Automattic.

The community wants Gutenberg as a plugin. Matt does not. Matt is the head of Automattic. Matt is the self appointed lead for this release. The people leading the development of Gutenberg are Automattic employees. Matt is forcing this. There is no other decision or debate - he has 51% of the vote and he is exercising it.

Don't kid yourself into thinking that WordPress is in any way shape or form a democratic or community product. It is Automattic's product now, however it was framed or marketed in the past, and they are now directing development focus, pace, and decisions.

@rosswintle , it's relevant to the ticket in that the community is asking for methods to turn off Gutenberg, and the Gutenberg team is responding that the plugin is going to the be the only way to do so, regardless of what the community as a very large whole is asking for.

Matt and Automattic are enforcing their authority on this. You might as well close this ticket and all others like it, because our voice is no longer relevant other than to convey sympathy and give us a place to vent. This ticket might as well not even exist.

Automattic is in charge of this, not the community. We need to face that and brace for impact, because this is happening and the only off ramp is the Classic Editor Plugin, and even that is a bit of charity. There will be nothing else.

I, personally, don't see how discussing who's making the decisions here helps move the issue forward. It's being developed as an open source project, and that means that you can have a voice, and I'd encourage people to use their voices constructively by helping develop options and a rationale for implementing this options.

The last post that was on the topic of the request being made was by @tomjn, followed up by some relevant questions from @wpstudio and @jawittdesigns

Keep in mind that for a constant, the classic editor plugin would need to be bundled with WordPress, with a custom loader, and remain there in perpetuity. It could still be there in 10, 15 years time when whatever Gutenberg is replaced by comes along.

Has a constant never been deprecated? (Genuine question) Looks like WPLANG might have been in v4.0? Is this a philosophical thing about the nature of constants? Would a filter be better? Would a filter be acceptable to @smp303 ?

Even then, for those who need or want both editors, the plugin is still required anyway.

Why is that?

@jawittdesigns Rightly asks:

If everything for Classic is still in core why make a plugin just to activate it? And so what if it has to remain in place. There's a ton of old and deprecated code already in WordPress core. A built-in Classic trigger wouldn't really make much difference at all in the grand scheme of things.

and @pento has pretty much ruled out removal of most of it:

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.

Finally:

Don't forget that you can still install and setup the plugin in v4.9 in anticipation of Gutenberg arriving.

We're all aware of this. We're trying to advocate for different methods that give options to developers that have different workflows.

@rosswintle – It's important to discuss it because ultimately knowing who is making the decisions sheds light on how likely our requests are to be accepted and how to phrase them to be as influential as possible.

However, yes, you're right in that this particular issue isn't the right place to discuss it. The refusal to budge on our requests is – however – indicative of the fact we're in a position of weakness compared to those driving the decisison.

Anyway. You make some good points in the last post. In fact, let me pick up on your quote:

Keep in mind that for a constant, the classic editor plugin would need to be bundled with WordPress, with a custom loader, and remain there in perpetuity. It could still be there in 10, 15 years time when whatever Gutenberg is replaced by comes along.

Are we to assume that once whatever replaces Gutenberg comes along that we won't be having the very same discussion again? WordPress' big USP has always been its dedication to backwards compatibility compared to its competition. That's worked well up until now. As we've all pointed out, Gutenberg breaks that. There's very little choice to stay with what we have now, bar what is effectively an official sanctioned hack.

The fact is, the code is all still in core. It is a much smarter and more eligant approach to allow the use of a constant – a single line of code – over a plugin that will need to be maintained separately that will end up being hundreds of lines of code.

The fact is, the code is all still in core. It is a much smarter and more eligant approach to allow the use of a constant – a single line of code – over a plugin that will need to be maintained separately that will end up being hundreds of lines of code.

This is my point entirely... Its not just a niche amount of people who will need this. Due to the fact that Gutenberg currently out right breaks a huge amount of plugins and themes etc etc... Another plugin is not a fix, its a hack, a dependancy. Not the correct way to fix an issue that could end up driving away a core of people who make the best WordPress sites out there.

The other option, which scares me the most, is that people just stick with 4.9 and don't upgrade sites. These then become unstable and open for hacking, and bring down the name of WordPress.

It just doesn't feel to me that enough thought has gone into this, and hence why a plugin is the end solution.

If TinyMCE is going to continue being "underneath" Gutenberg for certain blocks then why not approach the situation like this:
Pre-5.0 (aka current sites powered by WordPress) would have Gutenberg disabled by default with a filter/constant making it easy to enable Gutenberg.
5.0+ (aka WordPress sites installed on and after 5.0) would have Gutenberg enabled by default with a filter/constant making it easy to disable.

This way, anyone who wants to use Gutenberg has an easy time making that choice and anyone not ready or willing to use Gutenberg (for whatever reason) also has an easy time making that choice. It just appears at times that some want to make a dying stand on the Gutenberg hill when there appear to be more practical (in the short term) solutions.

@wpstudio This is pretty much what #4423 is asking for.

Like @rosswintle, I think it's important to bring this issue back on track for those that made it and pleased the last few comments seem like it is. Thank you for those that are discussing with respect.

It has to be said though, whatever you feel about a company and their motivations, many people are working on Gutenberg in a lot of different companies. Just like with WordPress, this is made of community contributions (not just one company). To make sweeping statements isn't fair on those working on this. It's also not fair on those that started this issue and want a solution.

I hope this issue get back on track and continue to respectfully debate the point of this issue.

@karmatosed , @ntwb , @tomjn , and others in this thread, If my little rant above gave offense, I apologize for that. This is an extremely important subject and worthy of debate - if we are, indeed, going to debate it.

From the threads above, I think it's pretty apparent that Gutenberg can be disabled in Core, as the other components will have to remain as part of Core, so it's just turning off Gutenberg. Which makes sense, as it currently exists as a plugin and many sites can run it fine. So, barring a heretofore unpresented technical reason, that means this decision is not a technical one, it is a philosophical one.

And, that is the real heart of it. I do not think the community as a whole is of one mind on this. Not even close. This is why the decision is being placed (notice I said "placed" not "blamed") with Matt, because he appears to be the driving force behind it. And, apparently, behind the unwavering decision to make Gutenberg part of Core and the 5.0 release.

The question is "Why?"

I can certainly see the reasoning behind forcing Gutenberg to be in Core. I think that "blocks" are very important to the future survival and widespread use of WordPress, .org or .com. I do. I am behind "blocks' 100%.

However, I do not think that Gutenberg itself, as the delivery method of those "blocks", is a well thought out system. Just from this thread, there are 3 different use cases (me, @rosswintle , and @smp303 ) and Gutenberg does not appear to satisfy any of us. Indeed, it's causing us quite a bit of concern - for us, our business, and our users.

The decision to put Gutenberg into Core makes sense for Automattic because it forces every plugin developer to adopt to it and re-write their plugins to work with it. This is very good for WordPress.com and, possibly, good for WordPress.org. But, again, some use cases will not benefit from blocks, but hopefully the existence of blocks won't hurt them, either.

However, this means a very small group of people are making some pretty powerful economic and business decisions for a very large number of people. For me alone, changing to blocks will be hundreds of hours and thousands of dollars, plus the lost development time of having to take resources away from my planned goals (that the community I service actually wants) in order to overhaul significant sections of my system to meet the demands of those unknown decision makers (again, I'm assuming Matt is a large part of that decision making group).

I wouldn't feel so bad about this - or so scared, to be honest - if Gutenberg was solving problems for me. But, it isn't. So far, it is making my life much worse. Things may improve, but I don't see a huge shift in the development direction. It seems that 95% of the decisions about use, implementation, UI/UX, as well as means and methods, have all been decided by a small group of others without much debate or input.

WordPress powers more than 25% of the entire internet. That translates to millions of sites, billions of web pages, and, possibly, hundreds of billions of dollars. From the New York Times to the handful of book bloggers on my network. From massive e-commerce sites to the individual signed books sold by the authors I service. That is massive -- MASSIVE. It is practically a worldwide global utility.

Yet, the decision to re-write a significant portion of the underpinnings for all of this -- affecting many millions of people -- was apparently made without debate. Everything from the interface to the reliance on REACT (controlled by Facebook which has proven itself to be highly predatory, just ask SnapChat). All of these decisions have been made, largely, unilaterally.

If this was all just to power a module in JetPack, no one would really care. That is WordPress.com business. But, it isn't. It is transforming the underpinnings of the entire internet.

Which leads me to right here and now. The community, definitely the community members in this thread, is asking for control over the product and business they have built using the open source and publicly available WordPress.org code. We are asking for the ability to protect ourselves and our users, and the only way we can think to do so is to ask for a way to turn off Gutenberg. We are asking for that ability to be a part of Core, just as adding Gutenberg is to be a part of Core.

Can the ability to turn off Gutenberg be added to Core? Who is it who makes that decision and directs the leads to do so? What is the mechanism for asking that question? Is the answer up for debate? Will it be put to a vote? Is there a comment process? If so, where?

And, @karmatosed , you are 100% right in that the "Issues" section of Github is not the best place to have this debate. I agree that this repo should be largely left to its intended purpose, which to identify and resolve technical issues directly related to the Gutenberg Plugin.

Sadly, there does not appear to be any other place to have this discussion. I mean, there is the Reviews section of the Gutenberg Plugin, but that is a pretty limited forum for this kind of conversation.

Will there be a site set up to discuss Gutenberg? Not only its implementation, but to comment and discuss the interface? The release timetable? (For example, what criteria governs if Gutenberg and WP5.0 are "finished" and ready for release? Who makes that decision?") Will there be user testing of the Gutenberg interface? Is there a way to gather data and feedback from @tomjn 's very helpful "Frontenberg"? If so, will that data be published?

There was an interesting video on YouTube asking people to try and use Gutenberg and rate it's intuitiveness (link here: https://youtu.be/7iWRBLCP-l0 ) - are there any others like this? Is there a large scale effort to test Gutenberg? If so, where is that data kept? How is that data shared? Can the community see it? Is it being used to drive design?

The problem we're now facing with Gutenberg - and indeed is the driving force behind this very thread - is that the community feels very isolated from this process. We feel like it is happening to us. Indeed, that is is being forced on us. Opening up the process for comment and debate, allowing new voices and ideas about things like interface, sharing data and user insights, would go a long way to alleviate those fears and concerns.

And, making blocks a Core capability, but keeping Gutenberg as a plugin, could make everything much less scary and a lot more palatable to the community as a whole. I would love that, personally. Give the community time to explore and develop alternative approaches to Gutenberg -- different interfaces and use cases - but still encourage the development and future of blocks.

So, that was pretty long, but again, where else are we to have this debate aside from here? And, this debate is VERY important. It may be the most important discussion on the internet right now, considering the number of people and businesses affected.

Having done a little research on this, it would appear that all you need, in a mu-plugin file is the following to disable Gutenberg with code, unless I have missed something - which is likely!

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

For context I have the Gutenberg plugin active and the code above in a file in the mu-plugins folder. Now all post edit screen use the classic editor.

A couple of things to note on that:

• gutenberg_can_edit_post_type is not the final filter name - gutenberg names will be renamed before merge into Core.
• 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. As Classic-specific code (for example, edit-form-advanced.php) is moved to the Classic Editor plugin, it will stop falling back to the classic editor, and explicitly expect you to load your own editor.

@rosswintle: picking up the thread from last week:

The easiest way to think about this is "if the data appears between <body> and </body>, it's content, and will ultimately fit into a block". For WordPress 5.0, this is a little more limited - only what comes between <article> and </article> is blocks. 😉

So, to take one example, a Real Estate Property post type. The price is stored in postmeta, but it's content. You might have a block called "Property Lede", it has a few items to fill out - the price, the address, building type, number of bedrooms/bathrooms/garages, that kind of thing. You'll probably have other blocks, too - Inspections Times, Features, Photos, Floor Plans, Agent, etc. Using block templates, you set up the block editor so that when the property post type is being edited, the blocks are already located, and can't be moved. The workflow for the end user is not dissimilar to what an existing metabox-based workflow looks like now, but it much more closely resembles the final output.

That was a little long-winded, but it hopefully sets the scene - anything that looks like content _is_ content, regardless of where the data is stored, or how it might be manipulated or formatted before it's displayed on the frontend. Some blocks might store their data in post_content, but that isn't the defining feature of what makes them content - being displayed on the frontend is what makes them content.

So what about information that's not displayed on the front-end? The owner's name? Relationships to viewing appointments? Is that "content"? Is that to be entered into a "block"?

Categories/tags/taxonomies may or may not be displayed on the front-end. Are they "blocks"?

Post status might be displayed on the front-end, but this definitely is not a block.

You previously said:

meta data isn't a block, though it might inform how a block is used or displayed.

Which is fine. But why, then, are developers being told that in future meta data should be edited using the block interface?

This is the real confusion for me. I get why Gutenberg blocks are good for editing what's between the body tags, but I don't get why blocks are good for editing other data that's not between those tags.

It seems to me that it's this confusion that is causing developers to want to turn Gutenberg off. Some of our uses of WordPress have a LOT of information that's not displayed in the front end and yet we're being told that in the future a front-end editor is what we should be using as an interface for this data.

I hope this communicates the confusion.

So about these ways to disable it...?

@pento the doc block for that function does not at all indicate that this filter is temporary:

/**
 * Filter to allow plugins to enable/disable Gutenberg for particular post types.
 *
 * @since 1.5.2
 *
 * @param bool   $can_edit  Whether the post type can be edited or not.
 * @param string $post_type The post type being checked.
 */

What is the purpose of that filter if not to do as described?

Additionally @pento regarding this:

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. As Classic-specific code (for example, edit-form-advanced.php) is moved to the Classic Editor plugin, it will stop falling back to the classic editor, and explicitly expect you to load your own editor.

We have been told in a number of place that if post types declare show_in_rest => false or a meta box on the post editing screen declares '__block_editor_compatible_meta_box' => false,, then the classic editor will be loaded. It seems from above you are saying this won't be part of core and therefore how can that be the case it you have not activated the classic editor plugin?

To fallback to the Classic editor is something is detected that doesn't support Gutenberg then surely the Classic editor has to remain part of core - therefore surely we don't need the plugin to invoke this functionality?

So what about information that's not displayed on the front-end? The owner's name? Relationships to viewing appointments? Is that "content"? Is that to be entered into a "block"?

Sure there's room for meta information, too - that's discussed in #3330. The primary thing I wanted to note is that a lot of what is referred to as "meta data" is actually content.

Categories/tags/taxonomies may or may not be displayed on the front-end. Are they "blocks"?

Well, they're meta to the post, but possibly content to the site. The Gutenberg Customisation focus will probably include a block that uses that meta data to produce content. 🙂 It's unlikely that a block in the block editor would use them as content, though, hence why taxonomies are in the sidebar, not in a block.

Which is fine. But why, then, are developers being told that in future meta data should be edited using the block interface?

We're not saying that all meta data fits into the block interface. Some might, but they don't have to. The point all along is that _most_ existing uses of meta boxes fit into the block interface, the easiest way to tell them apart is to think about whether it's displayed on the front end or not. #3330 discusses concepts for editing meta data in more detail.

I can categorically tell you that meta data _does not_ need to be edited in the block editor interface. If it isn't content, or doesn't somehow relate to content, it doesn't belong there - there are other places to insert the interface for editing that meta data.

So about these ways to disable it...?

If you build sites, use the Classic Editor plugin. If you build plugins, use the CPT and meta box compat flags. 🙂

If you build sites, use the Classic Editor plugin. If you build plugins, use the CPT and meta box compat flags. 🙂

This is fine for sites we build going forward, or clients that we have "on the books" and look after their sites. However what about clients whose sites we built in the past and are working fine, auto updating etc. They will probably click update to WordPress v5.0.

These sites will not have the Classic Editor plugin installed and they will not have any flags on those meta boxes / CPTs because they were coded when Gutenberg was not around. Those sites are going to have issues and leave their owners confused and frankly quite annoyed. Please correct me if I am wrong here.

@wpmark nailed it.

I will use the Classic Editor plugin if I need to in future. I will use the CPT and meta box compat flags if I need to in future. But I have tens of individuals, businesses, and charities/non-profits of all shapes and sizes that I've already created sites for. Some of them I still have working relationships with. Others have moved on and are either just running the site themselves, or work with another developer or no developer at all.

It's unrealistic to expect code changes or a plugin install on every site out there that needs it.

This is #4423 territory really.

For all the important conversation this ticket has no labels or owner. If it's not going to happen is there any point in keeping it open?

gutenberg_can_edit_post_type (or whatever it's called in Core) and '__block_editor_compatible_meta_box' => false will fall back to the classic interface in WordPress 5.0. Future WordPress releases may change that behaviour, however.

gutenberg_can_edit_post_type only flags whether to load the block editor or not. For now, the default behaviour when not loading the block editor is to load Classic, but the assumption of that filter is that, if you're not loading the block editor, you're providing your own interface. That could be the Classic Editor plugin, it could be a custom interface. But it's a likely that a future WordPRess release will see that the Classic code will be moved to the Classic Editor.

A similar situation exists for the __block_editor_compatible_meta_box flag. It falls back to the Classic interface for now, but a future release of WordPress may see the default behaviour changed to stay in the block editor, and show a warning where the meta box would be.

Of course, none of these changes are going to happen without both research and reaching out to site owners - my point is that these settings primarily exist for the purpose of transitioning to Gutenberg. The Classic Editor plugin is the stable option for forcing the Classic interface to be used.

See #3902 for more discussion on these issues.

On the topic of informing site owners, WordPress 5.0 will not be released into a vacuum. There are many tools we can use to inform site owners of the coming changes, and to let them know if their site will work or not. Future WordPress 4.9.x releases will include information about the block editor, there are plans underway to collect data on plugin compatibility (both automated and crowd sourced - #4072), and we're open to other options to ensure site owners are aware of what's coming.

For all the important conversation this ticket has no labels or owner. If it's not going to happen is there any point in keeping it open?

I had no problem keeping it open while we had this discussion, but at this point, I don't see a need to keep it open any further. To address the original question, a code-based option to fall back to the classic editor isn't on the cards.

@pento Why did you close this? The issue has not been resolved yet.

You're just proving the point that the community isn't being listened to by closing this.

I really think you should reopen it, so we can come to a resolution on this.

The resolution was no - they will not enable a way to disable Gutenberg in code. You have to rely on a plugin.

Completely unhappy and unsatisfied with this but at least I tried.

The resolution was no - they will not enable a way to disable Gutenberg in code. You have to rely on a plugin.

Where and when did that happen? There is no mention of a decision here.

Or is this just the typical core team reaction by pretending to listen then just shutting it down?

What sort of resolution are you wanting at this point?

If you want to disable Gutenberg using a constant, that's not going to happen. We've been listened to and the idea has been rejected.

I had no problem keeping it open while we had this discussion, but at this point, I don't see a need to keep it open any further. To address the original question, a code-based option to fall back to the classic editor isn't on the cards.

From @pento - this is why it closed

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.

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

To answer @smp303's original question.

1. In wp-config.php add

define( 'ENABLE_GUTENBERG', false );

1. 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

Even easier...in wp-config.php

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

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.

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.

@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.

@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.

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.

@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?

Sure @wpmark,

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

Best

@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 https://github.com/WordPress/gutenberg/issues/4409#issuecomment-357912790

@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

@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.

@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

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.

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.

@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.

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

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.

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.

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

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.

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

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.

@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

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!

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.