The Future of WordPress Plugins with Gutenberg

Gutenberg! The future editor of WordPress that will help us write posts, create beautiful layouts and finally get rid of the infamous page builders. Well, at least that’s what they’ve promised us, because even though it looks very nice, it’s still pretty green.

If you don’t know anything about the project (are you serious?), there’s plenty of reviews out there discussing the pros and cons of it. The Gutenberg review at WPLift is a pretty good introduction to the project:

Gutenberg offers a completely different take on the default WordPress Editor. Instead of one long input box that basically acts the same as a Word document, the Editor is now broken up into individual blocks. One block may contain several paragraphs of text, another an image, and another a button. So and so on.

(…)

I think Gutenberg is an improvement for casual users who like to write their content in the WordPress Editor. But as someone who writes and uploads multiple posts per day from Google Docs, I don’t see any benefit to Gutenberg based on how I work. All it does is make it a heckuva lot harder to bring in content from something like Google Docs.

Colin Newcomer – WPLift

So, it brings a new paradigm for creating content (blocks), which might be an improvement for casual users. But such paradigm shift might not be what you need. Only time will tell us if Gutenberg was the right decision or not—I personally think and hope it will, for it’s an interesting idea with a lot of potential (an opinion shared by some of the people we’ve recently interviewed in our blog, like Caspar or Alice).

Be that as it may, Gutenberg is clearly a hot topic and we couldn’t let another week go by without discussing it. As I just said, it’s a promising project, but there are some issues that concern us. Specifically, integrating plugins (yes, I’m thinking of Nelio Content and Nelio A/B Testing) with the new editor looked complicated until recently…

Gutenberg—The New Editor

The current WordPress editor is an old acquaintance. Although it has received some face-wash in recent years (especially with the advent of WordPress 3.8 and the integration of the MP6 project), truth is it’s still the classic TinyMCE-based, WYSIWYG editor, with its toolbar at the top and a style that tries to imitate what our users will see when they access the post:

Gutenberg changes the paradigm completely and “modernizes” the way we write posts. As we’ve just seen, the main novelty of this editor is that all the post’s copy is organized in blocks: a paragraph, a quote, an image, a gallery… all independent of each other, with their own contextual editing tools and with the ability to move them around easily:

As you can see, Gutenberg has a much cleaner and more minimalist interface than the classic editor. I personally love this design, because the simpler the user interfaces, the better—a prettier UX will help WordPress to attract new users and to re-engage the less active ones. But, as pointed out by Colin at WPLift, it radically changes how we create content, so I still don’t know if professional copywriters will welcome Gutenberg or would rather keep using the old editor.

Today, though, I’m not interested in reviewing Gutenberg and its functionalities again. Instead, I want to focus on something very, very important for the WordPress ecosystem—the integration of WordPress plugins with the new editor. In case you haven’t noticed, the WordPress edition page doesn’t just include the editor—it’s full of boxes with extra functionalities. Many of these boxes are features included by your plugins, such as the Social Media or References boxes added by Nelio Content:

Integration Problems—Editor (Meta) Boxes

The first versions of Gutenberg didn’t deal at all with the meta boxes issue (it wasn’t a priority) and there simply was an issue in the project’s Github repo commenting on the need to integrate them at some point. The problem of such integration is that it’s much more complicated than it seems. On the one hand, we have that Gutenberg‘s development team is using quite modern technologies for its implementation (basically, they’re writing everything from scratch with React, a JavaScript framework), so porting the current meta boxes (defined in PHP) to the new editor can be quite complicated. On the other hand, the project didn’t define where and how we would put those boxes either (remember that nowadays there are basically two possible areas: smaller boxes on the side and bigger boxes under the editor).

How can we solve all this? For now, the Gutenberg team has prepared an area (Extended Settings) under the editor where, in theory, we can put our boxes. In fact, a couple of days ago the team announce that Gutenberg 1.5 includes “an initial pass at supporting existing meta-boxes without intervention”. This is clearly a great step forward, but it made me realize that Gutenberg is actually reinventing the wheel and going back to what we already had: an editor with extra meta boxes around it. Therefore, was it really necessary to rewrite all the post edit screen?

A few days ago I was reading Yoast’s blog and saw that the issue of integrating plugins with Gutenberg is something that also worries them. In their post, Joost highlights what I’ve just told you: Gutenberg and block editing will revolutionize WordPress, but its implementation doesn’t have to change the entire UI all at once. In fact, it would be enough to change the editor itself from the classic TinyMCE to Gutenberg and keep the editing screen as it is, with its “old” concept of boxes around it:

With this proposal, we are looking at a more familiar and fully backward compatible interface (at least on paper—the truth is that I don’t know if there would be any problems at the internal/implementation level). Following the idea of Yoast, it’s very simple to think about how a plugin like Nelio Content could look like inside Gutenberg:

Undoubtedly, a simple, elegant and functional solution. The only drawback that some people might see is that we are not really “innovating”—we’re still with the same old solution and, therefore, with the same old problems. But I sincerely believe that this is not an inconvenience, but a virtue. Using this type of solution allows us to introduce Guntenberg taking baby steps, replacing the components one by one: first the editor, then the boxes, etc.

If you’re interested in seeing some “innovative” solutions, there are some in Github that somehow eliminate the “meta box” concept and integrate these “additional adjustments” into the editor itself:

but I’m not particularly attracted to them… there’s too much information (front and back end data) in the same component!

The Power of WordPress as a CMS

If WordPress is where it is today, it’s thanks to its enormous versatility. WordPress has been more than just a blogging platform for many years now, so we can’t redesign its editor based solely on blog entries (which is what Gutenberg looks like at the moment). For example, Kevin Whoffman shares the following screenshot of a quite common UI for custom post types:

As Kevin tells us, we are dealing with a personalized content that depends solely and exclusively on custom fields. This type of content does not even have the classic WordPress editor, so what’s the point of using Gutenberg? How could we adapt this to Gutenberg‘s current proposal?

Registering support for Gutenberg in CPTs has not been confirmed, and honestly it feels more like avoiding the problem of meta boxes rather than solving it.

Kevin Whoffman

Using Yoast’s solution, this scenario wouldn’t be a problem—we’d still have regular meta boxes and the (Gutenberg) editor would still be optional.

That being said, I must confess that the current solution of the boxes doesn’t convince me completely either—you can end up with so many boxes in the edit screen that the goal of “being simple” simply vanishes. One possible solution to this explosion of registered meta boxes is using views for grouping them. The current Gutenberg editor allows you to switch between a visual editor and a text editor, through a small menu in the upper right corner (in Yoast’s proposal it is in the upper left corner):

Well, we could add new “views” in that menu so that the interface presented to the user (that is, so that the set of boxes/tools they see) depends on the view they’re using at any given time. The set of views available could entirely depend on the plugins or be pre-set in 4 or 5 main categories. For example, I’d start with something like this:

1. Visual Edit. Here we would have the visual editor along with the typical boxes: categories, tags, publication, and so on.
2. Raw Edit. In this type of editing, we would have by default the text editor/HTML, along with, again, the boxes in the visual editor (yes, the same box could appear in multiple views). In custom post types such as Kevin’s, there would be no option to select the Visual Edit view and the Raw Edit would not include the text editor—it would only offer the box created with Advanced Custom Fields to edit the meta fields.
3. Analytics. Here we could have boxes like the ones included in Nelio Content, with information from social networks, Google Analytics, Yoast’s quality analysis, and so on.
4. Social. Boxes that deal with reader interactions would appear in this view: social messages from Nelio Content, WordPress comment boxes, etc.
5. Meta. Here you’d find any other boxes that don’t fit anywhere else.

What do you think? Which ones would you put?

Nelio A/B Testing

I was very impressed by the quality of this plugin, how easy it was to set up, and the outstanding support Nelio provides. I highly recommend Nelio A/B Testing.

Josette Millar

WordPress.org

View Plans

In Summary

Gutenberg is a very ambitious project with a lot of potential. The idea of blocks is fantastic and, although it may have to be polished, I think it’s the future of WordPress. The only problem behind it is the fact that it aims to change more things than needed.

Gutenberg has not yet been able to give a convincing answer so that plugins can be integrated. Many solutions are being considered in the project’s Github to guarantee backwards compatibility. Some people want a step-by-step integration, replacing the different components of the editing screen little by little. In this sense, I believe that Yoast’s proposal is the most realistic and effective, precisely because it’s the most conservative.

I understand that the Gutenberg team wants to take WordPress to the next level and, therefore, they feel that it’s a good time to “start from scratch”. But I think we have to be careful, and that’s why I propose the idea of views as a formula to “change what we have while keeping everything unchanged”. That is, I keep the WordPress boxes, but add order and cleanliness with the views.

What do you think?

Featured Image by Mr Cup / Fabien Barral via Unsplash.