WordPress Gets New Gutenberg Editor: What You Should Do as a Developer[UPDATED]

WordPress, the go-to 15-year-old content management system (CMS), still grows and experiences significant changes and improvements. During the last 2 years, 5 major versions have been released. Their focus was on editor, customizer, widgets and other minor improvements of UX. I would describe these improvements, released after the REST API in WP 4.4, as well-liked by both ordinary users and developers. However, the release coming very soon is a major fundamental change of the core WP experience, content editing. This change affects every WP user. For years, WP relied on tinyMCE editor, which is a quasi-WISIWIG editor with an extensible list of buttons to add and edit rich content. Now, the core team behind WP has set a kickoff goal: to create a completely new post and page editing experience.

Need to adapt to these changes and stay up-to-date

As a plugin or theme developer, you may consider how this will affect your business generally and your products specifically. The introduction of Gutenberg editor initiated a big concern among many WP users and especially developers. It split the community into opposing camps. Very few developers or people in WP community had a balanced view on Gutenberg. Reviews of the Gutenberg plugin in WP plugin repository demonstrate this point clearly: while in April Gutenberg plugin had only 4000 active installs, now the number has gone up to 100000+, the more than 300 reviews (as of Feb 2017) have been replaced by 945, 57% of which being 1 star and 21% of them being 5 star reviews. 

By examining the reviews, one can draw a conclusion that among those criticizing the new editor, there are many developers, whose intentions are driven by the concern for their business. So it is crucial to consider how plugin and theme developers can adapt to this new editor by making their products compatible with it. Moreover, how we can really make the best use of the new editor and create nice and popular solutions based on Gutenberg?

Yes, rather than viewing Gutenberg as an annoying painful update forcing us to come out of our comfort zone to adapt to it, why not view it as a real opportunity to get ahead of the competitors? Why not let your product reach the next level of quality and capability? As time showed and will show, in the end only those staying up-to-date survive and thrive.

Let’s discuss these points. First, we’ll see how Gutenberg affects WordPress core, plugins and themes. Then we’ll consider technical details, and in the end, try to peer into the long-term future of WordPress and its ecosystem.

How Gutenberg will change the game

What is Gutenberg?

Gutenberg is a new editor for WordPress, “a new editor for the next 12 years,” as promised by the developers’ team. The intention behind introducing the new editor is keeping WordPress innovative and competitive among other CMS platforms. The goal is to make core WP experience intuitive and enjoyable for all users. Gutenberg is not a page builder, but it is definitely more than just a content editor. Its UX is based on blocks and not text, as it is in the current tinyMCE editor.

“The editor will create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.”— Matt Mullenweg

Blocks are basic pieces of content. They can contain text, HTML, media, shortcodes, widgets, and other structures. Blocks are an attempt to unify multiple different interfaces of content creation into one standardized interface. With a common, reliable flow for creating any kind of content, there’ll be no need to learn how to create shortcodes and write custom HTML or insert widgets.

How it affects UX

Blocks are easier to handle than text with embedded media or shortcodes. While this is not a full WYSIWYG experience, it’s quite intuitive if properly integrated with backend styling. Layout customizations are easier to do using block and not text editor. It is notable however that Gutenberg is not a drag-and-drop editor, similar to WIX editor or most of the page builders. Its experience also differs from the UX of traditional office editors, such as MS Word.

When and how it will be introduced into WP core

It’s important to have a look at the timeline of Gutenberg development and releases. The first stage of its release focuses on the post editing experience and block implementation. It will be shipped with WordPress 5.0. Right now, it’s a standalone plugin, which should be merged with the WP core. The exact date of WP 5.0’s release has not been announced yet. Initially Matt Mullenweg had given an estimate of April 2018, however the estimate wasn’t met till today and there is still some work to do before the official release. The plugin is being actively developed right now by a dozen contributors. So, regardless of the delay that happened, the release can hardly be extensively delayed and will come out the latest by the end of this year. Reckoning with this roadmap, you need to make all the necessary changes to your plugins and themes to have products fully compatible with the next major version of WordPress.

Gutenberg vs Page builders

Before considering the effects of Gutenberg editor on plugins and themes, we’ll discuss Gutenberg’s relation to page builders. This is a natural question, because both Gutenberg and page builder plugins are used for the same goal of content creation. Initially, there were some concerns regarding Gutenberg. People claimed it was “yet another page builder” or that “WP’s set to have its own page builder.” Some even considered the new editor a “page builder killer.” If it were so, it would mean a major shake up in the plugins’ directory and in the multi-million dollar businesses built around premium themes and plugins. The deeper analysis of the new editor suggests however, that even if this happens, it will not be soon. Page builders will dominate in some niche of content creation at least for the future few years. Below is a comparison of Gutenberg features and UX with those of popular page builders.

 

Feature Gutenberg Page Builders
Main usage Editing content only (stage 1 – 2018) 1 Editing content only 2
Main element of content Extensible blocks with a small number of defined attributes Essentially blocks with attributes 3,4
UI Minimal interaction with tools, more focus on content, resembles front-end editor. Some blocks are previewable in backend. Large variety of interaction elements depending on builder. Some builders provide full front-end editors with mobile UI, others only preview.
Drag-and-drop Yes All the major page builders have
Reusable blocks Yes Some builders have
Nested blocks and columns Planned (experimental) Supported
Classic editor compatibility Classic editor content can be fully converted to Gutenberg.

Partially convertible to Classic editor.

Usually classic editor content is partially convertible to builder’s content.

Usually not convertible back to classic editor

Lock-in effect Weak lock-in effect because content is partially convertible to Classic editor. Strong lock-in effect
Stored as Semantic HTML comments in the post content Shortcodes in post content or metadata

Notes:

  1. Visit Gutenberg project for stages two and three
  2. Some builders started to go beyond page content creation, see for example Elementor’s blank canvas
  3. Some builders have extensible blocks and attributes and offer more blocks and attributes as a premium feature or as free additional plugins
  4. The number of free blocks and attributes in page builders varies greatly 

How it affects plugins and themes

Gutenberg is a big change, and there are several key areas you need to check to make sure your products are compatible with the new WP version. The new editor affects not only the shortcodes, but also all the content generated via the editor. Besides that it also affects the metaboxes and custom post types (CPT). WordPress themes modify Gutenberg appearance via editor styles. The Gutenberg Plugin Compatibility Database -a crowdsourcing tool to identify whether or not WordPress.org plugins are compatible with Gutenberg, is constantly being updated. The good news is that most of the top  plugins have already been positively tested and claimed to be compatible with Gutenberg (however for example jetpack was stated incompatible on the base of a missing a UI editor).

Technical

Gutenberg blocks are higher-level than HTML. They are stored in the content as HTML with semantic comments. These semantic comments in turn contain serialized attributes of blocks. A typical example of Gutenberg content looks like this:

<!-- wp:paragraph {"backgroundColor":"#7bdcb5","fontSize":15} -->
<p style="background-color:#7bdcb5;font-size:15px" class="has-background">new paragraph<br/>As a new WordPress user, you should go to <a href="http://example.com/wp-admin/">your dashboard</a> to delete this page and create new pages for your content. Have fun!</p>
<!-- /wp:paragraph -->
<!-- wp:image {"id":21,"width":578,"height":386} -->
<figure class="wp-block-image" style="width:578px"><img src="http://example.com/wp-content/uploads/2018/02/daniel-von-appen-262818_1.jpg" alt="" class="wp-image-21" width="578" height="386" /></figure>
<!-- /wp:image -->
<!-- wp:shortcode -->
[my_shortcode]
<!-- /wp:shortcode -->
<!-- wp:latest-posts -->

This content is rendered on front-end and in the editor itself via PHP and JS parsers.

Detailed guidelines for creating blocks are available in the Gutenberg handbook. Here we’ll just discuss the key points and applications.

We can create blocks using registerBlockType PHP function and pass callback for rendering block on front-end as one of the arguments. JS function registerBlockType is used to control block appearance and interaction with it in the editor. Pass block attributes title, icon, and other parameters as arguments.

Steps to make sure your plugin is compatible with it

Shortcodes

We can leave shortcodes as they are without converting them, because the new editor has a block named “shortcode” by default. Basically, it’s an input field where users can paste any shortcode and it will be rendered normally on the front-end. However, it is much better to convert shortcodes to blocks in order to make the best use of Gutenberg blocks. Each shortcode becomes a block, its attributes convert to block attibutes with corresponding input fields for editing. This way the shortcode will not be hidden as an anonymous shortcode, but rather will appear in the list of blocks.

Editor buttons and Media buttons

Gutenberg does not include tinyMCE editor. It has only a paragraph block with some basic formatting buttons, media embedding blocks, as well as custom HTML block. The last one’s just a text area for pasting HTML code. So, the editor buttons and media buttons of the old editor disappear. Turning the content generated via these buttons to blocks is the easiest and recommended solution.

At 10Web, we have dozens of plugins generating shortcodes using editor or media buttons. On click, they usually rendered an iframe with forms. For example, our Photo Gallery has a large form with many inputs and buttons to customize shortcode parameters. Instagram Feed WD has a small popup with a list of feeds to select. In both cases, we converted them to blocks. Upon clicking on the block, the old iframe with the form still opened in a popup, but instead of pasting shortcode into the content of editor on form submit, it returns shortcode as a block parameter, and the block saves it after that.

Meta boxes

Gutenberg supports meta boxes although it may break some of them. Meta boxes, previously placed in the side area, have been moved to sidebar → document → extended settings area. If a meta box is under the content, it will stay there. First check if the meta box is still visible in all post types, as it previously was. Each meta box may or may not explicitly declare or undeclare its support for the new editor. Meta boxes conflicting with Gutenberg and undeclaring their support are allowed to force a fallback, that is to revert to the old Classic editor, where they will continue working as before. Of course, we’d like to keep backward compatibility, because in case one of several meta boxes reverses the WordPress screen to the Classic editor, others should continue to support the old editor as well.

Some plugins making updates to editor page DOM on “submit” or “save” may break, because Gutenberg has a different mechanism of saving meta boxes’ data. Also, be careful, if you have a plugin targeting any selector of the old editor or any specific element on that screen. These elements may not exist anymore or may have another selector.

Widgets

Because rendering of widgets is theme- and template-specific they will continue working normally. However, Gutenberg editor provides a nice opportunity to make widgets easier to discover and facilitates their move to content. Turning widgets also into renderable blocks helps achieve that goal.

Editor styles

The block styles in the editor are customizable. Blocks can have their own overridable admin styles or rely on theme styles. Themes provide styles using the editor style feature, which already exists in WordPress. In the new editor, this stylesheet has more importance than in the classic editor, because Gutenberg may render blocks in back-end, too. Of course, you’d like to make blocks in the editor look similar to what users see on frontend. Indeed, better UX of content editing, similar to what front-end builders provide, will be an asset for your theme.

Custom Post Types

Gutenberg already supports custom post types (CPT), however this feature needs to be refined. There are still some open issues regarding merging with core, custom taxonomies, custom post statuses and REST API. You may consider Gutenberg support for CPT in your plugins for several reasons:

  1. to allow blocks in CPT content;
  2. even if CPT does not utilize editor, you may benefit from improved performance of metaboxes in Gutenberg;
  3. to provide unified UX when editing CPT.

 

How to make extensive use of Gutenberg UI

Blocks API

Gutenberg uses blocks API to create, extend, and customize blocks. You may review all the content elements created by your plugin to see if it is beneficial to convert them into blocks. If the element is visible on the front end content, it may be considered a block. For example, even if a gallery is usually not placed in the post/page content, it may turn into blocks, too. Another example is widgets or menus, usually displayed in header, sidebar or footer. What should prevent inserting a similar element into content? Also consider some page-specific elements such as featured images. They can be normally customized using metaboxes but turning them into blocks lets you place them anywhere you want in a user-friendly way.

Fields API

One of the unsolved issues with Gutenberg is Fields API, a toolset provided to create standardized fields for customizing blocks attributes, document properties or metaboxes. Right now each plugin is responsible for rendering the block editing experience which results in an inconsistent interface and surely unpleasant UX. Essentially, most of the customizable blocks have some form with fields organized into groups, sections or tabs. With the possible introduction of fields API, we can finally create a unified editing experience, extensible fields, and more blocks relying on REST API.

Open questions

After Facebook relicensed React under the MIT license, the question of framework choice for Gutenberg has been resolved. Although the developers declared their intention to keep Gutenberg framework-agnostic, it uses React to render blocks. Therefore, taking into account that Gutenberg is still under development and needs more time to become a stable and mature component of WP, we’d recommend using only React to make your products compatible with Gutenberg. Gutenberg already has the reusable blocks feature. The next major step to wait for is allowing reusable pages or templates.

Future trends for plugins and directory

Incompatible plugins

After the release of WordPress 5.0, we expect many plugins to remain incompatible with Gutenberg. Not keeping your plugin up-to-date will have a drastic negative effect on its usage. After updating WordPress to the latest version, users may suddenly discover that some plugins fail, fail badly. And they’ll have to switch to new ones. There’s an additional factor: Plugins in the WordPress directory have a “Tested up to” parameter indicating their compatibility with the latest WordPress versions which affects their search ranking. Incompatible plugins will not only lose their installations, but also fall behind in search results, accelerating their abandonment.

Blocks and templates for Gutenberg

The release of Gutenberg will trigger the development of new free and premium plugins for creating blocks and templates. At the last stage of Gutenberg development, when themes will fully support Gutenberg templates and blocks, we’ll see a rise in new WordPress block-based themes.

New players

Gutenberg is definitely a large leap forward for WordPress. After its UX has been perfected, Gutenberg will finally be adopted by the WordPress community. It is the default editor. Whether or not one approves of it, Gutenberg will be the most used editor among millions of WP users. A few weeks ago, Alberto Medina, Developer Advocate in the Web Content Ecosystems Team at Google announced Google’s WordPress vision, which addressed contribution to Gutenberg development and close involvement in support and development of WordPress-based tools and platforms. We have to reckon with the new editor. In the long run, the products failing to keep up with the new editor will be abandoned, making place for new players. Gutenberg will keep WordPress innovative and will open a wide door for new products and content creation services based on WordPress.

Tigran is a product owner at 10Web with a strong past experience in web development and science. Currently his focus is on making 10Web products and website better, more innovative and easier to use for everyone.

Leave a Reply

Your email address will not be published. Required fields are marked *

Cancel reply