WordPress to Support Classic Editor for “Many Years to Come,” Plugin and Theme Markets Expected to Drive Gutenberg Adoption

During the 2017 State of the Word address, Matt Mullenweg announced the availability of the Classic Editor plugin for site owners who are not ready to adopt Gutenberg when it makes its debut in WordPress 5.0. Since its release, the community has speculated about what the plugin’s active installation numbers mean and how long it will be supported.

Matt Mullenweg has confirmed that support for the Classic Editor will be available for “many years to come,” which should come as a relief to those who feared that WordPress would drop support for the old editor after a year or two.

“I love that people are using the Classic Editor plugin!” Mullenweg said in comment on a recent post. “There is an infinite number of ways that WP can be used and not all will be ready for Gutenberg when 5.0 is released, Classic allows people to still be able to update core and stay current with releases, and with the click of a button try out Gutenberg again in the future if they want to. It’s also trivial to maintain because Gutenberg also uses TinyMCE, so Classic Editor users will still get improvements and updates to TinyMCE — I won’t say ‘forever’ but I don’t see any reason why we can’t maintain classic for the edit screen for many years to come.”

These assurances about the continued availability of the classic editor mean that WordPress product developers will need to decide if they want to provide support for both editing experiences or go full steam ahead with Gutenberg, limiting support to WordPress 5.0+. We don’t yet know how many users will be installing the Classic Editor after WordPress 5.0 is released but that may inform more product decisions in the future.

The Market Will Drive Gutenberg Adoption

During the Q&A following the State of the Word in 2017, WordPress developer Kevin Hoffman asked a question about the prospect of developers having to support two different editing interfaces:

Hearing you suggest the Classic Editor plugin and different ways to undeclare support for Gutenberg leads me to this idea that we are headed towards a split admin interface with no finality to the transition, meaning that I don’t see a time in the future where everyone will be on Gutenberg. We will always have these people in classic mode. As plugin and theme developers, we will always have to support two different types of users. How do we reach that point where we are past the transition, however long it might take, where we can not have this box of chocolates effect where you click “edit post type” and you never know what you’re going to get?

Mullenweg said his hope and expectation, based on how this has worked out with new interfaces in the past, is that over time product developers would adopt the latest interface. He cited the Customizer as one example where one is now very hard-pressed to find a theme developer who is rolling their own options panel after the Customizer was introduced as the new standard. It was just three years ago in 2015 when WordPress.org began requiring theme options to be built using the Customizer and now it is used everywhere.

“The truth is, if you are a plugin or theme developer, people are going to expect things in Gutenberg, so you really need to develop for Gutenberg,” Mullenweg said. “And then, at some point, I’m totally ok if you drop support for the Classic [Editor]. There will be themes and plugins that will say you need to have Gutenberg, [WP] 5.0 or newer if you want to use this.

“We already have that existing now. Plugins only support so far back in PHP in WordPress. There will be plugins that don’t support under WordPress 5.0. It’s not going to be that much different from supporting different WordPress versions where people choose sometimes to go way way way back, sometimes a year or several years, and support WordPress 3.8 and 3.9. And some don’t bother anymore. There’s lots of APIs and other things that changed during that time. At some point you just have to make a cost benefit analysis and do things like maybe Yoast is doing for upgrading PHP, and say, ‘Hey, if you really want the best of this, check out this new thing.'”

As Gutenberg blocks become the standard way of extending WordPress’ editing and customization capabilities, the market will drive its adoption. This is already happening with new blocks and block collections being released every day. The new Gutenberg Block Library offers a glimpse of that and there are many more blocks on GitHub that are not yet commercially marketed.

During that December 2017 Q&A, developers seemed to be excited about the Gutenberg demos they had just seen but their uneasiness was palpable in their questions. Now, eight months later, the current proliferation of Gutenberg themes and plugins demonstrates that WordPress developers are ready to embrace the new editor and build the creative extensions that Gutenberg’s creators’ had always anticipated.

“I’m really looking forward to seeing what the design and developer community can build with it and where their imaginations can take us from there,” Gutenberg technical lead Matías Ventura said when I interviewed him in June. “Core is going to supply the infrastructure and the main building blocks but it’s everything that can be built around it that’s going to be exciting, as always with WordPress.”

The extension ecosystem that made WordPress a success in the first place is going to be a key influence in driving adoption for the new editor. Major players in the product market are not waiting to see how users react to the new editor before building their Gutenberg-compatible interfaces. Users may not be compelled by the writing experience, but Gutenberg’s block model will provide a better framework for site customization and a core standard for page builders that interface with WordPress. If the blocks pouring into the ecosystem right now are any indication, the plugin market surrounding Gutenberg is going to offer an exciting variety of tools for site building.

13 Comments


    1. I will too for existing sites, but moving forward will probably use Gutenberg on new projects

      Report


  1. I’m very happy about the promise of extended support of the Classic Editor. I’d be much happier if we took this to its logical conclusion and make Gutenberg an optional plugin until it’s both a) finalized, and b) in wide-enough use that it makes sense to switch over, instead of forcing people to install a plugin to make sure their website doesn’t break. Even if they wanted to make the Gutenberg plugin default in new installations, that’d be fine.

    The heavy-handedness of the announcement and plan actually bother me more than the actual plugin itself, because there are always ways to architect around bad decisions. As someone who manages enterprise installations, I have trouble selling my bosses on a product that the maintainer can decide needs a wholesale revamp on, despite it working very well for us as-is.

    Report


  2. If Gutenburg implements the same or similar functionality that is present in the current editor that may Go some way to make it more useable.

    Report


  3. one is now very hard-pressed to find a theme developer who is rolling their own options panel after the Customizer was introduced as the new standard

    Is this a joke? Perhaps that is true on the WordPress.org repository, since integrating options into the customizer is a requirement for themes that want to be listed there, but the vast majority of themes on other marketplaces still roll their own admin panels.

    It’s also apples vs oranges. No one needs to disable the customizer for their site’s features to work. It’s just an additive experience. This is much more similar to the replacement of the media library, which saw a mass die off of popular plugins in its wake.

    The issue with Gutenberg vs Classic Editor is that they are two completely different and mutually exclusive development environments. So, either plugin developers stick to the subsets of metabox interfaces that aren’t broken by Gutenberg, or they build systems that aren’t compatible with Classic Editor, or they do twice the work.

    Realistically, that means plugin devs are going to pick a side. Those that pick the Gutenberg side will see a significant reduction of userbase, but will also make it much harder for users of Classic Editor.

    What is really crucial from Matt/Automattic is not just a statement that classic editor will be supported indefinitely, but a statement that it will be supported by all Automattic properties, such as WooCommerce. This is especially crucial with WooCommerce’s history of implementing breaking changes.

    Report


    1. Agreed.

      I use Beaver Builder, Beaver Themer, and Beaver Theme, and I avoid the customizer like the plague. And always have once I got to see its failings.

      As a site dev, I find a child theme with all my custom css in its stylesheet the best workflow. Then everything is in one place.

      I wish WordPress would stick to and focus on its core product instead of seeing something succeed in the dev community then eating those dev’s lunch.

      Let the dev community make WP great. It’s worked for 15 years and was working fine before the Customiser and before Gutenberg.

      Report


  4. Hello I understand new and improved ways of doing things are always at hand or in the future. But, am sure you know how many people are not welcoming to change (new unfarmiliar ways) in how things work? They have to learn something new (again). Especially when they just learned the Old way of doing things or how things worked. WHY or Can’t Someone Develope a way for the Old to be Automatically changed (updated) to the new process with (option of) instructions on how the New process works? Therefore leaving noone behind in the process of updating systems or operations? And then Everyone is Happy with learning something New in the process.

    Report


  5. And then, at some point, I’m totally ok if you drop support for the Classic [Editor]. There will be themes and plugins that will say you need to have Gutenberg, [WP] 5.0 or newer if you want to use this.

    What incredible arrogance. This is what WordPress has come to; what a horrible shame.

    Report


    1. That would be true, but since WordPress and it plugins are open source, you can hire a developer to customize that plugin to fit your needs. Once you purchase the plugin from the original developer, there is nothing that they can do to stop you from paying someone to customize it to your needs.

      Report


  6. I don’t feel better about the Classic Editor plugin. Gutenberg is absolute trash, and adding it to the WP core is blatantly ignoring the fact that the majority of people hate it. The WordPress editor needs to be left as it is, and Gutenberg needs to remain a plugin — this is only my opinion and hundreds of others.

    It’s too late to turn back now, because there’s been too much marketing involved with claims of the so-called almighty, amazing capabilities & functionality of this disaster called Gutenberg. The Gutenberg plugin authors and WP core team members are too arrogant and not willing to admit the catastrophe of this horrible thing. Admitting that the Gutenberg project is a failure (despite its good intent), would be too much of an ego buster.

    When Gutenberg becomes part of the core, my hope is that WordPress receives soo much heat to the point that they are forced to remove Gutenberg from the core. If Gutenberg still isn’t removed from the core and issues/bugs still persist, then my hope that it will be possible somehow for people to take legal action the Gutenberg authors and WP core team members that allowed Gutenberg become part of the core. If Gutenberg disrupts enough themes and plugins, there are going be developers losing clients and money — lots and lots of moolah. Even though the WordPress script is open source, there is a slew of people displaying their critiques and dislikes of Gutenberg (well prior to its release), and people are literally ‘begging’ for this not to be added to the core.

    Report


  7. He cited the Customizer as one example where one is now very hard-pressed to find a theme developer who is rolling their own options panel after the Customizer was introduced as the new standard.

    I think this is not the best example, because in my company our clients never ask us to make theme options with customizer, this is not always convient for the client and it’s a lot more easier to make theme options panel with Advanced Custom Fields, for example or with the Redux Framework.

    Report


  8. This might be true, but keep in mind that WordPress and all of the plugins and themes are open source. That means, someone can hire a developer to disable gutenberg and customize a plugin that was purchased to fit your wordpress website. This will increase the cost of doing business, but it will be worth it.

    Report


  9. I do not know where you get the idea that developers are excited by Gutenberg. A simple comment that I posed on Facebook produced a vast number of responses from developers, all united in their dislike. I have tried Gutenberg as a plugin for several weeks now, on a couple of my websites. It tends to freeze up the backend. This is probably due to a clash with another plugin, and, when I get chance, I will try to find out which one. But why fix what isn’t broken? Gutenberg is an answer for a question that nobody was asking. And it has some considerable problems – Gutenberg’s code editor, for example, is just plain text, with none of the helpful tools found in the Classic Editor’s code editor.

    WordPress is an open source product. They have the right to do what they like, and I don’t have to use it. I will be interested to see if ClassicPress manages to get off the ground as a viable fork.

    Report

Comments are closed.