WordPress Theme Composition and Interoperability

I’ve shared quite a bit about the composition of WordPress themes and how they’ve evolved over the years. But one notion that has captured my attention lately is just how composable themes have become lately.  

WordPress themes used to be so static; stuck in the time when it was first launched. Sure, you’ll get a few maintenance updates, but that’s really it. 

Today’s themes—or rather, today’s block themes—inherit the newest additions to WordPress out-of-the-box, as blocks carry much of the “weight” themes were once required to do. And historically, many theme designers—including myself—relied on a framework that covered the basics of their theming approach; but now, WordPress is that framework.

Consequently, you can mix and match blocks from any page or template, and between any theme. It’s pretty cool, but there’s so much more to this.

Color and typesets

At its simplest form, a block theme is a data object, represented by a configuration of settings, presets, and styles within a single theme.json file. 

If we abstract a theme’s color set (all color, duotone, and gradient presets—and the application of those values), and typeset (all typographic settings—and the application of those values), we end up with theme-agnostic values for both, that can be applied independently of each other. 

Never before have you been able to apply the typographic choices of one theme, with the color definitions of another, along with any content (i.e. blocks) you’d like. And perhaps there’s a path here towards sharing colors and typesets, the way you share patterns on the Pattern Directory—adding that much more creative expression to WordPress. 

This abstraction of style is one the driving forces behind the recent effort to expose a theme variation’s color set and typeset as options within a site’s global styles.

The best part of this effort is that all existing block themes will inherit this capability, without having to do a thing. Anyone running a block theme can use any combination of colors or typesets from any of their theme variations.

It’s a step forwards for themes becoming a true composition of parts; that is colors, typesets, patterns, and templates.

But there are caveats.

Themes, and patterns for that matter, need to be crafted in a way that properly leverages global styles. When designing a theme, you should almost never apply a style directly to a block or template. Instead, lean on the theme’s global styles, which are able to properly style any block presented on the site as intended, regardless of its origin.

Patterns and templates

Patterns can already be served from the Pattern Directory using theme.json; we need more theme designers experimenting with this approach. Twenty Twenty-Four pulls a couple patterns, but I’m thinking the next default theme should use this method almost exclusively perhaps.

Aside from theme interoperability and a lower maintenance burden, the big advantage here is that pattern authors can improve them over time, and anyone running the associated theme(s) can receive those updates without any action.

I also think it’d be interesting if patterns in the Patterns Directory could declare a theme, or set of themes, that they should be available in. This way, theme designers wouldn’t need to update a theme’s theme.json file to add more default patterns to a theme.

So what do you think?

I’m confident that continuing to evolve towards this parametric-driven design system for WordPress themes will only improve the interoperability of content and design, allowing for more creativity without the typical constraints of WordPress. 

So what do you think? Do you see a near future where themes are a sum of parts; a composition of taste, derived from color, typography, and content?

Responses

  1. Carolina Avatar
    Carolina

    If all patterns in a theme are loaded from the remote pattern directory, the theme will not work well on closed secure networks such as intranets. Or am I missing something? I think only non-vital patterns could be fetched from the pattern directory.

    1. richptabor Avatar

      I think it’s acceptable to have templates with content/local patterns (where necessary), but generally all others could be from the directory. It’s too beneficial to omit from everyone because of an edge case.

      1. Carolina Avatar
        Carolina

        Yeah. +1

        And as soon as we have translations working, that specific type of content pattern will not be needed.

  2. Derek Avatar

    It’s an interesting concept, but one thing difficult about the pattern directory right now is there is no design cohesion. A site should have consistency throughout, so I almost advocate for fewer patterns available that are carefully curated for a particular site experience.

    However, I could see this as a step towards a cloud connected library for theme designers. Some themes do this now (Kadence and Spectra i.e.) where you get one theme but have access to a cloud library of site templates and patterns. This new approach you would lower the barrier of entry for theme designers to be able to create one theme—or design for one or two themes—and create collections of patterns based on genres of content.

    If patterns can be easier to search based on style, content type, aesthetic, and a number of other taxonomies that are more descriptive of the type of site someone owns or is building will make the pattern experience better.

    1. Rich Tabor Avatar

      Yes, I’m thinking about how design could be more cohesive across patterns. It’s a tough ask, but not out of reach.

Leave a Reply

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