As I was perusing the latest block themes on WordPress.org, I came across a new favorite: Bai. The typography was on point for those who tend to write long-form content. Plus, it has a built-in dark mode design that did not make me want to rip my eyes from their sockets. I had planned to review it, but I did not have much to say. It is simply a solid design without much in the way of extras.
However, in the particular test environment I had set up, one piece of it was broken. I ran into a longstanding issue with the block system.
The default “intro” image used on the homepage will return a 404 if WordPress is not installed in the root directory or if the /wp-content folder has been moved. I switched it to another test site using the default configuration to make it appear.Bai theme homepage.
This is not the fault of the developer. Block themes currently have no way to add dynamic values in their templates. Therefore, the only solution is to hotlink an image from a third-party site or add a static URL.
This is a not-so-trivial issue that has, at least in part, hampered the momentum of block theme development.
Ever since themes have been around, they have output data via PHP functions. When using block templates, everything is HTML and bits of JSON data. The dynamic parts are the blocks themselves. This works well enough for at least 90% (probably more) of scenarios.
Where theme authors run into trouble are the cases where there is no existing block or way of adding dynamic data inline. Some use cases include:
- Printing internationalized text strings.
- Outputting the current year in the footer copyright section.
- Adding image URLs.
It is not so much that these things absolutely must be dynamic. Users are expected to edit the content via the site editor. However, the experience is not ideal if an image returns a 404 status when users have a different directory structure. Or when their theme has bits and pieces of English scattered throughout when using the Spanish translation. Before block themes officially land in WordPress, this must be fixed.
There is an open ticket slated for Gutenberg 11.8 that addresses this issue through a new Pattern block. Essentially, it would allow themes to output a pattern within templates.
The reason this works is that patterns are defined via PHP. Theme authors can use internationalization functions like __(), print out the date with date_i18n(), or output an image URL with get_theme_file_uri().
This upcoming feature closed an earlier proposal for a standalone i18n block. It should also tackle the multiple ideas on an earlier issue for dynamic data in static HTML files. Another one for including images in block templates. A proposal from 2020 for using patterns in templates. And, I am sure a host of other tickets.
The push will likely happen because the upcoming default theme, Twenty Twenty-Two, needs it. Developers currently need to figure out how to show the default flying bird image on the homepage and add internationalized footer credit text.Twenty Twenty-Two homepage design.
I like the concept here. Developers add the Pattern block within their templates. In the site editor, the pattern is shown and persists until a user makes a direct edit. Then, it behaves like any other set of blocks, and the content is no longer dynamic.
A side benefit of this feature is that it could also solve a duplicate code issue and allows theme authors to follow the DRY principle.
When creating templates or template parts, some theme authors duplicate the same content as user-selectable block patterns. Instead of having the code in two places, they can register it once as a pattern and call it within the template.
While the Pattern block is not officially merged yet, it looks to be the best solution to the dynamic content issue with block themes.