I’ve long been a huge fan of block patterns. So much that I see patterns becoming the primary method most of us lay out pages within the block editor. And with the recent release of Gutenberg, and upcoming release of WordPress 5.9, patterns are getting a lot of attention. There are a number of Pattern API improvements on the way, but one I am most interested in, is the addition of the Pattern block.

In the realm of WordPress editing, a pattern consists of a set of blocks which can be added to a page all at once. The Pattern block, recently merged into the Gutenberg plugin, is a block that renders a pattern — typically used within a template from a block theme. You’re probably thinking this concept of a block to be used within a block template, that renders a pattern, which is really just a group of blocks, is meta — it is. However, there area a couple good reasons behind this.

Translatable block themes

WordPress uses a few PHP translation functions, such as `_( $text, $domain ), for themes to declare translatable strings within its template files. And with the move towards Full Site Editing, and block templates that are entirely HTML based, text strings that were historically internationalized with these PHP functions were no longer being identified as translatable strings.

This means that any WordPress block themes that have text strings within a block template or template part, are not currently internationalized. Patterns on the other hand are translatable, as each is registered via PHP using the register_block_pattern() function, and can be written with the proper internationalization functions in place. So you would first register a pattern — like this:

function richtabor_register_patterns() {
    register_block_pattern(
        'namespace/title',
        array(
            'title'       => __( 'Pattern Title', 'namespace' ),
            'content'     => "",
        )
    ); 
}
add_action( 'init', 'richtabor_register_patterns' );

Then from within a block theme, in a block template file, you’ll add this snippet, with the registered pattern’s slug:

<!-- wp:pattern {"slug":"namespace/title"} /-->

Now any text strings within a block theme’s template files can be fully internationalized. Nice.

Dynamic URLs

Another use case where the new Pattern block shines is for including dynamic URLs within block templates and parts, such as for images and videos. Previously, any block template or template part would need to leverage images from external sources, to have media display within in a template. With the addition of the new Pattern block, those areas of the block theme can instead be created as patterns with dynamic URLs as get_template_directory_uri or get_stylesheet_directory_uri() in use — which would pull directly from the theme. Neat.

A theme of patterns

If you look at the block templates and template parts within the Twenty Twenty-Three theme, you’ll see the Pattern block used to solve for internationalization and dynamic URLs throughout the block theme.

On one hand, this feels like an odd workaround — but on the other, I like the idea of having patterns available within the block editor, that also are used within block templates. And while this does add a layer of complexity and understanding to building block themes, it makes adding patterns to block templates as simple as adding block template parts. I mean, they’re essentially identical:

<!-- wp:template-part {"slug":"header"} /-->
<!-- wp:pattern {"slug":"namespace/header"} /-->

So this brings to question, are block template parts just patterns with extra settings for wrapping the inner blocks with? And what’s the real use-case for identifying block template parts that are essentially patterns (and in some cases are simply rendering the reference pattern 1:1)? I suppose the difference is that a block template part can standardize the parent tag name (i.e. <header> and <footer>), color and spacing settings—which will maintain as the pattern, or blocks, inside it that can be switched out.

And while the group block also has those same controls — so the template part does not have to set those attributes—you probably wouldn’t want to establish the pattern as a <header> element, as the pattern could technically be used anywhere.

It’s a bit of a mind game—and it’s going to take some clear examples to set the standard for using the Pattern block within theme templates. But in all, I’m looking forward to the WordPress 5.9 release, when all this hits the “real world”.