Support » Plugin: Gutenberg » Have both: Classic and Gutenberg

  • I have added feedback on this Gutenberg situation to the other reviews in this forum.

    I am giving one star here as the current stance of the team behind the introduction of Gutenberg does not inspire trust or confidence.

    I can understand the need to improve on the editor in WP but being so adamant that it needs to be core and default is not taking into consideration a lot of unforeseen problems and broken sites. Would it not be better to have both, Classic and Gutenberg with an option to make one or the other default. I can see the merits of both. Gutenberg being paired down for non complex tasks and classic being retained (and improved on) for developers with more complex workflows.

    Yes I have tried the Classic Editor plugin and while it does work, being a plugin suggests that, at some stage, it will be deprecated. The plugin also lacks the option to make the classic editor global by default.

    As it is Gutenberg is playing havoc with established frameworks such as Divi and Toolset Types, with both vendors having to spent many man hours figuring out how to reconfigure their offerings to play well with Gutenberg. Only recently Toolset Types implemented a reasonably good integration with Divi which I am now using on sites. All I need is for Toolset to throw in the towel on this integration because their hands are tied by the enforcement of the Gutenberg way of doing things.

    So please put in place a better strategy for the introduction of Gutenberg with a clear roadmap of how and when things will change.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Tammie Lister


    Firstly, thanks for being active in the review forums and leaving a review. That’s a shame you have no confidence, I would like to dig a little more into that if that is ok?

    It’s worth saying that right now what happens on WordPress 5.0 isn’t known. That said, the product is being developed still so there is time to iterate and listen to feedback. That’s what I try and do here on the forums.

    I can confirm there are no foreseeable plans for the Classic Editor plugin to go away. I also point to the fact Gutenberg itself has a classic text mode, whilst in Gutenberg it still offers a lot of the same experience, there is even a classic text block.

    Can I dive a little into what issues you’ve had with Divi and Toolset Types? You seem to have specific issues there and I would love to find out more. Page builders are working on being compatible on day one of Gutenberg being released, so yes some things may be issues. I would love to find out more to see if it’s the plugin or something Gutenberg needs to work on.

    Hi Tammie,

    I will dig in a bit more at risk of either digging a bigger hole for myself or yourself.

    The issue here is the right tool for the right job and before getting to answering your questions and going into more detail I would like to recount an analogy (albeit an agricultural one) to demonstrate why you might be getting a lot of one star reviews here.

    There is a company called John Deere that makes tractors to a high specification. These tractor typically have a PTO (Power Take Off), to which farmers can attach all sorts of machinery to do all sorts of jobs on the farm and big wheels with chunky tyres to get around all sorts of rough terrain. On top of this, inside of the cab is full of mod cons and is very comfortable, making John Deere tractors very popular.

    One day a boffin in the marketing department notices that sales of John Deere tractors have exploded in Ireland. Thinking that everybody in Ireland is a farmer and wondering if the appeal of the John Deere brand can be broadened he suggests that the company should produce a family saloon. The farmer’s kids would love it and it would drive up sales further.

    So off to work go the engineers and designers on this top secret project. The first thing to be dropped is the PTO, on the health and safety grounds that it is a threat to life and limb. Obviously those chunky wheels go too. At the end of this process John Deere has produced the most dramatic semi-autominous car to come to market and all electric to boot.

    The big launch day arrives and it is in Dublin with farmers invited from all over the country. When the veil is lifted there are gasps, this is not what they were expecting.

    In reaction to this shock and awe, Paddy from Kiltemagh pipes up:

    “When will we see an update to the 6120M.”

    The CEO of John Deere, who happens to be on the podium, responds:

    “We have no new tractors in the pipeline at the moment. Looking to the future, we will be focusing on road based vehicles. We are so confident that this car will be successful that we currently have a sports coupe V8 in development. Next question please.”

    Paddy turns to Tom standing beside him:

    “Well I wouldn’t drive one of those around Dublin.. All those computery lads from Facebook, Google and Microsoft would laugh me off the road and call me the parrot.” (incidentally the car comes in John Deere livery only, all green with yellow branding down the side.) “It’s of no use to me on the farm and the nearest charging point is 40 kilometres away.

    “Well that’s that then” says Tom “No more American imports for me, what with Trump, tariffs, trade wars n’all. I’m going to check out one of them German Deutz-Fahrs.”

    This sums up why there is a lot of concern and upset at the way the Gutenberg is being promoted. A lot of developers depend on the current editor interface and, forcing the Gutenberg interface on them will break and disrupt their workflows.

    Let me explain a bit more. I have added links below to websites and pages with screenshots to illustrate the point I am making. The Gutenberg editor has some merit and potential and will be useful in certain scenarios which I will highlight as we go along. The interface is very clean and the introduction of blocks has some appeal but as an interface it is static and lacking the complexity required for certain workflows. By static I mean the interface elements can’t be moved.

    On the other hand the current editor allows you to rearrange panels in whatever way you want. This would be a good point for me to define what the editor is:

    From what I can see you define this as the TinyMCE editor whereas I would define the whole webpage on the back end as the editor. I see that there is indeed a block in Gutenberg called Classic for those who want to use it. I use the TInyMCE a lot and it does a very good tool for certain jobs. My understanding is that is a separate module developed for other platforms other than WordPress and there are many versions of it. In fact I use a plugin called TinyMCE Advanced that adds extra functionality. In fact when I use the Classic block in Gutenberg I get this advanced version of that editor, which is a good thing. The one fly in the ointment with TinyMCE (at least the version in WordPress from what I can see) is that the text editor tab is hopeless at rendering formatted code, has no colour coding for highlighting syntax, and makes a balls of indentation. It could do better and aspire to function like a proper IDE text editor. The other thing the text editor lacks (like a lot of other plugins, page builders, and Gutenberg blocks) is a decent canvas area, when called upon, to do intensive coding/HTML markup work.

    Back on topic, I want to illustrate why the current editor page is so important to my workflow with the following screenshot:

    That layout is setup for a custom post type and custom fields for boats on a site I build two years ago. I am using Toolset Types plugins for this and while I am using the Divi theme for the overall site pages, in this case I am using Toolset’s templates on their own. Looking at this layout I have a set of Product fields that does not include the text area that is default for the general content loop. This is turned off through Toolset settings for this post type. I created a Description custom field for the text are instead and it is placed in a specific order after other fields to suit the workflow for data entry. This is important as I was tasked to pre-populate the site with a an inventory of hundreds of products that included items other than boats. Making the layout as logical and streamlined as possible were factors to make this job as efficient and cost effective as possible.

    Moving on, the Boat fields are linked to the boat products only, Oar products get their own post type and their own specific set of fields.

    Then at the bottom I placed the Boat Categories panel. I add a small css hack so that the panel is made larger so as to see all the boat categories at a glance.

    What I want to emphasise here is that this layout is optimised for the job at hand. It may look intimidating to the uninitiated but it conforms to Larry Tesler’s Law of Conservation of Complexity. Larry was part of the team that developed the Macintosh and he stated:

    “Every application must have an inherent amount of irreducible complexity. The question is: who will have to deal with it?”

    Well the answer is the person who is accustomed to or trained to use the interface. In my screen shot of the editor set up for boats everything is on the table and clearly labelled. Trying to do the same thing with Gutenberg interface as it currently works would entail a lot of wasted time hovering over elements to make them visible and of course I can’t put things where I want them.

    This brings me on to some words on WordPress. I started using it about ten years ago and initially it was a challenge. I jumped in at the deep end and a the time the hosting I was using didn’t have one click install so I was left to figure out how to create the mySQL database, FTP up the files and then configure everything to link up. I remember it being a painful experience, digging around on the internet to find good clear documentation. In all it took me the guts of a week to get my head around it. Nowadays I could do a manual WordPress install blindfolded in five minutes. Then there was a learning curve of acquainting myself to where everything is in the dashboard.

    The point I am making is that WordPress is a complex beast; not for the faint hearted. Its built to a certain degree for professionals. For this reason we see platforms like WIX and Squarespace pitched at amateurs and I am using the word according to its original and French definition: enthusiasts. These are solutions for people who want to built a site quickly without the complexity of rolling their own HTML or wrestling with WordPress. Yes there are limitations to what can be done with WIX et al, but they do a reasonable good job for those who don’t want too much fuss.

    Back to some observations on my testing of Gutenberg and other configurations I use.

    I spent a few days looking at some betas that Toolset have released for working with Gutenberg. Please read the following so that the comments that follow make sense:


    Following the article and documentation you can see what work is being done for the templates and views blocks. I like the way when you set up a view block how it has controls for some of the filters.

    One thing I noticed though, on a test site where there are custom post types I previously made, the Gutenberg editor doesn’t appear and instead defaults to the classic one. Toolset has in settings for types a checkbox for  show_in_rest, as you will have seen in their documentation. Even with this set Gutenberg didn’t kick in. Then I realise that fallbacks are in place when things aren’t configured in a specific manner and I often don’t use the editor on custom post types, using only custom fields. By editor, I am referring specifically to the TinyMCE text area which represents the standard content loop. My non conformist elimination of the editor must be triggering one of these fallbacks to the current editor interface.

    Looking at that show_in_rest option triggers another insight on what is happening with Gutenberg. I read in other reviews and comments that the React framework is being used. Again a good application of this technology and Elegant Themes use it for the visual builder in Divi. So I deduce what really is happening with Gutenberg, in its current guise as a plugin, is it is using the rest api to override the current interface with its own interface. Again all very good stuff and seeing custom interfaces like this is a welcome addition to WordPress. To clobber the Gutenberg interface we need your Classic Editor plugin. In effect that plugin doesn’t actually contain the classic interface, it is just a switch and more on this in my conclusion.

    Moving on to one more concern. How this effects my work with Divi, and Divi using the Toolset integration. Have a skim through the following pages to see how this works:


    When using the Gutenberg plugin and let say in theory we don’t have access to the classic editor anymore you end up with a pile of Divi shortcodes which really isn’t something you can work with. Yes you can still work with the Divi Visual Builder on the front end for regular posts but when making templates through Toolset’s integration for Divi you only use the back end.

    Here is how the editor should look like when making a template:

    And when Gutenberg is in charge:

    This give you an idea of how terrible wrong things can go when you introduce something as disruptive as Gutenberg. All the developers out there need to firefight situations like this. I have to depend on venders like Toolset not throwing in the towel on the Divi integration because it all becomes to taxing with all the other theme integrations they are working on.

    In conclusion I can see some merit in the Gutenberg editor. It has a clean interface and would be useful if we could use it for end user clients for simple data entry and trivial post and page publishing. But as I have illustrated, Gutenberg on its own is a hornets nest of pain when shoved into the complexity of established workflows and theme/plugin integrations.

    There is of course a simple and elegant solution to all this. There is no reason why both interfaces can’t be used in WordPress. It could be a healthy symbiosis with certain features and design bleeding from one interface to the other. By all means, you can make Gutenberg interface default on installation of WordPress but just show us the checkbox to make the Advanced Editor default. Don’t make Classic Editor a plugin and actually change the name form Classic Editor to Advanced Editor. Both plugin and Classic title stink of deprecation and abandonment sometime in the future.

    Tammie if you have got this far your a star and thanks for considering my suggestions and observations.



Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Have both: Classic and Gutenberg’ is closed to new replies.