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. 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.
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.
This issue came up with my Pria theme. I wanted a page template with the page title within a cover block, but with no way to include a cover image due to the dynamic nature of the root directory, had to make do with just giving the cover block a background color.
Also for the base theme of my WP Block Patterns site, I wanted the current number of preview themes do be displayed dynamically. Basically to avoid manually editing this every time in the page content.
As I have yet to learn how to develop blocks, my solution was using the Shortcode block on the page, with a call to a custom PHP shortcode that would return this number dynamically.
Themes adding their own shortcodes or creating their own blocks would obviously not be allowed in the org directory, so this new Pattern block would be the ideal solution.
Additionally the placeholder content can be changed by the user and would not be lost when switching themes.