Exploring Enhanced Patterns In WordPress 6.3 — Smashing Magazine

Patterns Get a Unified Workflow

WordPress’ content creation toolkit has been evolving since the introduction of reusable blocks in version 5.0 and block patterns in 5.5. While reusable blocks have always been a straightforward way to create content once and keep it synchronized across the site, block patterns have provided a more modular approach to enforcing consistent design layouts. A key distinction has always separated the two: reusable blocks could be built directly in the Post Editor, whereas block patterns had to be registered or installed before they were available.

WordPress 6.3 effectively retires that distinction. Reusable blocks and block patterns are now combined into a single feature called “Patterns,” accessible directly in the Post Editor. The creation flow works much like the old reusable block process, but with a new crucial twist: you decide at the point of creation whether the pattern’s content should be synced across all instances—behaving like a classic reusable block—or left as a static, unsynced layout component.

The WordPress 6.2 Baseline

To understand what changed, it’s worth taking stock of how the two features worked in WordPress 6.2.

Building Reusable Blocks

Creating a reusable block in 6.2 was a simple task. Select any block, open the additional settings in the Post Editor’s context menu, and click the “Create Reusable block” option. A prompt would then ask for a name. Once saved, the block was accessible from the Block Inserter—in a section labeled only with an icon—or by typing a forward slash (/) followed by the block’s name in the editor.

Making edits wasn’t as direct. To modify a reusable block, you had to click the Post Editor settings while on a page or post and select “Manage Reusable blocks.” This led to a dedicated editing screen where changes could be saved and propagated throughout the site.

Managing Block Patterns

Block patterns were treated like plugins in WordPress 6.2. They were “installed and activated” before being available in the Post Editor. Site creators could consume—but not create—patterns from the admin interface. To contribute patterns, developers needed to either register them in code or package them into a theme.

The register-block-pattern API introduced in WordPress 6.0 allowed theme authors to register custom patterns. The content argument accepted any raw HTML markup, enabling developers to assemble a group of blocks in the Post Editor and paste the resulting HTML into a PHP function. That function could then be hooked into the theme’s initialization process. Patterns could also be removed programmatically with the unregister-block-pattern function using the pattern’s title argument.

WordPress 6.0 also added support for a /patterns directory inside a theme folder. Each pattern in this directory lived in its own PHP file—no function registration required. A pattern file could include a “Block Types” property to make it contextual to a specific block type, such as core/template-parts/footer. This registered the pattern as a transformation of that block type, allowing the pattern to be applied on top of an existing template part without restructuring it.

Templates themselves could reference registered patterns using the wp:pattern context. The Automattic Archeo theme demonstrated this pattern-driven approach, building its full home template from registered patterns and pattern files.

Creating Patterns in WordPress 6.3

WordPress 6.3 merges these two workflows into a single “Patterns” feature. Instead of deciding up-front whether you need a reusable block or a pattern, you now create a Pattern and then decide whether to sync its content. The result is available directly in both the Post Editor and Site Editor.

Creating a synced pattern follows the same familiar path. Select a block or group of blocks, open the context menu, and look for the new option labeled “Create pattern/reusable block.” The subsequent popup still asks for a name, but now includes a toggle to enable synced content support. Once saved, the pattern can be inserted via the Block Inserter or a slash (/) command.

Creating unsynced patterns is where the new workflow departs from the old. Disabling the synced toggle in the creation popup produces a plain, static pattern. No PHP registration or special file directories are required to build these custom patterns on the fly in the Design & UX admin area. They function like design blueprints that can be dropped into any page or post without imposing synchronization constraints.

The practical use case is straightforward. Start with a pattern pulled from the Patterns Directory or assemble any set of blocks manually. Make any desired tweaks—adjusting colors or layout, for example—then select those blocks and create a new unsynced pattern by leaving the synced setting off. These patterns are then available alongside synced options, providing a flexible blend of efficiency and control for content creators.

Patterns Take Center Stage in the Site Editor

Patterns have earned a permanent spot in the Site Editor’s navigation. When you head to Appearance → Site Editor in WordPress 6.3, the redesigned sidebar gives you direct access to edit navigation, styles, pages, templates, and now patterns. This shift means patterns are no longer confined to the Post Editor; they function as modular components that can shape templates right from the Site Editor.

Clicking into the Patterns screen reveals all of your saved patterns, split neatly into synced and unsynced categories. Each pattern opens in its own editing interface where you can tweak and save changes immediately. A notable change in this release is that patterns and template parts now share a single screen. Previously, Template Parts had their own top-level spot in the Site Editor; that entry point has been replaced by “Patterns,” with template parts displayed alongside them.

This merger could blur the line between patterns and template parts. The two features already shared overlapping functionality, much like patterns and reusable blocks did before they were consolidated. It remains to be seen whether template parts will eventually be fully absorbed into the patterns feature, given how much less distinction exists between them now.

Another detail worth noting is that patterns are organized in folders within the Site Editor’s side panel. Folders are generated automatically when a pattern is registered as a contextual block pattern. A lock icon appears next to folders that contain patterns bundled with the active theme, marking them as core to the theme’s design rather than user-generated. These locked patterns are meant to be used as a foundation, the same way you might register a pattern as a contextual block type.

Creating a brand-new pattern (or template part) can now happen directly in the Site Editor—no more hopping over to the Post Editor to set one up and then returning to your template work. This streams a workflow that previously required jumping between two separate UIs.

The screen that used to be labeled “Manage Reusable blocks” in the Post Editor has also been renamed “Patterns,” and it’s now accessible as a direct link from the Site Editor. It lists all custom saved patterns, though it excludes those bundled with the theme. That could change down the line; Gutenberg project architect Matias Ventura has noted in a GitHub discussion that patterns may eventually be served through the Pattern Directory rather than packaged with themes. If that happens, you might see every available pattern, not just your custom ones.

Patterns as Starter Templates

Since the Patterns API landed in WordPress 6.0, a popular approach has been to present a selection of starter content patterns when a user creates a new page template in the Site Editor. The goal is to offer a predefined layout option rather than forcing users to start from a blank canvas, complete with a preview of how the template will look.

The Patterns API expanded in WordPress 6.2 makes this workflow easier by letting you bind custom patterns to specific template types. For instance, you could build a set of patterns aimed at single posts or another set for the 404 template. That capability turns patterns into true starter templates designed for particular contexts.

Let’s walk through the process of registering custom patterns as starter page templates, beginning with the register-block-pattern() function. While registering patterns via the theme’s /patterns folder is an option, it didn’t work in our testing, so we’ll stick with the function for this example.

Registering Custom Patterns with register-block-pattern()

Here’s a function that registers a pattern and associates it with the theme’s 404 page template via the templateTypes argument:

function mytheme_register_block_patterns() {
  register_block_pattern(
    'wp-my-theme/404-template-pattern',
     array(
       'title' => __( '404 Only template pattern', 'wp-my-theme' ),
       'templateTypes' => array( '404' ),
       'content' => '<!-- wp:paragraph { "align":"center","fontSize":"x-large" } --><p class="has-text-align-center has-x-large-font-size">404 pattern</p><!-- /wp:paragraph -->',
    )
  );
}
add_action( 'init', 'mytheme_register_block_patterns' );

The example above, largely drawn from a GitHub Gist, shows how quickly things can get cluttered when you register multiple patterns for one template. Each additional pattern grows the file and makes the template harder to read, preview, and maintain.

Consider the default Twenty Twenty-Two theme: it ships with 66 patterns. To manage that volume, the theme places each pattern in its own PHP file inside an /inc folder, mirroring the common practice of breaking up functions.php into smaller, focused files.

Following that strategy, we can register a few starter patterns of our own. Start by adding an /inc folder at the theme’s top level, then create a /patterns subfolder inside it. Within that folder, add a block-patterns.php file. In that file, adapt the Twenty Twenty-Two theme’s registration function to handle four patterns meant for the 404 template:

• 404-blue.php
• page-not-found.php

Now, focus on the patterns themselves. Open 404-blue.php and add code from this Patterns Directory entry and this one:

<?php
/**
  * Blue pattern
  * source: https://wordpress.org/patterns/pattern/seo-friendly-404-page/
**/
?>

return array(
  'title' => __( '404 Blue', 'mytheme' ),
  'categories' => array( 'post' ),
  'templateTypes' => array( '404' ),
  'inserter' => 'yes',
  'content' => '<!-- wp:columns { "align":"full" } -->
<div class="wp-block-columns alignfull"><!-- wp:column { "width":"100%" } -->
<div class="wp-block-column" style="flex-basis:100%"><!-- wp:columns { "style":{" color":{ "gradient":"linear-gradient(308deg,rgba(6,147,227,1) 0%,rgb(155,81,224) 100% )" },"spacing":{ "padding":{ "right":"20px","bottom":"100px","left":"20px","top":"100px"} } } } -->
<div class="wp-block-columns has-background" style="background:linear-gradient(308deg,rgba(6,147,227,1) 0%,rgb(155,81,224) 100%);padding-top:100px;padding-right:20px;padding-bottom:100px;padding-left:20px"><!-- wp:column { "width":"1920px" } -->
<div class="wp-block-column" style="flex-basis:1920px"><!-- wp:heading { "textAlign":"center","level":1,"style":{ "typography":{ "textTransform":"uppercase","fontSize":"120px" } },"textColor":"white" } -->
<h1 class="has-text-align-center has-white-color has-text-color" style="font-size:120px;text-transform:uppercase"><strong>404</strong></h1>
<!-- /wp:heading -->

<!-- wp:heading { "textAlign":"center","style":{ "typography":{ "textTransform":"uppercase" } },"textColor":"white" } -->
<h2 class="has-text-align-center has-white-color has-text-color" style="text-transform:uppercase">😭 <strong>Page Not Found</strong> 💔</h2>
<!-- /wp:heading -->

<!-- wp:paragraph { "align":"center","textColor":"white" } -->
<p class="has-text-align-center has-white-color has-text-color">The page you are looking for might have been removed had it's name changed or is temporary unavailable. </p>
<!-- /wp:paragraph -->

<!-- wp:search { "label":"","showLabel":false,"placeholder":"Try Searching for something else...","width":100,"widthUnit":"%","buttonText":"Search","buttonPosition":"no-button","align":"center","style":{ "border":{ "radius":"50px","width":"0px","style":"none" } },"backgroundColor":"black","textColor":"white" } /-->

<!-- wp:paragraph { "align":"center","textColor":"white" } -->
<p class="has-text-align-center has-white-color has-text-color">💡 Or you can return to our <a href="#">home page</a> or <a href="#">contact us</a> if you can't find what you are looking for</p>
<!-- /wp:paragraph -->

<!-- wp:buttons { "layout":{"type":"flex","justifyContent":"center" } } -->
<div class="wp-block-buttons"><!-- wp:button { "backgroundColor":"black","textColor":"white","style":{ "border":{ "radius":"50px" },"spacing":{ "padding":{ "top":"15px","right":"30px","bottom":"15px","left":"30px" } } } } -->
<div class="wp-block-button"><a class="wp-block-button__link has-white-color has-black-background-color has-text-color has-background" style="border-radius:50px;padding-top:15px;padding-right:30px;padding-bottom:15px;padding-left:30px">Go to Homepage</a></div>
<!-- /wp:button -->

<!-- wp:button { "backgroundColor":"black","textColor":"white","style":{ "border":{ "radius":"50px" },"spacing": { "padding":{ "top":"15px","bottom":"15px","left":"60px","right":"60px" } } } } -->
<div class="wp-block-button"><a class="wp-block-button__link has-white-color has-black-background-color has-text-color has-background" style="border-radius:50px;padding-top:15px;padding-right:60px;padding-bottom:15px;padding-left:60px">Contact Us</a></div>
<!-- /wp:button --></div>
<!-- /wp:buttons -->

<!-- wp:paragraph { "align":"center","textColor":"white","fontSize":"small" } -->
<p class="has-text-align-center has-white-color has-text-color has-small-font-size">Find the page at our <a href="#sitemap">sitemap</a></p>
<!-- /wp:paragraph --></div>
<!-- /wp:column --></div>
<!-- /wp:columns --></div>
<!-- /wp:column --></div>
<!-- /wp:columns -->'

The templatesTypes argument is essential here. It links the “404 Blue” pattern exclusively to the 404 page template, so the pattern only appears as an option for that specific template.

With the folders, files, and pattern registration in place, you can create the 404 template and put the patterns to work:

1. Navigate in the WordPress admin to the Site Editor (Appearance → Editor).
2. Open the Templates screen via “Templates” in the Site Editor’s side panel.
3. Click “Add New Template”.
4. Select the “Page: 404” option.

Choosing the 404 template triggers a modal that prompts you to pick a pattern for the page, with options filled by the patterns you registered earlier. The theme’s default starter pattern shows up alongside them.

Custom Templates With Starter Patterns

So far, we’ve linked a pattern set to the built-in 404 template. But what about linking patterns to a custom template? When the Site Editor first appeared, it only supported core templates like page, post, and front page. Now you can both choose from more options and create custom ones from scratch.

To see this in action, add two more files to the /inc/patterns folder from the previous example:

• about-me.php
• my-portfolio.php

We won’t detail the full code here since the process is identical to the last example. The key difference is that the templateTypes argument in each file points to the custom templates you plan to build in the Site Editor:

<?php
/**
  * About Me
  * source: https://wordpress.org/patterns/pattern/seo-friendly-404-page/
**/
?>

return array(
  'title' => __( 'About Me', 'mytheme' ),
  'categories' => array( 'post' ),
  'templateTypes' => array( 'portfolio', 'author' ),
  // etc.
);

Back in the Site Editor, open the Templates screen and select “Add new template” as before. This time, instead of a pre-defined template, click “Custom template” at the bottom. You’ll be prompted to name the template; we’ll call ours “My Portfolio”:

Choosing patterns for this custom template currently leads to a blank page at the time of writing. So, skip the pattern selection step, open the template in the editor, and add patterns as you would any block. Click the + button in the top-left corner to open the block inserter, switch to the “Patterns” tab, and select patterns to preview them in the custom template.

You’ll notice patterns are grouped into categories like Featured, Posts, and Text. That organization comes from the categories argument in each pattern file’s return array. If you leave a pattern unassigned, it lands in an “Unclassified” category automatically.

The WordPress Developer Blog offers more examples of building custom starter templates this way.

Using Patterns in the Post Editor

Custom patterns aren’t limited to templates. In the Post Editor, you can insert them into pages and posts just as easily. Any registered pattern that isn’t tied to a specific template appears under the “My patterns” category in the Block Inserter’s “Patterns” tab.

According to this GitHub discussion, dedicated categories for custom patterns are slated for a future release, offering more organizational control down the road.

Installing Community Patterns

Patterns contributed to the WordPress.org Patterns Directory work much like plugins from the Plugins Directory: community members publish open-source patterns that any WordPress site can adopt. The directory filters patterns by community or curated collections, spanning categories from Text to Gallery to Call to Action.

Unlike plugins, however, patterns are not activated from the admin. To use a directory pattern as-is, you register it in a block theme’s theme.json under the patterns object, using the pattern’s slug as the value. Separate multiple slugs with commas:

{
  "version": 2,
  "patterns": [ "short-text", "patterns-slug" ],
  // etc.
}

For instance, the “Slanted Style Call To Action” pattern can be declared in the theme.json of a theme cloned from the default Twenty Twenty-Three theme:

{
  "version": 2,
  "patterns": [ "slanted-pattern", "slanted-style-call-to-action" ]
}

Once registered, the pattern appears in the Post Editor’s Block Inserter under the Patterns tab, and can also be found via search:

If you prefer to skip registration entirely, the GutenbergHub team offers a page builder app that pulls patterns directly from the directory, demonstrated in their introductory video. You can copy the generated code and paste it into a site, enabling low-code construction of complex layouts. In a short video at 1:27, Jamie Marsland shows how the app assembles an entire page from selected directory sections, much like a full page builder.

See the “Utilizing patterns” guide in the WordPress Developer Resources for more on creating starter patterns.

Image Aspect Ratio Controls

WordPress 6.3 introduces aspect-ratio controls for the core/image block, which previously offered no dimension or ratio options for inserted images. Now you can set an aspect ratio that is preserved when swapping in images of different sizes.

This is especially useful for maintaining layout when replacing images inside block patterns, as shown in this short demonstration.

Background and rationale are discussed in GitHub PRs #51078, #51144, and issues #50028, #48079.

Onward to 6.4

The WordPress 6.4 roadmap lists several pattern-related enhancements already in development:

• Pattern categories;
• A consistent inserter experience between synced and unsynced patterns;
• Better compatibility for non-block themes;
• Improvement to the empty category state on the patterns page;
• Fixing a missing alignment attribute for synced patterns in the editor.

This WordPress TV video details the evolution of block patterns, and open issues are being tracked on GitHub.

Since writing, WordPress 6.4 Beta 1 has shipped with support for organizing synced and unsynced patterns into categories during creation. See the release note for current details.

Also see:

• Reusable Blocks (WordPress Documentation)
• Synced Patterns: The Evolution of Reusable Blocks (WordPress News)
• Core Editor Improvement: Advancing the power of Patterns (Make WordPress Core)
• Difference between Reusable Blocks, Block Pattern, Templates, Template Parts (Learn WordPress)
• Builder Basics: Goodbye Reusable Blocks — Hello Synced Patterns (and more) (WordPress TV)
• Roadmap to 6.4 (Make WordPress Core)