WPTavern is the watering hole for the latest news on WordPress. As the Gutenberg Editor approaches Release Candidate in early November and the WordPress 5.0 Launch, there are some roaring debates going on at WPtavern. This is not quite Justice Kavanaugh stridency, but beyond the normal WP civility norms. As an example, the topic of WordPress Theme and Plugin Shops are Pioneering the First Layout Blocks for Gutenberg tripped off a number of comments. Here is the gist of the report. “The first iteration of Gutenberg focuses on blocks and the post editing experience. After Gutenberg is in core, the project will move on to the second phase – full site customization. This will venture into page builder frontend layout functionality. Matt Mullenweg predicts this phase will happen much faster than phase 1 since all of the infrastructure is already in place.”
The article goes on to cite Gutenberg Container Block tools built by Mary Comet, Fred Arntz, and Marc Lacroix. And PootlePress has two Gutenberg plugins Caxton and then Storefront Blocks. But perhaps the most impressive is Kadence Blocks – Gutenberg Page Builder Toolkit as seen below:
Kadence looks like the 2-dimensional front-end tool that many were expecting Gutenberg to look and work like right out of the gate. Three observations come immediately to mind.
First, as others have noted much earlier, Gutenberg is beginning to look like just another PageBuilder but from about 2 years ago. Yes, Gutenberg is that far behind the top WordPress Page Bulders. Second, it appears that just like 5 years ago when 3rd party PageBuilder tools like Themify Builder and Visual Composer came to WordPress’ rescue when Website Builders had building momentum. These 3rd party PageBuilders helped to stem the rising tide of Website Builders. Today, Gutenberg is getting the same boost and benefit. An unpopular Gutenberg Editor [its ratings dropped from 2.48/5 rating in April 2018 when 30,000 users had tried Gutenberg to 2.32/5 rating today after 500,000 users have tried it] is buoyed by the 3rd party Gutenberg plugins that are inevitably creating rival blocks to the Gutenberg core set.
Third, instead of duplicating the already effective 3rd party PageBuilder, why didn’t WordPress set the standards for theme customizations, standards for UI widgets with their necessary features and interoperability, standards for page and section template libraries and conditional behaviors, and standards for the CSS styling and Animations attached to each widget. Or was it necessary to create Gutenberg, even a limited 1 dimensional Gutenberg, in order to discover and establish these standards?
What is really interesting is that established PageBuilders like Beaver Builder, Elementor, Site Origins and Themify Builder [all of which are using JavaScript engines] have pledged to have Gutenberg interfaces and/or plugins. How will these work is the $64,000 question.
Gutenberg 3.9 Introduces Reusable, Exportable Templates for Multiple Blocks
This is the second WPTavern debate with vigorous comments and concerns. The gist of the article is about new features found in the 3.90 release of Gutenberg. “Gutenberg 3.9 was released last week with a new feature that allows users to group multiple blocks into reusable templates. The templates can also be exported and imported as a JSON file. The idea of reusable templates is an expansion of the concept of dynamic reusable blocks that Gutenberg technical lead Matias Ventura proposed in June 2017. Reusability is even more powerful when applied to multiple blocks. The import/export capabilities make it possible for multi-block templates to be easily shared across WordPress sites.”
Now one would think a templating feature like this would be greeted with open arms. But …” what happened with the feature freeze plan? it seems that GB keeps adding new features” and ” Exactly what I was thinking. Clearly and regrettably, Gutenberg is going off the rails. How about fixing the problems before release like making multi-column blocks responsive?” and “Gutenberg, has some nice ideas, looks nice, but underneath very clunky, clumsy and badly implemented…not very useful. To boot, widely surpassed by many, many page builders already on the market.” This echoes others views on Gutenberg’s duplication of tools already available. To be sure there is positive feedback …”Wow, I can see how this would be very useful to create simple items like an “accordion block” Just add an open/close mechanism and you’ve got a fly out of text at the click of a headline.”
But perhaps the most interesting observation was made by a non-Developer, David Bennet. “At the moment, Gutenberg is a plugin. … others have made additional blocks that are available as plugins. When Gutenberg goes into core, I will want to use some additional blocks …If that block is in a collection of blocks available as a plugin I could add the plugin…but I could then end up with many plugins, really only wanting just one or two blocks from each plugin, and perhaps lots of repetition because the different plugins cover a lot of the same ground.
In an ideal world, I don’t want extra plugins on my site if they don’t need to be. Is there a way I could extract the blocks I want, keep them and remove the plugin? Would reusable templates enable me to do this?
The answer to David’s question is threefold. First, YES, templates would help you to avoid having to buy/acquire plugins with unnecessary blocks. But as we have already seen in the first debate, there are non-core 3rd party Gutenberg plugins being developed that have blocks which are superior supersets of the core Gutenberg blocks. This means super-duplication is inevitable So many plugins with blocks will proliferate in the market. This echoes the phenomenon that has already happened with popular PageBuilders like Beaver Builder, Elementor and Visual Composer. They have many third-party libraries of widgets that overlap each other.
Second, as a vigorous PageBuilder template user, I find the need to create specialized plugins, shortcodes, custom post types, and/or custom fields has diminished notably as I can use specialized PageBuilder templates. Third, the rules of the road or standards for template usage are being determined “dynamically in the marketplace”. For example, there are some templates I want to reuse with no link back to the library template. There are other templates that I want to be global – any change to the template will be reflected in all page/posts that use the template. Next, I want some global templates to be changeable in an “unlocked” and local fashion. This means that you can make content changes or styling changes to a template used in a specific post/page and those will be local to that one use of the template. Meanwhile, this same post/page template accepts global changes made to the library’s copy of the template. Last, shades of shortcodes and handlebars.js , I would like to be able to pass parameters when a template is invoked.
WordPress on the UI front would be better to act like W3C for Web Standards. Thus WordPress would assemble recommended standards for widgets/blocks behavior, use of styling options, and behavior as a template. This is what Apache does for its open source apps. Also, WordPress should work to help integrate 3rdParty tools and code with Gutenberg and the WordPress core more effectively.
Major third-party developers like Beaver Builder, Site Origin, Themify Builder among others have announced plans to work with Gutenberg. But there are two problems. The PageBuilders are all 2D frontend tools while Gutenberg is still 1D, vertically-only drag & drop oriented. Worse, there are responsive and other bugs/glitches to some of the critical Gutenberg blocks. The net result is that the grapevine indicates that major PageBuilders are having probems with their interfaces to Gutenberg. If that is so, then talk about biting the hands that have stemmed the out-migration to Squarespace, Weebly, Wix and other popular Website Builders. Here are the current trends:
CMS trends in worldwide usage on 10 million Alexa websites is very illuminating for how these vendors are doing:
| CMS | AUG 2017 | AUG 2018 | 1YR % CHANGE |
|---|---|---|---|
| WordPress | 28.4% | 31.5% | 11% |
| Joomla | 3.3% | 3.1% | -6% |
| Drupal | 2.3% | 2.0% | -13% |
| Squarespace | 0.6% | 1.2% | 100% |
| Wix | 0.4% | 0.8% | 100% |
The Website Builders, Squarespace and Wix, are growing at ten times the speed of WordPress.
And WordPress cannot be dismissive of the use and presence of the PageBuilders among WordPress Users:
| PageBuilder | Builtwith LiveUsers | WordPress Actives |
|---|---|---|
| Beaver Builder | 185,000 | 500,000+ |
| Divi | 1,192,000 | NA |
| Elementor | 716,000 | 1+ million |
| SiteOrigin | 826, 000 | 1+ million |
| Visual Composer | 4,226,000 | NA |
| WordPress | 29,384,000 | NA |
The numbers how that roughly 25% of all WordPress websites use one of the top 5 PageBuilders. This is a sinificant marketshare for PageBuilders
Summary
The debate is a little tardy, but because Gutenberg itself is late. This situation has prompted several arguments on how Gutenberg should be structured and deployed. The simple facts are that Gutenberg does not come close to matching the PageBuilders’ feature sets and that 3rdparty tools are rushing in to fill the gap between Gutenberg and what existing PageBuilders can readily do. What makes the situation more volatile, is that Gutenberg is still changing and so too the rules of Gutenberg deployment and interaction of PageBuilders tools with Gutenberg
”