Support » Plugin: Classic Editor » Too Many Config Steps

  • If we are going to be forced to install a new plugin on all the existing sites that Gutenberg will break, it needs to be a one-click process. Currently, I need to install and activate the plugin, then change the setting in Writing Settings to disable Gutenberg completely, then I need to reset the screen options, because apparently classic editor defaults to showing all screen options.

    For this to be workable to install on multiple sites (300+ in my case), installing and activating the plugin needs to immediately remove Gutenberg, and preserve the existing screen options. Making Gutenberg an optional interface should be opt-in, not opt-out.

Viewing 15 replies - 1 through 15 (of 15 total)
  • Plugin Author Andrew Ozz

    (@azaozz)

    Gutenberg will not break sites 🙂 It will chance how posts are written and edited, and yes, most users will need to learn a little more about how web pages work and how to “format for the web”. There will be a learning curve, but not a steep one.

    Of course changing the editor will require updates to all plugins that do something with the editor. That will take some time. The Classic Editor plugin will be most useful for this transition period.

    …it needs to be a one-click process

    Currently this plugin is for testing. It will become necessary once the Gutenberg editor is merged in core. Was considering to change it to replace the editor by default, but for now this doesn’t make sense (the user can simply deactivate the Gutenberg plugin). After the merge the default will probably be changed.

    I agree with the goal that Gutenberg won’t break as many sites as possible, but some breakage will occur (imagine upgrading a site that is using the current version of BoldGrid or Blockade).

    I understand that this plugin is partly for demonstration purposes at the moment, but the primary driving force for non-devs to try the plugin at the moment is to see if it is actually a complete removal of Gutenberg. Their workflow is:

    • install Gutenberg
    • install Classic Editor
    • See if all their customizations to the interface still work

    Having as few steps as possible involved in the process of fully removing Gutenberg would help to ease many concerns about their upgrade paths.

    Andrew,
    You mention above just deactivating the Gutenberg plugin.
    I tried out Gutenberg and love it. It is GREAT. I wish it was up and ready right NOW. I finished off 1 post, and a few other little things and began to see problems. As you said current it is for testing, only.

    Now, I want to deactivate Gutenberg, and clear up the little problems. But, I have this 1 post and I wonder what will happen to it, when I deactivate.

    Do you know????

    What happens to my 1 Gutenberg post, if I deactivate the Gutenberg plugin?

    Lesley

    @gschoppe, I just released a function that changes the default setting. Please have a look here: https://gist.github.com/senlin/691c5f06459857f57247dc92f7ec1406

    @muckmoney, why don’t you try deactivating Gutenberg and see what happens? What is the worst that can happen?

    Ross Wintle

    (@magicroundabout)

    I agree – I have about 150 sites that I manage for clients. I will want to update them to Gutenberg when the time is right. So my plan was to install this plugin using a tool like ManageWP on all the sites.

    But I just found out that installing the plugin is not enough.

    The default behaviour of the classic editor plugin should be to restore the classic editor. I don’t want to have to automate the changing of an option as well.

    Please make full classic-editor-restore the default function for this plugin.

    Ross Wintle

    (@magicroundabout)

    A couple of other things to note:

    Gutenberg will not break sites

    You’re possibly/probably right in that Gutenberg will not stop sites from functioning. But they will significantly change the user interface. As one of many developers who creates WordPress-based sites for other people (my clients) I want my clients to be ready for this, and I want my code to be ready for it.

    I consider significant UI changes “breaking” as much as I consider code/functionality changes to be “breaking”.

    From my point of view, Gutenberg will significantly “break” sites.

    After the merge the default will probably be changed.

    Can we at the very least make this “a short time before the merge” so that my sites are ready to have Gutenberg deactivated BEFORE it arrives in the update?

    Thanks.

    Can we at the very least make this “a short time before the merge” so that my sites are ready to have Gutenberg deactivated BEFORE it arrives in the update?

    Agreed wholeheartedly. We need to be able to put this plugin in place on all our existing client sites Before the release of 5.0 and have it function out-of-box with no config.

    With the current configuration, I’ll need to release yet another plugin, perhaps called Better Classic Editor just to do this the right way.

    Phil

    (@philclothier)

    +1 for that. It would be ideal to have a plugin/filter which prevents Gutenberg from being the default editor when it is included in core.

    Is anyone aware of a way to do that?

    @philclothier
    @gschoppe

    Did you see my post about the snippet you can add to your functions.php file or functionality plugin?

    I’ll post it again: https://gist.github.com/senlin/691c5f06459857f57247dc92f7ec1406

    So the solution for GB not being the default is to use this plugin and add my snippet and be done with it.

    • This reply was modified 1 year, 8 months ago by Pieter.
    Phil

    (@philclothier)

    @senlin Ah I missed that comment, thanks for following up and sharing the gist!

    @senlin Thanks for the snippet. I made a change to it, so that the plugin will no longer read or update a setting from the database on every page load. It should slightly improve performance. I also packaged your code with a plugin header, so that it can be installed via ManageWP, or another multi-install dashboard.

    https://gist.github.com/gschoppe/ce88a7821764ef11803a5c64350078b6

    I still, however, firmly believe that this is a flaw with the design of the plugin that should be properly fixed so we don’t need two plugins to do the work of one.

    Phil

    (@philclothier)

    Nice work guys, thanks for sharing. I agree that this should be available in the standard plugin, but at least we have this solution now.

    @gschoppe Great changes, thanks for collaborating on it!

    @azaozz

    Thank you for providing this plugin. While Gutenberg is undoubtably the future of WordPress, I do appreciate the ability to ease into the transition by using this plugin.

    Above you mention,

    Was considering to change it to replace the editor by default, but for now this doesn’t make sense (the user can simply deactivate the Gutenberg plugin). After the merge the default will probably be changed.

    I’d like to suggest modifying this default to replace sooner rather than later. If someone installs this plugin now in preparation for the merge, their option will be set to no-replace.

    Even if the default changes in the future, these legacy installs will still have a value of no-replace. (I’m assuming future updates will not modify the existing option).

    Those who install the plugin later, will have the new default (replace).

    Since the impact of this plugin is not visible until Gutenberg is merged (or the Gutenberg plugin is activated), I suspect many of these sites will be unaware of their setting until the merge occurs.

    The result will be that when Gutenberg is merged, the plugin behavior will vary based on when the plugin was first installed, which will be quite confusing.

    Would you please change the default value to replace to help avoid this issue.

    Thank you again for providing this plugin to our community.

    Quick update to announce that Greg and I released the earlier mentioned snippet as an official plugin:

    Classic Editor Addon

Viewing 15 replies - 1 through 15 (of 15 total)
  • The topic ‘Too Many Config Steps’ is closed to new replies.