A way to disable Gutenberg editor in code?

[smp303]

If Gutenberg is to be enabled by default...

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

DEFINE{'ENABLE_GUTENBERG', false);

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

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

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

[smp303]

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.

[wpstudio]

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.

[rosswintle]

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

[karmatosed]

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.

[robmcclel]

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

[wpmark]

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.

[pento]

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.

[pento]

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

[rosswintle]

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

[wpmark]

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

[wpmark]

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?

[pento]

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

[wpmark]

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.

[rosswintle]

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

[pento]

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.

[JAW-Dev]

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

[smp303]

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.

[JAW-Dev]

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?

[rosswintle]

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.

[smp303]

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

[JAW-Dev]

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

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

[rosswintle]

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

[bobbingwide]

To answer @smp303's original question.

1. In wp-config.php add

   define( 'ENABLE_GUTENBERG', false );

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

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

props @tomjn @wpmark

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

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

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

[bobbingwide]

Even easier...in wp-config.php

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

[colomet]

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

Inside of a post we just need a text editor.

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

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

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

[TomDesign]

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

Bring your programming skills to helping solve the problem.

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

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

[markkap]

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

[bobbingwide]

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

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

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

[unCommonsTeam]

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

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

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

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

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

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

Thank you all for your attention, Good job.

[wpmark]

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

[unCommonsTeam]

Sure @wpmark,

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

Best

[wpmark]

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

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

However was informed by @pento that was not a robust solution as it does put an editor back in to WordPress. See https://github.com/WordPress/gutenberg/issues/4409#issuecomment-357912790

[unCommonsTeam]

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

Best

[wpmark]

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

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

As @pento stated:

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

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

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

[unCommonsTeam]

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

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

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

Cheers

[codebard]

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

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

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

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

[WebTrooper]

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

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

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

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

[chrisvanpatten]

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

[tomjn]

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

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

---

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

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

[rosswintle]

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

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

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

Alternatively, April 12th 2020 will do. 😉

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

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

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

[codebard]

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

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

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

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

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

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

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

[tomjn]

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

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

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

[rosswintle]

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

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

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

[polevaultweb]

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

[smp303]

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

[tomjn]

@smp303 can you please identify who they are?

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

[ghost]

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

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

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

[pento]

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

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

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

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

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

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

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