Major flaws in block theme creation

During the last few months, I worked quite a few times with block themes for WordPress. And while I get used to it, I also experienced some flaws I want to talk about. I want to clarify that not everything is bad with block themes, but it gives you an idea of some fundamental problems with them and a potential reason why they are adapted so slowly by theme creators.

Template parts

When it comes to template parts, there are some problems I have with it. Since they can be fully edited within the site editor, they’re basically just text. So they’re just static. You cannot add logic to them in any way, which is dynamic in any way.

Non-translatable

That means, template parts are practically not translatable. If you’re running a multilingual website with Polylang or WPML for instance, you would need to have each template part in every language with static text to work properly with it for every language.

Predefined images

The same problem applies to images you predefine in template parts. You simply cannot use any dynamic content (which would be required here to determine the correct URL to an image) and thus cannot use predefined images at all in template parts.

References

Which brings us to the whole part of references. For example, the navigation block uses references to a navigation object to make a navigation reusable in different places. However, you cannot add such a navigation object reference in your template part (and also not to any other dynamic content). That means, you can only create a new navigation every time you insert a template part with a navigation. And that’s the same case for all blocks requiring some sort of reference.

Fix it with block patterns?

One would say that all the issues above can be solved by using block patterns. Which is true when it comes to have it sort of dynamically. You can add PHP code in block patterns, but as soon as they’re inserted into the editor, they’re static again. And not only this, they have no reference to their pattern code whatsoever. Which means, if you edit the block pattern any time, you would need to edit all areas where you’ve used this block pattern – manually.

Template creation outside of the editor

Since templates are now blocks, the template creation outside of the editor has to be block markup, too. While it’s relatively trivial to have a template for a paragraph, the more settings a block has, the more difficult is it to create a template outside of the editor. Also editing it requires much experience in using blocks since you need to make sure to edit all necessary parts of the markup correctly.

And if you don’t, you have to pray for an error message that’s actually usable to find the error in the template (which applies to all error messages of the block editor).

Very often, and especially if you don’t know the block from memory, you have no other choice to create the template or the part of the template you want to add/edit, inside the editor and copy it from there. Then, you still have to make sure to remove all references in the blocks to this particular WordPress instances if you want to share it afterwards. That makes the whole workflow a big pain, especially after you publish your theme and need to make sure that always have the latest version of the templates shipped within your theme (and preferably also that existing outdated templates and template parts do not completely destroy the look).

theme.json documentation (sort of)

While first creating this post in late 2023, I could find many different documents about the theme.json. However, none of them was near complete and always more of an example on how to use it. Luckily, that changed and we have a proper documentation here:
https://developer.wordpress.org/themes/global-settings-and-styles/

However, it’s still a very steep learning curve and not always self-explaining to use. Also, especially when it comes to particular styles for particular blocks, you are practically forced to test which ones work and which don’t. Or you have to look into the source code of the particular block to check which styles a block supports and which it doesn’t.

Limited query block

For the query block, that is used to automatically output posts of a certain post type, there are just not enough options. You can define the post type, the order, whether to include sticky posts and can define the items per page, the offset and a maximum post count to show. And that’s it. If you want more, you need to add it manually, which can become kind of tricky. So you’re basically stuck with a very limited query block, especially if you compare it with classic themes, where you can use just a small bit of PHP to make use of the full potential of a WP_Query object, which is very powerful.

Having just a fraction of it in the UI makes the UI lightweight, but also robs the creator of many possibilities.

Where to change what

By using a block theme you always have to possibility to edit the page or the website you’re working on. Even for me as a developer it’s not always clear where I can edit what. And I’ve seen now multiple other people struggling with it. While it can be quite nice for people to edit templates and template parts on their own, to do so they first have to understand the concept of templates. And many people just want to edit the page they see, without having to know how it works in the background, which is totally understandable for me.

I think a better approach would be to be able to edit the page as a whole, while having popups for every area that is part of a template, to notify the user that if this part is edited, it also changes this part on other pages. That would be very similar to editing synched blocks.

Additionally, while editing a template part, you’re in a completely different context, since you cannot see the whole page anymore but just this one template part.

Conclusion

While there are definitely some benefits in using block themes, which I kind of like, I also hate some things as stated above. Unfortunately, I don’t think for most of them that they will change any time soon, if at all. It would require some fundamental change and it would be very complex, especially while maintaining backwards compatibility (not if the whole project is that much interested in backwards compatibility at all, but that’s another story).

Currently, for the most users I cannot recommend creating block themes whatsoever. They not only left the creator with some major flaws, but also a bad user experience while managing the theme afterwards.

What’s your opinion on this and on block themes as a whole?