The ‘Pattern’ block and how it solves a long-standing problem with dynamic data in HTML templates – WP Tavern
While browsing through the latest block themes on WordPress.org, I came across a new favorite: Bai. The typography was relevant to those who tend to write long content. Plus, it has a built-in dark mode design that didn’t make me want to tear my eyes out of their sockets. I had planned to see him again, but I didn’t have much to say. It’s just a solid design without a lot of extras.
However, in the particular test environment I had set up, part of it was broken. I have encountered a long-standing problem with the blocking system.
The default “intro” image used on the home page will return a 404 if WordPress is not installed in the root directory or if the
/wp-content the file has been moved. I switched it to another test site using the default configuration to make it appear.
It is not the developer’s fault. Block themes currently have no way to add dynamic values ââin their templates. Therefore, the only solution is to link to 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.
Since themes have been around, they generate data through PHP functions. When using block models, everything is HTML and bits of JSON data. The dynamic parts are the blocks themselves. It works well enough for at least 90% (probably more) of the scenarios.
Where theme authors run into problems is when there is no existing block or way to add dynamic data inline. Some use cases include:
- Printing internationalized text strings.
- Display of the current year in the copyright section of the footer.
- Adding image URLs.
It’s not that these things absolutely have to be dynamic. Users are expected to edit content through 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 of English scattered around when using the Spanish translation. Before block themes officially arrive in WordPress, this needs to be fixed.
An open ticket is planned for Gutenberg 11.8 which fixes this problem via a new Pattern block. Essentially, this would allow the themes to generate a pattern within the templates.
The reason this works is that the templates are defined through PHP. Theme authors can use internationalization functions like
__(), print the date with
date_i18n(), or generate an image url with
This upcoming feature closed an earlier proposal for a standalone i18n block. It should also address the multiple ideas on an earlier problem for dynamic data in static HTML files. Another to include images in block models. And, I’m sure a host of other tickets.
The push will likely happen because the next default theme, Twenty Twenty-Two, needs it. Developers currently need to figure out how to display the default flying bird image on the homepage and add internationalized footer credit text.
I like the concept here. Developers add the Pattern block in their models. In the site editor, the template is displayed 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 secondary benefit of this feature is that it could also fix a duplicate code issue and allow theme authors to follow the DRY principle.
When creating templates or template parts, some theme authors duplicate the same content as user-selectable block templates. Instead of having the code in two places, they can save it once as a template and call it in the template.
Although the Pattern block is not officially merged yet, it seems to be the best solution to the dynamic content problem with block themes.