WordPress Developer Blog

Creating Themes from a Pattern-first mindset

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.

Categories: ,

4 responses to “Creating Themes from a Pattern-first mindset”

  1. Val Avatar

    Great start to this new WordPres Blog!

    Although this is a Developer Blog and the intended audience are WordPress Developers, it is a terrific bridge between people like me (who aren’t coding their own plugins for distribution or contributing to WordPress Core), and the Core Developers and Theme Developers/Designers.

    The monumental iteration of WordPress into WordPress Gutenberg has relieved many of a need to know php or a need to find a Theme that does what we want but may not look the way we prefer.

    Since *most* can now get what they want with Block Themes, they can choose a DESIGN they love and easily customize their websites to present information in the way they want. I wondered how that would affect the ecosystem of Theme Developers whose businesses were built around teasing out desired functionality and selling Themes that gave end-users most of what they wanted.

    Having worked with the Site Editor on the redesign of one Site and the build of another Site with two different Themes, I can still see a clear need for Theme Developers and people who implement WordPress for end-users.

    Interestingly, these changes to WordPress have given many end-users greater access to Designers. Or perhaps the sea change in WordPress has offered an opportunity to Designers – and end-users are now benefitting from the work of both Developers and Designers.

    This new Developer Blog brings all three together: Developers, Designers and those of us who manage a few WordPress sites but don’t really fit into the Developer or Designer category. We can more easily keep up with upcoming changes and understand how those changes will affect our Sites.
    Thank you.

  2. Mike McAlister Avatar

    This seems to be the way to go, for now at least. I’m using pattern tags and template part tags to build out layouts and page structures. For theme creators, this really cleans up your theme files and helps you think more modularly about your designs.

    The only hesitation I have is we don’t know what this looks like in practice over time. I guess we’ll have to find out!

  3. Andrei Chira Avatar

    I have to admit I wasn’t sure what to think about Gutenberg when it came out, but now, as I see where WordPress is going with the blocks and patterns, I think it’s amazing. I have made a style variation for the Twenty Twenty Three theme in a couple of hours, and it’s just truly amazing how easy it is to build something cool.

    I’m beginning to understand theme.json, and still learning about patterns. I’m not a developer, and don’t consider myself a theme creator, but I like to play around, and this is the most fun I’ve had playing around with WordPress.

  4. Nazim Ansari Avatar

    Block themes & Gutenberg are really changing the way we do things in WordPress.

    Initially, I was worried about it but after looking at its power and ease of use I can say WordPress is heading towards revolution. I can’t wait to see it’s full potential 🙂

Leave a Reply

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