On St. Patricks Day in Toronto, The Toronto WordPress Meetup Group  had a 2 1/2 hour session devoted to the implications of Gutenberg to the WordPress developers and wider community of users. Great St. Patty’s Day Fun in TOTown.

The Meetup  brought out 26 WP Developers  on a gorgeous Saturday afternoon. All of the group had tried out using Gutenberg editor  and a small few had started coding their own GutenBlocks using React.js. And this was the purpose of the meeting organized by Andy McIlwain and Kiera Howe  –  to get a profile of what Toronto WordPress developers were doing with Gutenberg.. The  session  was designed for developers primarily with  3 main goals:

1)The Gutenberg Mission and Scope
2)Update the State of Gutenberg as new WordPress Core Editor
3)Gutenberg’s projected impact on Developers and End-users
Lets look at each of these topics and what they reveal about Gutenberg .

Gutenberg’s Mission

Andy and Kiera featured a video of Morten Rand-Hendriksens talk and later posting at WordCamp.US  from late last year. This was supplemented  by Matt Mullenweg’s State of Word talk at WordCamp as well. From these presentations and talks a clear idea of the emerging status of Gutenberg became evident to all  Meetup attendees.

The Source of concern for many developers at the Meetup

As one developer noted – “I was concerned given Gutenberg’s low plugin rating that this was going to be a mess.But I can see from the demo that Gutenberg will be a viable replacement for the TinyMCE editor”.

But others raised two concern: First, they had anticipated Gutenberg would be a WYSIWYG frontend editor like many of the best PageBuilders like Beaver Builder, Cornerstone, Divi, Elementor Thrive Architect, Visual Composer, etc. Second. some developers insisted that they used PageBuilders as their WordPress Editor of choice and that Gutenberg currently fell well short of those capabilities . They were concerned that Gutenberg would preempt the Pagebuilders when it  went core in 5.0. However, those concerns were partially allayed by the fact that a Classic Editor plugin has been  made available. Our tests showed that using this Classic editor plugin would enable users to choose between Gutenberg or the Classic editor in WP 4.9.4 and Gutenberg 2.4.0. But how long this setting remains in effect for WP 5.x and beyond  was a voiced concern.

More broadly, both Morten and Matt made clear that Gutenberg  was certainly not intended to be a mere replacement for the current WP Visual Editor. Gutenberg is really designed ultimately to be a complete SiteBuilder. Using the speed and coding advantages of GutenBlocks built with React.js, Gutenberg is designed to replace  specialized coding for headers, footers, sidebars, widgets, metaboxes, and even custom post types. So Gutenberg is intended to be not just an editor replacement but rather a   general WordPress User Interface Design tool, managing all of a website’s layout and design tasks.

In effect, Theme options and customizations plus  Content Building tasks are all handled by Gutenberg. But this is futures; the immediate target for Gutenberg is to replace the current Classic Editor. But this is  the same  direction taken by some of the best PageBuilders as described in this review . So the Gutenberg mission and scope goes well beyond being a replacement for the WordPress Visual Editor [aka the Classic Editor].  But in the process, Gutenberg has further accelerated the same innovation as  PageBuilders  become  SiteBuilders too.  So lets see how well Gutenberg does its first job of replacing the Classic Editor

Resolve Gutenberg’s Readiness to Edit

A tour through the Gutenberg Demo plus some selected edits showed that Gutenberg has improved notably  from its early summer 2017 initial  debut. But as you see in the sidebar on the left , Gutenberg is not a shoe-in for immediate success. as a replacement for the Classic Editor. First, because Gutenberg is still chock full of  “An unknown error occurred”  bugs. Second the size of the edit screen makes for tight fits and edit areas overlap especially when using columns and tables – Gutenberg is far from WYSIWYG.

And  as a result of these continuing teething problems, the current Gutenberg grades of 186 1-star ratings outnumber the 129 5-star ratings. Even in the last week, the comments by Gutenberg trial users echo some  consistent themes: “Much work needed!”, “Leave this as an optional  plugin ” and  “hard to figure out”.

Now as noted above it is possible to use the Classic editor or the Gutenberg plugin. So this provides an opportunity to compare the performance of the two editors using the same editing sequences. This gives us a feel for the  capabiity of Gutenberg versus the Classic Editor as of March 22, 2017.

Here is a screen shot of the Classic Editor in action:


Toggle edit view
Notice that the Classic editor in Visual mode provides only a partial WYSIWYG view of the page. This is very similar to what one will see below with the Gutenberg editor and is the chief weakness of the both the Classic and Gutenberg editors. However, the Classic editor has two rows at the top of all the edit operations available in contrast to Gutenberg where most of the operations are hidden and have to be discovered by the first time user. So it is easy in the Classic editor to do text editing for any of the text fields such as  headers, ordered and unordered lists, blockquotes, etc. However, to add a drop cap requires using a free plugin, Shortcodes Unlimited. It is handled more easily in Gutenberg.

Single images and Galleries are treated in the  Classic editor close to the same fashion as in Gutenberg. Likewise special display plugins like sliders, gallery grids, and animations can be inserted from the Classic editors command bars directly, a little more conveniently than Gutenberg. Now lets see how the Gutenberg editor works on the same post contents.

Here is the Gutenberg editor doing the same post edit:


Toggle edit view
The Gutenberg editor presents a completely new look for first time users familiar with the Classic WordPress editor. This will be a  non-trivial learning curve for the 30 million WordPress users – perhaps a half day training session followed by a week of usage to discover all the  Gutenberg features. Pressing on the ⊕ icon reveals all the block, embed and shared  commands. The shared commands in Gutenberg allows user to save blocks of code for re-use. This is the first hint of template PageBuilder-like capabilities built into Gutenberg. WPEdit premium version has snidgets  which match Gutenberg’s shared block feature.

Now let us consider editor commands unique to Gutenberg. What first come to mind is Gutenberg’s  34 embed commands  which are not matched in the Classic editor. Yes, most are simple one line URL embeds which can be duplicated in the Classic editor; but do you know all 34 embeds possible in WP?   So here is a list of  Gutenberg’s unique blocks:

• Preformatted  block like Verse block preserves all your blank spaces, tabs and line breaks in a text block. To date  the Preformattted block has just 3 styling options;
• Cover Image block is like a hero block in PageBuilders, it provides a centered white color text over a big image which can be easily dimmed. It has 5 styling options;
• Custom HTML block bombed every time we tried to use it [Gutenberg 2.4.0];
• Categories block got lost into Columns block on setup. There are 3 styling options;
• Latest Posts block shows user choice of  number of latest blocks, in in latest to earliest or reverse order, and user choice of columns;
• Columns Experimental block bombed quite often. Columns Text block  worked well  with 7 styling options;
• Text Auto complete where /head becomes a Header block, etc.

So there are now 7 unique Gutenberg commands that a)go beyond what the Classic editor can do but b)barely start to match the scores of custom components available with the top WP PageBuilders. Also the styling options available in Gutenberg blocks are small in comparison to those available in the TinyMCE editor and only a fraction of what is in the top PageBuilders.

So is Gutenberg ready to replace the Classic editor?  Of course, the answer depends on the timing of its introduction.  As you can see there are still many bugs just in the unique new  Gutenberg  blocks listed above; and there were bugs to be found in the traditional edit blocks as well. So Gutenberg is currently not bug free. It is likely not  ready for another 8-12 weeks at the least [yet the first Gutenberg  beta  with WP 5.0 appears to be set for the first half of April 2018]. Also Gutenberg cannot match the text editing prowess of the Classic editor as seen in the following screenshot:

The Classic editor session shows how having many of the key styling commands  [bold, italic, underline, color, background-color, alignment, font-type, font-size, etc.] readily available on the command bar , results in quick styling choices. The only major missing styles are margin, padding, border, outline, and drop shadow.  But these stylings are also completely missing in Gutenberg but are featured in the top 6 PageBuilders. Likewise for features  such as special characters, emojis,  tables, ordered and unordered lists, links, dividers, Read-More breaks, plugin shortcode buttons, find & replace, plus paste without styling – all of these features are more accessible in the Classic editor than Gutenberg.

So it should be no surprise that the Classic editor has become a part of Gutenberg with a Classic Editor block which look like the following:
The Classic Editor Block brings TinyMCE into Gutenberg – well sort of as seen in the screenshot above. First, the Classic Editor block swings in and out of being buggy  and having an awkward interface. In addition, there is some uncertainty as to what features will be in  the Classic Editor block and for how long as seen here. But the WordPress Community has raised a number of issues about the immediate replacement goal as well as the long term site builder direction. Lets look at the official Gutenberg Roadmap.

Gutenberg Roadmap

Gutenberg has three planned stages. The first, aimed for inclusion in WordPress 5.0, focuses on the post editing experience and the implementation of blocks. This initial phase focuses on a content-first approach. The use of blocks, as detailed above, allows you to focus on how your content will look without the distraction of other configuration options. This ultimately will help all users present their content in a way that is engaging, direct, and visual.

These foundational elements will pave the way for stages two and three, planned for 2019, to go beyond the post into page templates and ultimately, full site customization.

To say the least this is a terse roadmap on the WordPress.org Gutenberg official page and particularly for stage two – Gutenberg’s role in creating Page templates and then stage three – taking on total Sitebuilder tasks. Most notable is the fact that the official roadmap does not acknowledge that the top group of 5-6 PageBuilders have each completed major portions of stage 2, creating user customizable and  interchangeable Page and Post templates without needing to sacrifice any existing WP functionality like custom post type, custom field, and metabox functionality [but rather enhancing them]. Likewise for Gutenberg stage 3, creating SiteBuilder capabilities in WordPress, again the same top 5-6 PageBuilders have advanced plans and actually achieved major breakthroughs on delivering such SiteBuilder capabilities well ahead of Gutenberg. Its as if Matt and Automattic leadership, as custodians of the WordPress Ecosystem, are reserving the right to have final say on how and when Gutenberg Stage 2 and Stage 3 are achieved. So lets look at stage 1, how Gutenberg is impacting current Classic Editing practice.

Again the official Gutenberg roadmap statement about some of the challenges posed by Gutenberg on the existing Clasic Editor attributes and processes is revealing:

Meta-boxes changes required by Gutenberg

• Some will continue to work with no changes under the new UI.
• Some will need updates particularly those that rely on the DOM for operating. Also certain meta-boxes that rely on the specific structure of the current editing screen are not guaranteed to work under Gutenberg, and might need changes before they can be loaded correctly.
• Several can be converted to native blocks (particularly those that are rendered on the front-end).
• Some can transition to new Gutenberg native extension points outside of the content area.
• There will be a mechanism for conflicting meta-boxes to load the classic editor instead with a notice.

But note the following recommendation  on the use of metaboxes in the Gutenberg programming guidelines.: This is a brief document detailing how meta box support works in Gutenberg. With the superior developer and user experience of blocks, especially once block templates are available, converting PHP meta boxes to blocks is highly encouraged!

In effect, as we shall see below  PHP is a second class coding citizen in Gutenberg’s JavaScript  framework because it forces users back to the server.

Shortcodes support

• Most will continue working without changes.
• There is a new “shortcode block” to help inserting them.
• There’s a planned mechanism for previewing them in place.
• The following blocks currently do not support direct short code imbeds: paragraph block, list block, pull quote block, heading block,  custom HTML block and both text columns & experimental column blocks.  But subhead block, classic editor block, preformatted block with styling bugs, table block, verse block with styling bugs – all of these support short codes.
• Gutenberg expects shortcodes to be replaced by GutenBlocks as seen here:  We see the block as an evolution of the [shortcode]. Instead of having to type out code, you can use the universal inserter tray to pick a block and get a richer interface for both configuring the block and previewing it. We would recommend people eventually upgrade their shortcodes to be blocks. Again a case of JavaScript replacing PHP.
• In general, paragraph blocks do not  embed shortcodes, but neither  images nor oEmbeds such as audio and video. This is a serious shortcoming.

Shortcode support is mixed currently – what will emerge upon release is not yet stated in a release roadmap.

Custom Post Types

• Are supported by Gutenberg.
• Need REST API (show_in_rest) declaration.
• Can opt out by not declaring “editor” support.
• Will be able to declare supported and default blocks.
• Runs into the PHP  Custom Post Type vs JavaScript GutenBlocks tradeoff

Custom posts, custom fields, full shortcodes, and metaboxes all have to be accommodated in the JavaScript dominated GutenBlock world of Gutenberg. It is a case of  working PHP vs JavaScript futures  as a principal trade-off.  But as well there are feature differences and simply learning new coding to replace already working PHP code. This is the crux of some developers resistance to Gutenberg imposed JavaScript code.

Accessibility Issues

• There are currently 78 open accessibility issues. Some are very difficult.
• There is a commitment by the  Gutenberg team to improve accessbility.
• And the 2.0 release of Gutenberg in January  marked major improvements.
• But issues like inline-styles and speech input  still remain on the to-do list.

Accessibility improvements  will be tough sledding  for Gutenberg developers whose attention  will be diverted to many other delivery issues .

Gutenberg’s Impact on Developers and End Users

At the WordPress Weekend there was an audience of seasoned developers. But even among these developers their use of Gutenberg varied widely. Can you imagine what the case will be among end users? Gutenberg will impose a substantial learning curve when it goes core in WP 5.0 in the July to October time frame. Assume all the bugs are removed at full release. But how the Gutenberg interface works is a new learning curve for most end users.

True, end users will have  available the Classic Editor block in Gutenberg ; but  will the Gutenberg Classic Editor block measure up?  Gutenberg will  be challenged to do a perfect duplication on its intro[only 2 of the top Pagebuilders do so after 2-3 years of development].  However, end users will have recourse to the Classic Editor plugin which will then allow breaking the Gutenberg lock on editing – and users will be able to resume editing files in the  comfort Classic editor.

Breaking the Gutenberg lock on editing by loading the Classic Editor plugin may be vital  for many end users and their  shops. As seen above many existing pages/posts with  metabox, custom field,  shortcode  and custom post types may require the Classic Editor for any clean update/editing operations. Ditto for pages/posts with inline styling and embedded JavaScript code. Finally tables and specialized CSS and SVG graphics may have to be converted to make them Gutenberg compatible. In sum, for end users adopting Gutenberg fulltime, this will represent a sizable learning and converting burden. Caveat emptor.

For developers and savvy end users they are already using a vastly better Visual Editor by using  one  of the top PageBuilders. The top 5-6 PageBuilders are already delivering WYSIWYG page/post/custom post editing  with dozens of UI components plus sophisticated  prebuilt and user custom designed page  templates . In addition the best PageBuilder offer a much better range of component features plus more CSS styling options  than offered by any of the GutenBlocks.

Even more important with  the Role managers available in many of the top 6 PageBuilders, developers can control the PageBuilder components made available to end users . This means each user can be given just the amount PageBuilder editing capabilities that they can safely handle.  So for savvy developers and users  why  worry about Gutenberg stage 1, the Classic Editor update? Because Gutenberg goes into the WPCore and becomes the default editor replacing the WP Classic Editor.

So in order to make WordPress work in the WordPress 5.0  world  and beyond,  savvy developers  will have to take actions to cope with the intro of  Gutenberg  Stage 1. Vital will be to load the Classic Editor plugin as a recourse when Gutenberg falls short, which it will. The Classic Editor plugin will allow users to switch from using the Gutenberg editor to  using  the more comfortable and PHP compliant Classic Editor. Next task will be  to validate the ability of the Gutenberg editor to handle  existing  pages and posts  with minimum disruptions. Finally, given thecurrent mix of themes and plugins used on a website, developers + end users will have to decide what new pages and posts can be safely handled by the Gutenberg Editor  Depending on the size and reach of each WordPress website,  this adaptation process can be substantial.

Another 2 factors to take into account is how Gutenberg  will specifically  impact WordPress software developers like Elegant Themes, Thrive, WP Bakery, etc. First, Gutenberg represents a substantial replacement of PHP by JavaScript in the WordPress client UI. Already with Calypso and the Rest API, Javascript has become a major player in WP Admin as Calypso extends well beyond a local WP installation by handling  admin, editing and viewing of  multiple WP websites from one admin client. The Rest API is coded in other languages like Python but works fastest with Calypso and Gutenberg on the WP Client. Automattic tools like WooCommerce and Jetpack are also moving towards more Gutenberg content. In sum, WordPress developers, especially plugin designers,  become the servant of two coding masters – advanced JavaScript as well as PHP. One of the questions asked at the Toronto Gutenberg meetup was how many of the attending developers were coding in PHP and how many  were trying the new Gutenberg JavaScript, and how many using both.  The answer to the latter was very few.

The second major change in WordPress is the ongoing replacement of themes by customizable Sitebuilders. This is already happening with the top 5-6 PageBuilders transforming themselves into Sitebuilders ahead of Gutenberg Stage 3. The role of WordPress  themes will surely be diminished as SiteBuilders takeover more of the role of page and block templates plus establishing  sitewide settings for color, typography, spacing, etc. Plugin developers will  now compete with PageBuilder, Calypso and Gutenberg components  that duplicate large portions of their functionality. This raises the question of how  long will WordPress be  famous for having 10,000 themes and 50,000 plugins?

Summary

In March of 2016 the Elementor PageBuilder was first released  and 9 months later it had achieved nearly 100,000 active users [2 years after its intro, Elementor now has 600,000 active users]. In June of 2017 Gutenberg beta was released and roughly 9 months plus  ten upgrades later Gutenberg Editor  stands at 8000 active users. Yes, Gutenberg is beta – and an ambitious beta as it seeks to duplicate much of the functionality of existing top PageBuilders.  Some would argue that Gutenberg Editor interface resembles current PageBuilder layouts ever more closely.Yes, Gutenberg brings the superior runtime performance of JavaScript GutenBlocks  to WordPress development.

However, the bottom line for Gutenberg Editor and its broader Roadmap:

1. Gutenberg Editor is at present is not “better replacement” for the Classic Editor supported by TinyMCE Advanced or WPEdit plugins;
2. Gutenberg Editor is well behind such popular frontend, WYSIWYG PageBuilder editors as Beaver Builder, Divi, Elementor, etc;
3. Gutenberg Editor ‘s intro into the WordPress Core also brings substantial task loads  for WordPress users, developers and software developers of WordPress tools.
4. Gutenberg Stage 2 page templates and blocks is even further behind the state of the art being delivered by the top  Pagebuilders;
5. Gutenberg Stage 3 evolving into SiteBuilder capabilities is also substantially behind what is being achieved now by the top PageBuilders.

Hence our caution –  WordPress Gutenberg Looms Large . More ominous is the ability of Automattic to coerce or compel premature decisions along the Gutenberg Roadmap – use of alternative JavaScript frameworks to React.js  in GutenBlocks like Ember, Preact, or  Vue  and the role of PHP vs JavaScript in the client interface are just two issues that come to mind.

Gutenberg Resources 

• Gutenberg Plugin Page at WordPress.org
• The Gutenberg Editor
• Gutenberg, or the Ship of Theseus, with examples of what Gutenberg might do in the future
• Editor Technical Overview
• Design Principles and block design best practices
• WP Post Grammar Parser
• Development updates on make.wordpress.org
• Documentation: Creating Blocks, Reference, and Guidelines
• Additional frequently asked questions
• Ithemes Thoughtful Gutenberg Coverage
• Yoast: Gutenberg an Alternative Approach
• Organic Themes: Detailed Code on creating a non-trivial GutenBlock
• Gutenberg Marketing Problem
• Puckishly announced, Elementor Blocks