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.
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.
<!-- wp:pattern {"slug":"namespace/pattern-name"} /-->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. And, I am sure a host of other tickets.
The
[…]
This article was written by Justin Tadlock and originally published on WP Tavern.