Throughout most of WordPress’ history, classic theme development was a template-first affair. Templates housed the structure of the eventual document that would appear on any given front-end page. However, the block paradigm allows for a rethinking of how developers approach theme creation.
More and more, it is easy to see how patterns could almost entirely take over the role that templates played in the past. When you get right down to it, front-end code is often a bunch of repeated groups (i.e., patterns) of the same or similar code. Throughout much of the web and WordPress’ history, half the battle of tackling the front-end has been around finding new and unique ways of reducing repeated code. This is known as the DRY (Don’t Repeat Yourself) principle.
Patterns very much fit into this same mold, but most WordPress block themes have underutilized patterns. This is understandable. It is still early in the block themes era, and creators have not yet fine-tuned how they build with the available tools.
Most usage around patterns has centered on their registration so that users can build custom pages via a simple point-and-click inserter. However, there needs to be further discussion on how theme authors themselves can and should be building their themes atop this same foundation.
Think of it as a pattern-first mindset in the theme creation process.
There is some inkling of this approach in the Twenty Twenty-Two theme’s header and footer template parts:
However, it did not go far enough in showing off the potential for patterns. It was the first official default block theme to launch for WordPress, and we now have that magical ability of hindsight.
When I was first perusing the underlying template code from Twenty Twenty-Two several months ago, I noticed a lot of repeated code within the /templates
folder. Staring at the index.html
, home.html
, and search.html
templates, I could not find a single difference between the queried posts output. So, I ran them through a code-diff checker. As suspected, each instance matched. The flagship theme for WordPress was breaking the DRY principle. It had 33 lines of code in each file that could have been reduced to a one-line call for a block pattern.
That’s 33 lines of code that could instead look like this (assuming a registered pattern of twentytwentytwo/query-example
):
<!-- wp:pattern {"slug":"twentytwentytwo/query-example"} /-->
The entire /templates/index.html
file could be as simple as:
<!-- wp:template-part {"slug":"header","tagName":"header"} /-->
<!-- wp:pattern {"slug":"twentytwentytwo/query-example"} /-->
<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->
That is, quite literally, three lines of code.
The keen-eyed among you may have noticed I did not mention archive.html
. Its queried posts output appears the same as the other three templates on the surface. Technically, it has a few code differences, but I do not know why. Perhaps it was a mistake, a remnant from an earlier version. Maybe it was an oversight, a bit of block code that was never checked to see if it matched the other templates. My guess is that it if these templates were approached from a pattern-first mindset that archive.html
would not have had any differences.
Since WordPress 3.0, theme authors have used template parts to cut back on repeated code. That is still a valid approach using block-based template parts. However, patterns provide more flexibility and can even be combined with them.
Where patterns shine is that they put more power into the hands of end-users while not taking anything away from theme authors. Users can take any pattern made available through their theme and use it in their own templates or even plop them directly into the middle of a custom page.
Is it possible to reduce more template code in Twenty Twenty-Two, replacing it with patterns? Possibly, but this is the biggest win and incredibly low-hanging fruit. Besides, it is merely an example. I selected it because it was a core WordPress theme, but I have seen similar areas with other themes in the directory.
There is rarely much difference in most template output. Most themes could be broken down to a few primary areas:
- Header
- Content – archive views
- Content – single views
- Sidebar
- Footer
There are variations among that formula, but nearly everything within a theme’s templates is repeated at least once. With the block patterns system in place, some themes may never need anything other than <!-- wp:pattern --/>
calls.
This is not any sort of set-in-stone rule. Instead, it is a look outside the box. Or, at least a look at how extenders can rethink some old problems in the context of the block system.
Leave a Reply