Is the Block Editor too progressive for WordPress?
Published: â Leave a comment
The Block Editor is completely new beginning. But does its development fit in the WordPress ecosystem? I ask myself this question over and over again, if I have certain problems, especially if a new version of the Block Editor is released â or even more critical â if they land in WordPress Core.
I already follow its development for certain years now and have been started custom blocks as soon as it becomes part of WordPress Core. This was roundabout three years ago. And in these three years, I noticed certain things that are completely different in the way the Block Editor is developed compared to every other part of WordPress. And I donât necessarily mean technical things, which are only interesting for developers.
Changes to existing pages
Most dramatic for me, and probably most understandable for most people, is the sometimes downright reckless way of pushing changes so progressively that backwards compatibility is partially or completely disregarded. This in turn leads to changes to existing pages without any active action by the administrator or the creators of the pages.
This means: after a major update of WordPress, i.e. changes of the first or second digit of the version number, you can no longer be sure that the site looks exactly the same before as after. This is especially true if you use custom CSS or a theme that differs from the default.
An excerpt of changes that affect the layout
This list definitely isnât complete, but itâs the things I immediately had in mind.
- Classes to align button blocks are gone completely (WordPress 5.9)
- The element
.wp-block-group__inner-container
has been removed from the group block (WordPress 5.8) - The columns block has no more class reflecting the column count via
.has-<count>-columns
(WordPress 5.3)
Many usability changes
Those who witnessed the development of the Gutenberg editor early on will remember the point when it was â finally â possible to nest blocks within each other. And certainly everyone who witnessed that can still remember very well how difficult it was to navigate within the nested blocks. This was not only adjusted once and even today, several years later, it is still difficult and partly too complex, especially for beginners and non-specialists â for whom WordPress still is a very large target group.
But this is just one example of several radical changes to the usability of the Block Editor. At least twice since the release in WordPress 5.0, there have been fundamental changes, often involving relearning the functionality of the editor. Sure, itâs not a problem for power users, but thatâs a vanishingly small target group for WordPress. The fact that it is an extreme annoyance for all those who can not immediately familiarize themselves with changed technical conditions was either ignored beforehand or accepted willingly â it was more important that the version is released (and that was indeed the case in WordPress 5.0).
Considering that the rest of the WordPress backend interface was and is stable for a very long time (whether this is still justified after so many years is up for debate), it shows very well that things are different within the Gutenberg project.
Experimental functions in Core
New features are now often marked as âexperimentalâ and named accordingly within the code. While this is generally a good approach to explicitly state that a feature is experimental, in my opinion it does not make sense for such experimental features to end up in the final version of the core. However, this is exactly what happens often.
The main problem I see here from a developerâs point of view is that although you can use a new feature in the core, it is marked as experimental and thus should not really be used in a production environment. At the same time, I have not only once needed such a function then after all. This means that as soon as this function is no longer experimental, I have to test it again and adjust the implementation if necessary. In my opinion it would be much better not to include experimental functions. And if they are required within the Block Editor, you should make sure that they are no longer experimental before the release. It is not uncommon for these to be functions that, when they are no longer experimental, work differently than they did in their experimental stage.
Too many unprocessed issues
Currently (as of April 25, 2022), there are 887 open issues on GitHub with the âbugâ label, which means they have already been verified as errors. In addition, there is a large number of unknowns among the remaining 4,100 issues. Of my current six open issues, only two are labeled âbugâ, although the others are also clear errors within the Block Editor.
Likewise, an issue that was reported by me has been labeled âIn Progressâ since November 2020. Since then, however, practically nothing has happened. Thatâs frustrating, especially if you rely on the broken functionality. In this specific case, for me, it means that people who donât have sufficient authorization may break HTML code within reusable blocks, provided they edit a page. And it doesnât matter whether the reusable block itself is customized or not.
Other systems are ignored
An interesting short insight into his work with the WP-CLI was given by Alain Schlesser at the 80th Stuttgart WordPress Meetup. Unfortunately, the interesting part about the Gutenberg project arose from a question after the talk, so this is no longer part of the recording. Roughly speaking, however, the big problem for the WP-CLI is that the Block Editor is built in such a way that it can practically only be used reasonably and completely via JavaScript and thus via a browser. This makes it practically impossible for other tools such as the WP-CLI to process blocks effectively, since a lot of information is missing.
Furthermore, certain functions that exist in the core and are observed everywhere there are sometimes completely ignored in the Block Editor. I recently noticed this with the default image size, which is not correctly observed in the media/text block.
However, even functions that the Block Editor itself brings along are now, in my experience, partly no longer included when it comes to making changes that can be influenced by it. As an example, the function to completely disable the frontend CSS of the Block Editor and bring your own styling. That means that you have to adapt all the customizations that are made here as part of a new version. I donât expect changes to be held back because there are sites that bring their own styling. But exactly then I expect to find such adaptations clearly mentioned in the context of a changelog, instead of having to pick them out of the code myself every time. Especially with the amount of blocks this takes more and more time.
Important news are often not announced
With every new major version of the WordPress Core, itâs again a cat-and-mouse game whether you can find all the changes relevant to you. The announcements on make.w.org are useful, but by no means even remotely complete. Also the changelogs are often not helpful without really looking at each entry manually and carefully. With well over 100 changes, this is a mammoth task each time.
For example, WordPress 5.9 not only removed the alignment of the button block, but at the same time implemented a new feature that dynamically generates styling for just that alignment and the like and adds it as insite CSS directly within the respective page. Something like this has to be noticeable in a test environment and if it is not, you might end up with broken buttons on your website.
Conclusion
Yes, this post is very negative. Completely deliberately. But I donât mean to say that the Block Editor or the Gutenberg project as such is bad. On the contrary, I love the Block Editor and enjoy writing with it. The worse I find it that it is developed in a completely different way than the WordPress Core. Because just the backwards compatibility, the constant functionality of an existing function and the rather conservative way of releasing innovations are in my opinion huge reasons why the WordPress project became and is so successful.
And this is where you run the risk of changing so much that the entire project is affected. Because that this progressive development of the Block Editor keeps all developers on their toes is one thing. But the fact that even those who only use WordPress to maintain content are constantly exposed to sometimes dramatic changes is a completely different and much more serious problem. Because those who only do it from time to time will hardly be able to learn the new features in a meaningful way. Especially if a part of the user interface changes again every few months.
For worse, if then also content in the frontend is (visually) changed, which has not been notices during tests, this is bad.
A part of the things I noticed here I already gave as feedback. I really hope that at least some of the things mentioned here will be changed in a meaningful way. But only future will show âŠ