BlockBased Themes and the Problem with Dynamic Data in HTML Templates

Block-Based Themes and the Problem with Dynamic Data in HTML Templates


The Gutenberg project and its eventual full-site editing feature is coming upon a major issue that will need to be solved. Block-based themes of the future are currently on a path toward a template system that will comprise of plain HTML files. While that will work for the majority of a theme’s output, the trouble is figuring out how the project will handle dynamic values.

Most of the discussion has centered on handling URLs, which are probably the most common use case. Currently, theme templates have all sorts of dynamic content. Much of that will be replaced with blocks as we continue moving toward full-site editing. However, not all dynamic data will have a block equivalent.

A good example is that theme authors cannot currently add the homepage URL to the navigation block. Some experimental block-based themes are using a simple / character, which points to the wrong location on many WordPress installs.

Solving this issue sooner rather than later is important for the progression of theme development in a block world. However, such a solution needs to be carefully crafted so that the theming community is not bogged down by a decade or more with a poor templating implementation.

The Current Proposals

The Gutenberg repository currently has an open ticket for discussion on handling dynamic values in templates. At the moment, there are four proposals on how to address the issue.

On-the-Fly String Replacement

One solution would be to use PHP to parse each HTML file and replace strings representing dynamic data on the fly. This would require parsing all of a theme’s templates on every page load. The downside is that it would slow down the page load. We would need real unit tests to see how much of a spike in loading time this method creates.

Assuming a Mustache-like syntax, templates would have values such as the following image output:

<img src="{{ theme_image_example }}" />

One added benefit of adopting such a solution is that WordPress could automatically escape these dynamic values by default. This would be a boon to theme security, which is one of the biggest issues faced by the theme review team.

One-Time String Replacement

The second solution proposes using the same method but parsing the HTML files once, upon theme activation, and replacing dynamic values with proper values. The largest benefit of this method is that the parsing would not affect front-end loading speed.

This method is problematic because it does not account for changes to templates after the initial parsing. It also does not handle scenarios when a value changes via user input. For example, a user may decide to change the location of their blog posts page. Therefore, parsed URL that becomes static would point to the wrong location.

Templates as JSON

A third solution proposes the idea of turning theme files into JSON. It is far easier



This article was written by Justin Tadlock and originally published on WordPress Tavern.

Disclosure: Some of the links in this post are "affiliate links." This means if you click on the link and purchase the product, We may receive an affiliate commission.

Leave a Comment

Your email address will not be published. Required fields are marked *

Show Your ❤️ Love! Like Us
Scroll to Top