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, 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.

Bai theme home page.

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 get_theme_file_uri().

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.

Home page design for the Twenty Twenty-Two WordPress theme which features a black background with a large slogan and a flying bird image at the bottom.
Design of the Twenty Twenty-Two homepage.

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.

Comments are closed.