WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#43068 closed feature request (wontfix)

Ability to disable Gutenberg in wp-config.php

Reported by: simonp303 Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.1
Component: Editor Keywords: close
Focuses: administration Cc:

Description

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

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

Change History (6)

#1 @jeremyescott
3 years ago

Matt mentioned in the WCUS state of the word that Gutenberg will launch with a plugin that disables and that plugin developers and theme developers will be able to disable it on a per-editor basis.

As you said, this begs the question: how long will developers need to support both? But I don't think we'll need a new constant for it.

#2 follow-up: @SergeyBiryukov
3 years ago

  • Component changed from General to Editor

Hi @simonp303, welcome to WordPress Trac! Thanks for the ticket.

There is a Classic Editor plugin to disable Gutenberg: https://wordpress.org/plugins/classic-editor/.

#3 in reply to: ↑ 2 @simonp303
3 years ago

Hi :) I was curious if that was the only option - wondered if there could be a code way. I am keen not to have too many plugins enabled where possible. Also will that not add to load time?

Replying to SergeyBiryukov:

Hi @simonp303, welcome to WordPress Trac! Thanks for the ticket.

There is a Classic Editor plugin to disable Gutenberg: https://wordpress.org/plugins/classic-editor/.

#4 follow-up: @swissspidy
3 years ago

  • Keywords close added

If you want a "code way" you could copy the code of the Classic Editor plugin: https://plugins.svn.wordpress.org/classic-editor/trunk/. However, that doesn't make much sense when you could just activate the plugin instead. The overhead caused by activating a new plugin is so negligible, you won't even notice it.

#5 in reply to: ↑ 4 @simonp303
3 years ago

Its not the activating - its the code that is needed to make the changes and the order in which it gets called due to being a plugin :) Hence why seeing if it could be added higher up the chain like in wp-config

Replying to swissspidy:

If you want a "code way" you could copy the code of the Classic Editor plugin: https://plugins.svn.wordpress.org/classic-editor/trunk/. However, that doesn't make much sense when you could just activate the plugin instead. The overhead caused by activating a new plugin is so negligible, you won't even notice it.

#6 @dd32
3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

Last edited 3 years ago by dd32 (previous) (diff)
Note: See TracTickets for help on using tickets.