Take a breath is a long article!
Seems that I am famous for online ranting about wrong decision in open source, the last post about it was for Mozilla and Firefox (that got a lot of discussions online).
Often people that read my articles doesn’t know who I am (with false claiming about my experience or OSS knowledge) and my contribution to open source (I write monthly reports since 2.5 years), I wrote also a free book about contributing (check the sidebar) and I most famous for my contribution to Mozilla but also for WordPress.
In this world I am the author of GlotDict, the browser extension to improve the localization experience in translate.wordpress.org, for 4 months I lead in 2019 the WordPress Italia Community team, I am one of the maintainers of VVV, contributed to GlotPress, contributed on WordPress core since 5 years, co organized 2 meetups Rome/Terni in Italy during the years, co-organized a Wordcamp (WordCamp Rome 2018) and a lot of other things.
I am also one of the co-founders of the ClassicPress project, fork of WordPress, but I left the council team for lacking of Open Source experience from others in the project.
Sorry for this explanation but I have to do it or this article will be misunderstood or ignored. I will talk just about the wrong things because not everything is bad (in WordPress) like adding support for the new PHP features after PHP 5.6 as minimum version (but this doesn’t involve Gutenberg).
The last time
I wrote an article in may 2019 about all of this (I suggest to read it before continue), it was interesting to see the Joomla community took it as example on how to no implement a Rest API in a CMS. As today all the problems reported are still there, because addressing the data leak in the rest api means to change a lot of things and there aren’t so many contributors (and the focus is on something else).
So I don’t want to talk again about the technical issues about the content schema (why not JSON instead of this mixed garbage with a parser written twice in JS and in PHP?, we already have one for shortcode that is not perfect).
As for my opinions about Gutenberg and the WordPress project management (and also for my ClassicPress involvement), I was getting put outside about some community tasks. Anyway I am a developer I don’t care, as I thrust in meritocracy my actions, real explanations about how this tech works and my projects will speak for me. Probably they will do better because my italish ehm English is not so good.
At this day
The plan is still moving on with implementing Gutenberg blocks as widgets and in other parts as said in the last Matt’s keynote but this is going very slow (like everything since the Gutenberg appear).
At the same time, because of Covid-19, the latest release of WordPress was delayed with a lot of release candidates, a lot of bugfixes (finally some patches by me after 3 years got merged) and getting a more stable release. It was surprising for me to see a lot of pre-releases including bugfixes (more then usual). As a major release the plan is to have bugs fixed and not delay them to a minor or this versioning doesn’t make so much sense.
Right now the release cycle is 3 months for a new release, with 4 release every year (few years ago was 2 for year).
This release cycle got a lot of people not happy so much, because this means:
- Wait for a couple of weeks for a minor
- Check various plugins in WP repo supports page if someone reported issues with the latest version (after few years this problem is not so common because there aren’t since Gutenberg a lot of internal changes)
- Tests all the plugins if there are conflicts (and if they got updated)
- Update all the websites.
Think instead when you develop a plugin used by thousands users and you need to test *everything*, and the major is not always enough to be sure that everything will work (that you have to do a lot of minors like WooCommerce).
When you manage a lot of websites, like me as technician, is not very good to have a lot of release very quickly. Of course this cycle was chosen because Gutenberg get an update every month. Also, the GitHub repo that exist since 3 years has 2057 releases of all the various components that are split in various JS packages. So if you are a user that want to be sure that your editor doesn’t break easily you need to install also the Gutenberg plugin or wait for a new WP release.
Stats and complaints from WP.org users/devs
As today the Classic Editor plugin is installed on 5+ millions websites. We don’t know how many websites with WordPress exists around the world, the WordPress Stats page shows just percentage. We can say that in the 42% of WordPress 5.0> (for 4.9< is not required this extension) there are 5+ millions websites that don’t want Gutenberg for various reasons. We need to think also that this metrics includes websites that are just landing pages or with no content updated, so they have gutenberg but not using it.
On 4 May 2020, on WP Tavern the official news channel for WordPress, The Future of WordPress: The Block Editor Is Here to Stay shows some numbers from WordPress.com. Says that on 44.5 million WordPress.com instance there is people using Gutenberg and Gutenstats shows some other numbers.
It is interesting to see that the most used block is the paragraph.
I don’t think that WordPress.com is a good source of metrics because there are blogs unused or dead or big websites under WordPress VIPs that usually are international newspapers with an editorial staff that write a lot of articles every day. So this metrics for me are not trustable because incomplete or from a specific WP target usage.
This source includes numbers also from Jetpack that is a WordPress plugin used also in WP.org but we are not still able to see the number of total websites on WP.org.
This 2 comments in the WP Tavern article shows just how the project management about this feature is lead just for a single user case (WordPress.com), not the real power of WordPress made of a lot of meetups, wordcamp and business that lives around it.
Few days later Where Gutenberg Went Wrong: Theme Developer Edition on 13 may shows how theme developers doesn’t like Gutenberg because the release cycle so fast makes for them impossible to keep updated. The article ends with the fear that as it was for the Customizer support got mandatory this can happen again with Gutenberg.
I agree with some parts of this comment (3, 5, 6), I have something to say about the point 2. In my article of the last year there was some example where tickets, also if was reporting a bug or a feature request, were getting closed because it wasn’t in the roadmap or there wasn’t resources. This is not consistent with the WP trac where there are tickets of 10 years ago still opened.
The community act as toxic (in WordPress or any OSS project) if it is ignored (and is happening since a while), right after when Gutenberg integration was proposed.
The process to close tickets also if the bug exist makes no sense at all, it is like when you do pineapple pizza but no one buy it (In Italy we are racist against this thing) but you are still putting in the menu because you don’t care of the reality of facts.
Well a very concise explanation of the developers feelings and the project management. This way to release is good in a MVP or inside a startup that doesn’t share dev stuff outside so they can do changes without annoy other people and iterate.
Something already said about the content that is saved in the
post_content with all the blocks. I will discuss later in the next section.
In conclusion (as other people say) there are issues on the release cycle, it is not production ready and also pushing the project forward is by a specific company with no interaction from the community. Usually this in OSS happens with a different project name like Enterprise or Pro that doesn’t break the community.
Another point about Gutenberg is the CSS inline, the Gutenberg CSS enqueued also if Classic Editor disable the new one and the all the bloats that produce in the html page.
Right now the block (that include html/json/shortcode/whatever) is saved inside the article but when you change a color or require some css, probably is printing not in the head of the page but inside the body.
Now this is something that for performance (Google Lighthouse report it) very bad and also for further code optimization makes that impossible.
Consider that AMP standard require the CSS in the page head or there will be issues reported in Google Search Console. For this reason the WP implementation parse all the HTML content and move in the head the inline CSS rules.
Pushing only the standards that we like
All the WordPress ecosystem lives on SVN, all the plugin and theme shared the same history (so you cannot delete something as example). At same time finally GitHub was integrated in trac (around a month ago) so is now possible to contribute with pull requests but the documentation wasn’t updated (also for the VVV part), so I did for everyone (not created the pages but updated):
On WCEU 2019 Berlin there was a question during the final keynote about a plan to move away from SVN with no actions. If the WordPress ambicoius is to be more dev friendly is not doing it very good.
WPCS is very good and the work around it is awesome the problem is that is not used in the ecosystem everywhere and Tide is like without any real tool usable after 2 years.
Also the REST api from my previous article showed other problem.
You cannot block the rest api on frontend for public access because Gutenberg will have issues, like block a specific post type exposed to the world. You can use plugins that block for non-logged users but is not a bulletproof solution.
We have to remember that as it is today the REST api is not complete, there are various experimental implementation like for menus and other things check in this GitHub organization. Also the 2FA authentication is not integrated yet or Application Password.
The failure point is that there is an unique API with open to the world without security layer by default and require to install plugins. It is like sell cars without the safety straps but with the hole to add them but with spiders inside it because unused. Probably create different api for admin and non will simplify everything.
Also if a plugin require gutenberg for some libraries or integrations you are forced to use it. This require to a developer to create 2 UI (you don’t want lost 5+ million websites) or find a way to do just one.
Now the editor is asynchronous and can have some benefits but still doesn’t have featurity parity for developers. Right now there isn’t any trigger that let you know when post meta and post content are updates, before there was
save_post but now everyone that implement blocks or Gutenberg implement on its own. The most horrible part is that Gutenberg does a lot of calls for the revision system (it is better to put a low amount of revisions to don’t have a DB full of bloat).
An example I got about it is when you have an integration to ElasticSearch that need to index everything but just on changes for performance and latency. If you don’t know what is happening it is not easy to do it in the specific case.
We are pushing for new languages and standards, while we are still using old tools (with famous issues) because there isn’t any company around WP business pushing this change.
Create a page/post without blocks is better
I saw in my agency and other websites that usually Gutenberg is available but is not used. Basically ACF or CMB2 (we use the second) with specific fields, like title or content in a custom post type. They are used to create custom page builders (with limits) and with 2 major features that save the health of the developers, support guy and so on.
- You don’t have to explain to the users what blocks are required and the order. This can be achieved with Gutenberg templates but is another step to take and to explain.
- The values are stored as postmeta so it is possible to query with WP_Query or use it also outside the page itself. With Gutenberg those data are inside the post_content so you need to read all the posts, parse 1:1 to extract what you need… so not very easy. The other solution is to create a block that save in a post meta and something else inside the post content but not make so much sense (for me).
An example is the Mozilla Community Portal (built with bbpress for Mozilal to create their alternative to Meetups for their needs, I am offering my experience for their internal call as volunteer). They are using ACF to create custom pages for campaigns with a lot of fields. So you can avoid explaining to all the users (from around the world) what are the blocks, order them, the right amount, parameters etc. Fixed fields is the best way to simplify and works majority of times, with the plus of post meta that usually users don’t think of them but improve the quality.
over years WP core dev seems to have subtly separated into tiers:
1. strategic owner interests (a8c wants, a8c gets)
2. business interests (overbuilt features, driven by paid devs)
3. remainder (chaotically handled by volunteers at their expense)
— Andrey Savchenko (@Rarst) October 25, 2019
I have this tweet on my office’s wall. I think that is the best recap I can did about how the project is lead since the Gutenberg arrival.
Thanks to Enea for sharing the WP Tavern links and some rants about gutenberg in this article.
Thanks to Giuseppe for other hints about the topic and techincal details.
PS: Why screenshots of comments? Well in the past I saw comments deleted on WP Tavern…
Thanks for you patience on reading!
- 2020/21/05 – A new plugin by Google to help on performance debugging prints information of the hook that generated some HTML inside HTML comments in the Gutenberg way that include json.