How to Use WordPress Block Patterns: Synced, Unsynced and Overrides

WordPress block patterns are pre-built groups of blocks you can drop into any post, page, or template in a couple of clicks. A hero section, a pricing table, a testimonial row, a call to action: each one arrives fully laid out and styled, and you only change the words and images.

They have been part of WordPress core since version 5.5, so there is nothing to install. What has changed, and changed a lot, is how they behave. WordPress 6.3 split patterns into synced and unsynced. Version 6.6 added pattern overrides. Version 7.0, released in May 2026, changed the default editing mode so that clicking into a pattern no longer exposes its structure, which is why a lot of site owners updated and suddenly felt like their layouts had been locked.

This guide covers all of it: the three pattern types and when to use each, how to actually edit a pattern in WordPress 7.1, the three ways to register a custom block pattern, and how patterns compare to a page builder on speed and portability. If you came here because you cannot edit a pattern after updating, jump straight to the content-only editing section.

What are WordPress Block Patterns?

A WordPress block pattern is a saved arrangement of blocks that you insert as a single unit. Instead of building a three-column pricing section block by block, you pick the pattern and the columns, headings, buttons, and spacing arrive already configured. Underneath, a pattern is nothing exotic. It is ordinary block markup with a registered name, which is why patterns behave like normal blocks once inserted and why they carry no scripts or stylesheets of their own.

So, at the heart of this concept is the idea that plugins and themes have easy access to pre-built blocks and sections. Instead of adding blocks individually to your page, you can access your existing block library with different patterns and layouts for adding to your posts and pages with just a few clicks. This allows you to preset the entire page and theme, making it easy to create complex designs. 

Patterns are built into WordPress core, so there is nothing to install. They are also far simpler to build than a custom block. A block needs registered attributes, an edit component, and a save function, while a pattern is markup plus a short header comment. The trade-off is that a pattern cannot do anything dynamic on its own. When you need logic, you build a block and place it inside a pattern.

Synced, Unsynced, and Override Patterns: The Three Types

Before WordPress 6.3, “patterns” and “reusable blocks” were two separate features with two separate interfaces. They were merged. Reusable blocks became synced patterns, and everything that used to be called a block pattern became an unsynced pattern. If you built a library of reusable blocks before 2023, they are still there, still stored as wp_block posts, and they now appear under Patterns in the inserter. Our WordPress reusable blocks guide covers that older workflow and how it maps to the current one.

Here is how the three types differ in practice:

	Unsynced pattern	Synced pattern	Synced with overrides
Editing an instance	Changes stay local to that post	Changes apply everywhere	Structure global, marked fields local
Where it lives	Theme, plugin, or Pattern Directory	Database (wp_block post type)	Database
Best for	Layouts you customise each time	Footers, disclaimers, CTAs	Author boxes, recipe cards, product callouts
Update behaviour	Editing the source does not touch existing copies	One edit updates every instance	Design updates propagate, content does not
Available since	WordPress 5.5	5.0 as reusable blocks, renamed in 6.3	WordPress 6.6

Overrides are the one most teams miss. Introduced in 6.6 on top of the Block Bindings API, they let you keep a pattern’s structure synced site-wide while marking specific Heading, Paragraph, Image, and Button blocks as editable per instance. You enable it by opening the synced pattern, selecting the block, and choosing Enable Overrides under Advanced in the block inspector.

Two limitations worth knowing before you build around it. Blocks in an override pattern are never optional, so a pattern with three buttons always renders three buttons even if you empty the text on one. And the List block is not supported in a way that lets you vary the number of items. In WordPress 7.0 overrides were extended to custom blocks through the block_bindings_supported_attributes filter, which finally makes them usable for agencies shipping their own block library.

What are the benefits of using the WordPress block pattern?

Patterns solve a narrow problem, and it helps to be specific about which one. Here is what they actually change for the people building and maintaining a site.

You can save a lot of time and frustration

The time saving is real, but it compounds rather than arriving all at once. Building a testimonial section from scratch takes maybe twenty minutes. Building it as a pattern takes twenty-five. The payoff shows up on the fourth use, the tenth, the fortieth, and on the day you need to change one button colour across all of them.

Flexible and customizable

You edit a pattern the same way you edit anything else in the block editor. Click the text and type, click the image and replace it. There is no template file to open and no code to touch. How much of the structure you can rearrange depends on the editing mode, which changed in WordPress 7.0 and is covered in the content-only section below.

Easily combine theme demos

You can easily build websites that look exactly like those awesome theme demos you desperately wanted to replicate. Every WordPress theme developer knows the headache of finding what seemed like the perfect theme, only to look like an absolute disaster after installation. Patterns let you rebuild those demo layouts page by page, inside the block editor, without running a demo importer that overwrites content you already have.

Custom block combinations simplify your life

You no longer need to code anything to have a stunning website with complex components. Instead, plugins and themes can easily offer their block patterns and apply across the entire site.

Layouts survive a theme switch, with one caveat

This one needs a precise answer, because the popular version of it is wrong. Once a pattern is inserted into a post, its markup lives in that post’s content, so the layout survives a theme switch. What may not survive is the pattern itself in the inserter. If it was registered inside the old theme’s patterns folder, it disappears along with the theme. Patterns registered by a plugin, and synced patterns stored in the database, stay available. Styling will shift too, because the new theme supplies different colours, fonts, and spacing. Plan a visual pass after a theme change, not a rebuild.

Create your block patterns

Building your own no longer requires a developer. Since WordPress 6.3 you can create and save a pattern entirely from the Site Editor with no code at all. If you do write code, you get two further options: a file in your theme’s patterns folder, or a plugin registration that survives a theme change. All three are covered further down.

With the benefits clear, here is what is happening underneath.

How WordPress Block Patterns Work

WordPress ships with a set of core patterns and block themes add their own on top. What appears in your inserter comes from four stacked sources: core, your active theme, any plugins that register patterns, and the WordPress Pattern Directory, which is pulled in remotely by default.

Block patterns work by putting together a pre-arranged set of blocks to form a model. So you could say they are templates that you can customize. If you already use blocks, you will find it simple to use patterns. So, the cool part about WordPress block patterns is that while they are templates, they work just like regular blocks when you enter them in your editor. So editing them is simple, and there is no limit to the number of patterns or copies of the same pattern you can place on a page or post.

Once you add a pattern to the editor, WordPress visualizes it as an individual block that you can move and position wherever you want. If you work on design systems, patterns combine well with custom block styles and block variations. The pattern supplies the arrangement, the block style supplies the look, and the variation supplies a preset. Used together, they let you ship a small consistent set of sections instead of an open-ended page builder.

Patterns have effectively replaced the shortcode-and-theme-options approach that layout used to depend on. A section that once needed a shortcode, a settings panel, and a documentation page is now a pattern the editor can preview before you insert it.

WordPress Block Patterns vs Page Builders

If you’re a frequent user of page builders (and many out there), you might wonder how block patterns differ from page builders. Admittedly, page builders also have predefined design templates for website theme-specific apps. However, the WordPress block pattern fixes some significant drawbacks of using the page builder.

WordPress pre-made design: Compatibility

If a page builder is abandoned, the content it produced often degrades into visible shortcodes, because the markup only ever made sense to that plugin. Pattern content does not have that failure mode. It is core block markup, so it keeps rendering whether or not the thing that registered it still exists.

That is a real guarantee, but it is a guarantee about output, not about workflow. WordPress 7.0 changed how patterns are edited, and theme authors did have to retest their libraries. Published pages kept working exactly as before. The editing experience around them changed.

Speed

Patterns win on payload, but the reason is worth stating precisely rather than as a slogan. A page builder ships a runtime: its own CSS framework, jQuery dependencies, icon fonts, and a JavaScript bundle that loads whether or not the page uses those features. A block pattern ships nothing extra. It is core block markup, styled by core block CSS that the page was already loading, so a ten-section pattern and a single paragraph have the same script footprint.

The caveat nobody mentions: this advantage evaporates the moment you install a pattern library plugin that registers its own blocks. At that point you are running a page builder with different branding. If you are evaluating one, the same rules apply that we cover in performance optimization tips for custom WordPress plugins: check whether assets are conditionally enqueued, and test a page that uses none of the plugin’s blocks to see what still loads.

WordPress pre-made Design: Theme updates

Page builder layouts are tied to that builder’s stored settings, so a theme change means exporting, importing, and checking every template. Pattern content is already block markup sitting in the post, so a theme change moves the styling, not the structure. Expect to revisit colours, fonts, and spacing afterwards. Do not expect to rebuild pages.

End-user flexibility

While page builders can provide a beautiful website, it can be difficult for end-users to figure out. In addition, not everyone may find them easy to use, and many would not want to learn or use any kind of code to work with their website. WordPress block patterns eliminate this hassle for end-users with an easy-to-use, clickable interface.

The short version: page builders give you more visual control and more weight. Patterns give you less control and no weight. For a marketing site built out of repeating sections, that trade is usually worth taking. For a one-off landing page with heavy animation, it may not be.

How to use WordPress block patterns

Two things to cover here: getting a pattern into a page, and editing it once it is there. The second part changed in WordPress 7.0, so if your patterns feel locked, read both.

Inserting Block Patterns

Open any post or page, click the plus icon in the top left to open the inserter, then switch to the Patterns tab. What you see there depends on your active theme and plugins, since each can register its own.

Patterns are grouped by category: banners, calls to action, columns, headers, footers, and whatever else is registered. Hover over one to preview it at full width before you commit to it.

Click a pattern to insert it at the cursor position. For the complete library, including anything you have saved yourself, go to Appearance, then Editor, then Patterns.

Once it is in, you can edit the text, swap images, and adjust typography and colour. How much of the structure you can change depends on the editing mode, which is the next section.

Why You Cannot Edit a Pattern in WordPress 7.0 and Later

If you updated to WordPress 7.0 or 7.1 and clicking into a pattern no longer gives you the block controls you expected, nothing is broken. The default editing mode changed.

Patterns and template parts now open in content-only mode. You can edit text and swap images, but structural wrappers like Group, Columns, and Cover are visible and non-selectable, and blocks without content attributes are hidden from List View entirely. The goal was to stop editors from accidentally dismantling a designed layout while changing a headline. The side effect is that developers and theme builders hit a wall on every single pattern.

To get full editing back:

• Unsynced pattern: double-click inside the pattern, or click the Edit pattern button in the toolbar. This engages spotlight mode with full block access.
• Synced pattern or template part: click Edit original. You are taken to an isolated editor, and your changes apply to every instance across the site.
• Permanently, for one instance: detach the pattern from the block toolbar. It becomes ordinary blocks and loses its connection to the source.

If you build patterns all day and the extra click is costing you real time, there is a site-wide opt-out. Add this to a mu-plugin or your theme’s functions file:

add_filter( 'block_editor_settings_all', function( $settings ) {
	$settings['disableContentOnlyForUnsyncedPatterns'] = true;
	return $settings;
} );

This only affects unsynced patterns. Template parts and synced patterns stay in content-only mode regardless, because they are treated as section blocks. The full behaviour, including what block authors need to change in block.json, is documented in the WordPress core dev note on pattern editing in 7.0.

One piece of advice from shipping this on client sites: resist the urge to disable content-only mode globally. It exists because editors break layouts. If a specific pattern genuinely needs open structure, it is usually a sign the pattern is doing too much and should be split into two. That instinct, building guardrails into the tooling rather than relying on people to be careful, is one of the lessons we learned delivering enterprise WordPress projects, and it applies at any size.

Three Ways to Register a Custom Block Pattern

You no longer need to escape HTML through a JSON tool to build a custom block pattern. There are three registration methods, and picking the wrong one is the most common mistake teams make.

Method 1: the /patterns folder (recommended for themes)

Since WordPress 6.0, any PHP file placed in your theme’s /patterns directory with a valid header is registered automatically. No function call, no escaping, no functions.php edit.

<?php
/**
 * Title: Hero With Call To Action
 * Slug: mytheme/hero-cta
 * Categories: featured, banner
 * Description: Full-width cover image with a heading, short paragraph and a button.
 * Keywords: hero, banner, cta
 * Viewport Width: 1400
 */
?>
<!-- wp:cover {"url":"<?php echo esc_url( get_theme_file_uri( 'assets/images/hero.jpg' ) ); ?>"} -->
<!-- your block markup here -->
<!-- /wp:cover -->

Build the layout in the editor first, copy the blocks, and paste the markup straight in. Because the file is PHP, you can call get_theme_file_uri() for images so the pattern does not carry a hardcoded upload URL. The trade-off: these patterns live and die with the active theme.

Method 2: register_block_pattern() (recommended for plugins)

Use this when the pattern must survive a theme switch, which is almost always the right choice for a client’s branded components.

add_action( 'init', 'mytheme_register_patterns' );

function mytheme_register_patterns() {
	register_block_pattern(
		'myplugin/pricing-table',
		array(
			'title'       => __( 'Pricing Table', 'myplugin' ),
			'description' => __( 'Three pricing columns with a highlighted middle tier.', 'myplugin' ),
			'categories'  => array( 'columns' ),
			'keywords'    => array( 'pricing', 'plans' ),
			'content'     => '<!-- wp:columns --> ... <!-- /wp:columns -->',
		)
	);
}

The content value is a single string, which makes it awkward to maintain by hand. A common workaround is keeping the markup in a separate file and pulling it in with file_get_contents().

Method 3: the Site Editor (no code)

Go to Appearance → Editor → Patterns → Add new, build your layout, and save. You choose synced or unsynced at creation. This is the right answer when a marketing team needs to own the component, because they can edit it without a deploy.

Most production sites use all three: theme patterns for brand layouts the dev team ships, plugin patterns for anything theme-agnostic, and Site Editor patterns for whatever the content team maintains.

Where to find patterns you do not want to build: the official WordPress Pattern Directory is loaded remotely into your inserter by default, and block themes can pull specific directory patterns by slug through theme.json.

Adding more block patterns using plugins

Plugins can also add patterns to your inserter, and there is no shortage of them on WordPress.org. Before installing one, understand the trade. Most pattern plugins do not simply register markup, they register their own blocks as well, which means their own stylesheets and scripts. At that point the page speed advantage patterns hold over page builders is gone.

Two checks before you install any of them. First, read the last-updated date and the tested-up-to version on the WordPress.org listing. Several once-popular block libraries have gone quiet, and an abandoned plugin is a security problem, not just a stale one. Second, install it on staging and load a page that uses none of its blocks, then look at what still appears in the network tab. If the assets load anyway, the plugin is not conditionally enqueuing and every page on your site pays for it.

Our own view: build the five or six patterns your site genuinely repeats and skip the library. A pattern is markup and a header comment. The maintenance cost of a plugin is usually higher than the cost of writing them yourself.

More WordPress Block Pattern Resources

Start with the official WordPress Pattern Directory. It is free, it needs no account, and it is already wired into your inserter, so you can browse it without leaving the editor. Everything there is copy-and-paste block markup you can drop straight into a post.

Third-party pattern libraries exist and some are good, but check two things before you rely on one. Whether it requires an account to copy the markup, and whether the licence permits commercial use. Free to browse and free to ship are not the same thing.

One category you can now skip entirely: plugins whose only job is letting you save a pattern from the editor. That was a genuine gap in 2021 and 2022 and several plugins filled it well. Core absorbed the feature in WordPress 6.3. Appearance, then Editor, then Patterns does the same job with nothing installed.

Patterns and Visibility in AI Search

Patterns affect more than page speed. Because a pattern is a fixed arrangement of semantic core blocks, it produces predictable, clean HTML every time it is used. A heading is always an h2, a list is always a ul, a table is always a table. That consistency matters more now that AI answer engines parse pages for extractable structure rather than rendered appearance.

Practical version: build one pattern for your FAQ blocks, one for comparison tables, and one for step-by-step instructions, and every writer on your team produces the same machine-readable structure without thinking about it. Pattern libraries turn content standards into defaults instead of documentation nobody reads. If that side of things is on your roadmap, our WordPress GEO guide for AI search goes deeper on the markup that actually gets cited.

Frequently Asked Questions About WordPress Block Patterns

Start Building Your WordPress Pattern Library

Patterns are the least glamorous part of the block editor and the part with the best return. They cost almost nothing to build, they add no weight to a page, and they turn layout decisions into something a content team can use without breaking anything.

If you are starting from zero, work in this order. Audit the sections your site actually repeats, which is usually fewer than ten. Build those in the Site Editor first, with no code, and live with them for a month. When a pattern proves itself, move it into your theme’s patterns folder or a small plugin so it is version controlled and survives a theme change. Reach for synced patterns only where you genuinely want one edit to update every instance, and for overrides where the structure should be shared but the words should not.

Then test the library against content-only editing before you hand it to anyone else. The fastest way to discover that a pattern is doing too much is to try editing it the way a writer will.