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, a 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 to parse and extract data from a JSON file than and HTML file. However, theme designers do not write JSON to build template output. HTML exists for a reason.
This solution would raise the barrier so high for new theme authors that it would be rare for those who just learned basic CSS and HTML to get into WordPress theme development. This idea is so foreign to the idea of template design, that it should not be a serious consideration.
Templates That Return Blocks via PHP
The fourth and final proposal is to use PHP files with a function that returns a block template. This method would be straightforward and could be picked up easily for existing theme authors who have a familiarity with PHP.
A template would look something like the following:
function my_theme_front_page() {
return '<!-- wp:cover {"url":"' . get_template_directory_uri() .'/block-background-image.png","id":273,"dimRatio":0,"minHeight":647,"align":"wide"} -->';
}This idea puts more focus on PHP than HTML. It would be the easiest-to-implement solution for the Gutenberg development team. However, like the JSON method, it would raise the barrier to entry for first-time theme authors. It will mean making sure quote and double-quote characters do not get mixed up. The method would be prone to bugs and looks alien to modern-day templating.
Templating Should Focus on HTML
Templating should always be HTML-first. Even in our current theme system, theme authors can build beautiful, safe, and functional themes by simply knowing HTML and CSS. PHP is secondary, especially when it comes to the templating aspect. Our templating system relies on knowing HTML and plugging in a few template tags, which are PHP functions that WordPress provides for dropping in between HTML tags. This simplicity is, in part, what made WordPress theme development so easy to learn for anyone willing to put in a little time.
Block-based themes have the potential to drop the barrier even lower than our current templating system. However, templates as JSON or PHP functions runs counter to that. Any solution that pushes us farther away from the basic building blocks of the web, HTML, should not be on the table for discussion.
It may be time to adopt a proper PHP templating engine. There are plenty of examples out there. Twig, Blade, Smarty, and others have existed for years. Those also have some barrier to entry in the form of new syntax, but this should be no tougher than learning to plug template tags into the current system.
At the very least, we will need to figure out a solution for handling dynamic data in what is essentially static HTML files.
Interesting post Justin.
It doesn’t seem too far-fetched to me that that at some point theme author’s are going to have to start dipping their toes, feet, legs deeper and deeper into learning how to build blocks for the new editor. Which means learning a lot of javascript and subsequently JSON. Being primarily a frontend WordPress dev specializing in javascript and react, I am very biased, but I have to believe if we’re moving toward block-based themes, why wouldn’t we go all in by using templates as JSON?