Opt-in, not opt-out for legacy sites

[polevaultweb]

Only enable Gutenberg for new installs (for now).

Merging Gutenberg and releasing as part of 5.0 is an agressive timeline for the whole of the WordPress community and ecosystem.

I suggested in my recent post on Gutenberg that to ease the burden on developers, agencies, and site owners (not to mention plugin developers), that -

Gutenberg should only be on by default for new installs.

This would make the entire Gutenberg editor/experience/functionality OFF by default for legacy sites.

Apologies is this has been raised specifically before, but there seems to be some support of this idea and it needs a place to have the debate.

To be clear, this is related to this issue about having a better way of disabling Gutenberg in code #4409 but not the same. This would require the means to disable Gutenberg be actually in the Gutenberg code itself (not another plugin which needs to be updated and can break). Then as part of the merge to WordPress core, the logic to disable for existing sites can be implemented. Of course people can enable it if they wish (via a setting, code) on these sites.

Yes this will make adoption slower, but making it opt-in for legacy sites will make a much smoother transition for so many sites, developers and owners. I'm not suggesting make it this way for ever, but use the new installs usage to help improve and iterate and then flip the switch to a full Gutenberg experience across the board in 12 months, 18 months, X releases down the line.

It feels like Gutenberg is some way off being ready, and the plugin space is certainly not there, so let's iterate in a safer fashion. To quote @m when referring to the merge of the REST API:

It's: iterate in plugin with low stakes, or iterate in core, shipping to tens of millions of sites?

https://twitter.com/photomatt/status/696765965334290432

Related: The Economic Impact of the Timeline of the Gutenberg Rollout

[rosswintle]

It probably won't surprise anyone that I support this idea wholeheartedly.

Rationale is given by me in #4409 and https://rosswintle.uk/2018/01/wordpress-gutenberg-business-owner-developer/

[stompweb]

It feels like Gutenberg is some way off being ready, and the plugin space is certainly not there, so let's iterate in a safer fashion.

I think this is a different issue to whether or not it is opt-in or opt-out. If it's not ready then it shouldn't be be released for any installs, new or old.

+1 for an opt-in on existing sites. It feels like the reverse of the strategy used when the 'Links' menu item was removed for new installs but kept for existing ones.

[eirichmond]

I agree! The thought of retrofitting legacy code makes me shudder, I should have the option to choose if I want to use Gutenberg or not with older sites I have developed.

[wpmark]

I absolutely agree with this too - Gutenberg should only be active on new installs of WordPress when it lands in version 5, with the option to opt-in should a user wish to do so.

I have built, over the years hundreds of WordPress sites and I can imagine that I am going to get dozens of phone calls when their sites upgrade to WordPress 5.0 and Gutenberg gets activated on the site. These calls are going to require time and action and who is going to pay for that? I can see why the client would not want it to be them.

This could cause a lot of problems and a lot of bad feeling about WordPress in the wild - all of which isn't necessary.

[joffff]

(Bringing my comment over from #4409 as it's more appropriate here.)

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.

[bobbingwide]

Please also consider Multisite and what happens when a new site is created.

Main Site	Existing child sites	Gutenberg enabled in new site?
opted-out	opted-in	?
opted-out	opted-out	?
opted-out	mixed	?
opted-in	opted-in	Yes - opted-in
opted-in	opted-out	?
optend-in	mixed	?

What are the required values for ?.
How will this be achieved?

[danieltj27]

Within the current roadmap, I don't see the Gutenberg enabled for new sites option being viable. The reason for this is because Gutenberg will be merged into core and TinyMCE taken out, so you wouldn't be able to have Gutenberg turned off as you wouldn't have an editor otherwise. I'm on the fence as to whether Gutenberg is a good thing or not.

I like it, but I do think the backwards compatibility thing has been completely disregarded in this scenario which I'm not a fan of picking and choosing which standards you want to stick to. I'm curious as to whether anyone will want to fork WordPress into a new project. I can see it coming personally. I think we'll need to see how things pan out.

[bobbingwide]

No, TinyMCE will still exist. In Gutenberg v2.0.0 if a custom post type does not support 'show_in_rest' then the Classic Editor is shown.

At present hardly any of my CPT's have this flag set, so the Classic Editor is the only option.
Whether or not Gutenberg's own wpautop disrupts the front end for these posts I've yet to discover.

[danieltj27]

I'm of the understanding that in v5 of WordPress, when Gutenberg is merged in, the classic (TinyMCE) editor won't exist in core anymore, and as such there'll be no way of turning it on or off. Am I wrong with this assumption? Will TinyMCE still exist in version 5?

[rosswintle]

From #4409:

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

and

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.

[markkap]

@danieltj27 Obviously it will be in core as gutenberg is based on tinymce, and it is essential for the text widget and the wp_editor API.... it removal will probably break 50% of wordpress sites regardless of gutenberg.

[wpmark]

Just putting a comment from another thread here as it is more relevant.

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.

[pento]

I understand the issues being raised here, #4087 (and related issues) are investigating many similar problems, though with a different goal in mind. When WordPress 5.0 is released, it should be possibly for the vast majority of WordPress sites to upgrade and begin to use the new block editor seamlessly. For those that can't use the block editor, it should fall back to the classic editor.

To begin with, I think #4087 is the best approach to try first, so I'm going to close this issue while that's still underway, with the proviso that we can certainly re-open this issue if it turns out to be not possible to make the block editor work for the majority of sites.