search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.12k stars 4.04k forks source link

A way to disable Gutenberg editor in code? #4409

Closed smp303 closed 6 years ago

smp303 commented 6 years ago

If Gutenberg is to be enabled by default...

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

DEFINE{'ENABLE_GUTENBERG', false);

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

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

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

aduth commented 6 years ago

See also:

smp303 commented 6 years ago

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

wpmark commented 6 years ago

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

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

aduth commented 6 years ago

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

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

smp303 commented 6 years ago

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

aduth commented 6 years ago

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

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

smp303 commented 6 years ago

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

gomezcode commented 6 years ago

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

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

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

My 2 cents.

youknowriad commented 6 years ago

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

rosswintle commented 6 years ago

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

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

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

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

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

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

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

lukecav commented 6 years ago

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

dmje commented 6 years ago

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

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

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

NewJenk commented 6 years ago

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

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

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

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

robmcclel commented 6 years ago

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

ntwb commented 6 years ago

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

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

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

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

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

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

pento commented 6 years ago

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

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

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

robmcclel commented 6 years ago

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

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

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

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

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

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

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

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

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

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

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

markkap commented 6 years ago

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

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

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

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

rosswintle commented 6 years ago

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

You have said:

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

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

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

[blocks] are a unified way to style content

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

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

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

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

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

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

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

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

Some of the post_meta that I create is the same.

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

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

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

wpmark commented 6 years ago

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

joffff commented 6 years ago

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

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

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

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

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

polevaultweb commented 6 years ago

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

benfurfie commented 6 years ago

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:

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

eirichmond commented 6 years ago

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

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

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

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

benfurfie commented 6 years ago

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

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

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

pento commented 6 years ago

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:

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

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

eirichmond commented 6 years ago

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

pento commented 6 years ago

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.

pento commented 6 years ago

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

wpmark commented 6 years ago

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.

pento commented 6 years ago

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

tomjn commented 6 years ago

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:

<?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 commented 6 years ago

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

See: http://peoplesunderthreat.org

Real Estate example:

A "property" type that has:

Event example:

An "event" type that has:

There are many.

smp303 commented 6 years ago

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?

rosswintle commented 6 years ago

@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

JAW-Dev commented 6 years ago

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.

jameskoster commented 6 years ago

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.

robmcclel commented 6 years ago

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.

wpstudio commented 6 years ago

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?

tomjn commented 6 years ago

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.

wpstudio commented 6 years ago

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

JAW-Dev commented 6 years ago

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?

tomjn commented 6 years ago

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.

JAW-Dev commented 6 years ago

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

benfurfie commented 6 years ago

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.

rosswintle commented 6 years ago

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

JAW-Dev commented 6 years ago

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

robmcclel commented 6 years ago

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

rosswintle commented 6 years ago

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.

benfurfie commented 6 years ago

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