WordPress Block Patterns: Synced Patterns, Overrides and Locking

by Francis Rozange | Oct 2, 2026 | Gutenberg

Identical glass tiles in repeating patterns, linked by light threads to a master tile

A writer changes a phone number in the footer of one page, and the number changes across the whole site. Another writer wants to fix a heading in a homepage section, slips by a millimeter, and moves an entire column. Both situations have the same origin: WordPress block patterns, and the way they are synced or locked.

Patterns have become the central layout tool in WordPress. They serve as section templates, reusable blocks and page layouts. Since WordPress 7.0, released in May 2026, they are inserted in content-only mode by default, a change that divided the project’s own contributors.

This guide covers the topic in WordPress 7.1: synced and unsynced patterns, content overrides, locking, registering patterns in a theme, categories, the official directory, then a working method for an editorial team.

What a pattern is, and what it is not

Three reusable units

The theme developer documentation defines it simply: a pattern is nothing more than one or more blocks, preconfigured and offered to the user. It is not a custom block with its own code, but an arrangement of existing blocks, headings, images, buttons, columns.

WordPress offers three reusable units that people often confuse. An unsynced pattern is a starting point: you insert it, then each copy lives its own life. A synced pattern stays linked to its original: editing it changes it everywhere. A template part, such as the header or footer, belongs to the Site Editor and structures the theme’s templates.

Where patterns come from

Patterns have five possible origins: WordPress core, the active theme, plugins, the official WordPress.org directory and your own team, which can create them in the editor. Patterns arrived in core with WordPress 5.5, in August 2020, and the official directory has been built into the editor since WordPress 5.8, in July 2021.

Starter patterns

A special kind of pattern appears when you create a page: starter patterns. A theme declares them by tying them to the post content block and to the target content type. Introduced for pages in WordPress 6.0, they cover all content types since 6.1. The selection window only appears if the theme offers at least two.

For a team, the difficulty often comes from abundance: an inserter filled with dozens of patterns that nobody can trace. We will see further down how to clean it up.

Synced and unsynced patterns

Unsynced: a starting point you copy

An unsynced pattern is inserted as a copy. Once in the page, its blocks keep no link with the original, and editing the original pattern does not change the pages already using it. It is the right choice for post layouts, homepage sections or starter layouts.

Every pattern registered by a theme is of this type in WordPress core. A request open since February 2024 asks for synced theme patterns, with no result as of October 2026.

Synced: one source, every instance up to date

A synced pattern is saved once, in the database, and every page that uses it displays that same source. Editing the pattern updates all its instances. It is the ideal tool for a contact block, a legal notice or a standard call to action.

Long-time users know it under another name: until WordPress 6.3, in August 2023, these were called reusable blocks. WordPress 6.3 renamed them synced patterns, without changing how they work, and also let users create unsynced patterns.

Detaching, deleting, rolling back

An instance can be detached from its synced pattern: it becomes an independent copy that will no longer follow changes to the source. Deleting a synced pattern, on the other hand, leaves a message on every page that used it, saying the block has been deleted or is unavailable.

Before deleting or deeply editing a synced pattern, find out where it is used. Patterns keep revisions, and WordPress 6.4 lets you export and import them as JSON, which provides a simple backup.

Content overrides in synced patterns

A shared design, content specific to each instance

WordPress 6.6, in July 2024, added overrides: a synced pattern can now leave some content editable in each instance while keeping a shared layout. A testimonial card, for example, keeps the same design everywhere, but each page shows its own text and photo.

To turn it on, you open the synced pattern, select a compatible block, then click Enable overrides in its Advanced panel, giving it a unique name. In the markup, this becomes a binding to core/pattern-overrides, like this.

<!-- wp:paragraph {"metadata":{"name":"Testimonial","bindings":{"__default":{"source":"core/pattern-overrides"}}}} -->

Turning them on and off, and the theme limitation

Overrides are turned off in the same place, with the Disable overrides button in the block’s Advanced panel. They only work in synced patterns created in the editor and saved in the database, not in a theme’s files, since core offers no synced theme patterns. A small third-party plugin, Synced Patterns for Themes, fills that gap for themes that need it, with a still very small user base.

Which blocks, which attributes

At launch, four blocks were covered: Heading, Paragraph, Button and Image. In WordPress 7.1, core’s list also covers the list item, the post date and navigation links, plus more image attributes, such as the caption. Overrides change content, never layout or styles.

Custom blocks since WordPress 7.0

Since WordPress 7.0, any block attribute that supports the Block Bindings API also supports overrides, including in custom blocks. A developer declares the relevant attributes with the block_bindings_supported_attributes filter. Our selection of Gutenberg block plugins helps you spot the libraries keeping up with these changes.

Content-only mode and locking

What WordPress 7.0 changed

Since WordPress 7.0, an unsynced pattern inserted in the editor opens in content-only mode. The writer edits text, images, their alt text, links and button labels, but cannot move, delete or add the section’s structural blocks, such as groups or columns. They can, however, insert new paragraphs, list items or buttons into the designated content areas. A dedicated button, Edit pattern, opens the pattern for full editing, and the documentation presents this mode as protection against accidental layout changes.

For block authors, this brings a constraint: only attributes marked with the content role remain editable. A block that does not declare it becomes hidden from List View and cannot be selected inside a content-only section.

Locking a block or a container

Locking has existed since WordPress 5.9. At the block level, the lock attribute prevents moving or removing it. At the container level, such as a group or columns, templateLock accepts three values: all locks everything, insert prevents adding or removing blocks, and contentOnly, since 6.1, only allows content edits.

By default, anyone who can edit a page can also lock and unlock its blocks. To reserve that power for those who manage the design, the documentation offers this filter.

add_filter( 'block_editor_settings_all', function ( $settings ) {
	$settings['canLockBlocks'] = current_user_can( 'edit_theme_options' );
	return $settings;
} );

Locking protects against slips, but it does not stop a determined user: they can still open the pattern for full editing or detach it. The one documented exception is a locked synced pattern, which no longer offers the detach option.

The exits

For teams that prefer the old behavior, WordPress 7.0 added a setting that turns off content-only mode for unsynced patterns.

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

WordPress 7.1 added an equivalent setting for template parts, and a command in the command palette that turns the mode on or off for the current session. Synced patterns, however, are always treated as sections.

The real case: how WordPress 7.0 locked patterns

Making content-only mode the default is an editor change whose every step can be followed in public sources. The debate took place in public, on GitHub and on the project’s official blogs, between September 2025 and September 2026. It shows how WordPress weighs writers against site builders.

An idea of separation

On September 5, 2025, Matías Ventura, lead architect of Gutenberg at Automattic, opened an issue titled “Pattern Editing and contentOnly interactivity”. His argument: patterns are not custom blocks, and the editor’s nested architecture makes simple edits complex for ordinary users. He proposed limiting everyday editing to content attributes, to separate content from design.

Five days later, Ramon Dodd opened an issue to provide a way to turn this mode off, “if required”, with agencies in mind that build themes for content-editing purposes only and need everything unlocked while they develop them.

Objections from editorial teams

On January 24, 2026, Fabian Kägy, a WordPress core committer and principal engineer on the Editorial Engineering team at Fueled, the agency formerly known as 10up, tested the feature on Twenty Twenty-Five. His verdict: in its current form, it should not ship. He described feeling stuck, unable to add a list item or a button to a section, a full-editing button that was too hidden, and repeated clicks to change several sections.

Joen Asmussen, a designer at Automattic, replied two days later that the feature should ship, and that detaching a pattern should be treated as a normal step. On February 12, Kägy proposed an opt-out, explaining that the mode adds a lot of friction for teams that constantly jump from section to section. Aki Hamano, another core contributor, argued the choice should depend on the pattern’s content, not on user preference, and even raised postponing to version 7.1.

The compromise was merged on February 18, 2026: a setting turns off content-only mode for unsynced patterns only. On February 27, Ramon Dodd published a call for testing on the Test team’s blog, restating the reason for the change: small misclicks can restructure a layout or remove an entire block.

The release, then adjustments

WordPress 7.0 shipped on May 20, 2026 with the new default behavior. Feedback from the call for testing had flagged friction for people who edit many patterns, since each one needs an extra click: in June, Ramon Dodd added a command to toggle the mode on the fly, shipped with WordPress 7.1.

On July 1, 2026, Steve Ryan, a developer at Arizona State University, reported a confusing behavior. His team gives faculty and staff page patterns to trim, where you delete whatever does not fit, and he later explained that for those patterns, content-only mode would only get in the way.

After the update, the same pattern behaved differently depending on whether it was wrapped in a single Group block: without a single wrapper, content-only mode did not apply. Core’s code only ties a pattern back to its source when it has a single root block. The issue remains open.

Finally, on September 25, 2026, another contributor noted that the patterns screen still says “Not synced” even though style and structure are now locked, and proposed three clearer states.

What to take away

The new behavior stayed. Rather than rolling it back, WordPress added three exits: a setting for unsynced patterns, another for template parts, a command for the session. Locking is now the default posture: teams decide when to unlock, no longer when to lock.

For an existing site, the consequence is concrete: theme or agency patterns must be retested in content-only mode, and their structure, a single wrapper or not, changes their behavior. Also train your writers on the full-editing button and on detaching before they discover them alone. Our overview of what changed in WordPress 7 places this change among the other updates in 7.0 and 7.1.

A glass frame with fixed shapes where only small inner panels stay open

Registering patterns in a theme

The /patterns folder and its headers

Since WordPress 6.0, any PHP file placed in the active theme’s patterns folder is registered automatically as a pattern. A child theme overrides the parent’s pattern with the same identifier. The file header describes the pattern.

<?php
/**
 * Title: Hero
 * Slug: themeslug/hero
 * Categories: featured
 */
?>
<!-- wp:heading -->
<h2 class="wp-block-heading"><?php esc_html_e( 'Welcome', 'themeslug' ); ?></h2>
<!-- /wp:heading -->

Core only requires the title and the identifier, otherwise the file is skipped. The documentation recommends adding at least the categories. Other fields exist: description, keywords, preview width, block types, post types and template types, used in particular for the starter patterns offered when creating a page.

Translation, escaping and images

The title and description are translated with the theme’s text domain. Text inside the markup must go through escaped translation functions, such as esc_html_e(), and image addresses through esc_url( get_theme_file_uri() ), so they work whatever the site address.

The cache trap

Since WordPress 6.4, pattern file metadata is cached, and that cache depends on the theme version. Since 6.6, it is kept in a transient, so it persists on every site, even without a persistent object cache. An edited header may therefore not show up until the theme version changes. In development, the WP_DEVELOPMENT_MODE constant set to theme or all bypasses that cache.

Removing core and directory patterns

To slim down the inserter, a theme can remove core patterns and turn off loading of remote directory patterns.

add_action( 'after_setup_theme', function () {
	remove_theme_support( 'core-block-patterns' );
} );
add_filter( 'should_load_remote_block_patterns', '__return_false' );

No admin setting does this: it is code, to put in the theme or a small plugin. Note that this filter also blocks directory patterns declared in the patterns key of theme.json. Our guide to Full Site Editing and theme.json details other ways to curate the editor.

Pattern categories

Core categories and your own

WordPress 7.1 registers twenty-one categories, such as banner, buttons, columns, call to action, team, testimonials, gallery, header and footer. Use their exact technical identifiers: the theme documentation mistakenly lists a video identifier, whereas core registers videos. A theme can add its own categories with register_block_pattern_category().

Categories for patterns created by the team

Since WordPress 6.4, patterns created in the editor can also receive custom categories, managed like tags. That is the basis of a readable inserter for a team: one category per function, “Contact details”, “Legal notices”, “Calls to action”, rather than a pile sorted by creation date.

The WordPress.org Pattern Directory

Copy, paste, or declare in theme.json

The official directory offers about 2,350 patterns in English in October 2026, including a small selection highlighted by the WordPress team. You can copy a pattern and paste it in the editor, or declare it in the patterns key of the theme.json file with its identifier, so it appears in the inserter.

Once added to the site, the pattern keeps no link with the original. Its images, however, are still loaded from outside: the documentation advises uploading them to your media library.

A filtered directory by default

Since June 2023, the directory shows by default the patterns selected by the WordPress team, those that ship with core. Community patterns remain available behind a filter. Of the roughly 2,350 English patterns, only 44 belonged to that selection in October 2026, so most of what the directory holds comes from the community.

Submission rules

The directory only accepts patterns in English, built with core blocks, illustrated with openly licensed Openverse images and without dynamic blocks such as the Query Loop. Submissions are moderated by volunteers.

A working method for an editorial team

Decide what is synced

The most useful rule is simple: sync what must be identical everywhere, such as contact details, legal notices or a standard call to action. Use unsynced patterns for what shares a structure but not content, such as post or profile layouts. Overrides bridge the two, when the design must stay shared and the text vary.

The guide published in April 2025 by North Carolina State University’s communications office for the university’s websites follows the same logic: synced patterns for contact details, policies and standard calls to action, unsynced patterns for content that shares a structure. It also recommends documenting dependencies and warns that too many synced patterns on a page can slow it down.

Roles

Creating a synced pattern requires the right to publish posts: an Author can do it, a Contributor cannot. Editing other people’s patterns requires the right to edit others’ content, which Editors have. Combine these rights with canLockBlocks to reserve locking for those who manage the design. Our guide to WordPress user roles and capabilities details these rights.

Name, file, document

Give each pattern an explicit name, file it in a category by function, and note its dependencies: where it is used, who can edit it. Before editing a heavily used synced pattern, check the affected pages. The free Reusable Blocks Extended plugin lists the content where each synced pattern appears.

Moving patterns between sites

To move a pattern from one site to another, JSON export is enough. To turn patterns created in the editor into theme files, the Create Block Theme plugin saves them back into the active theme, with one caveat: its latest release is only declared tested up to WordPress 6.9.

On the command line, patterns created in the editor, synced or not, are wp_block content, which WP-CLI can list. Dedicated pattern commands are documented, but they are not yet part of the stable WP-CLI release in October 2026. Our selection of essential WP-CLI commands covers the commands available today.

wp post list --post_type=wp_block --fields=ID,post_title,post_modified

Performance and nesting

Synced patterns are not free in performance terms. An issue opened in June 2026 describes a site with about a hundred synced patterns that included one another, sometimes several times over: each repeated inclusion triggered a full new render, until the site could no longer load its own pattern list. Avoid cascading synced patterns inside each other, and limit how many sit on a single page.

Summary table

Unit	Link with the original	Where it lives	Best for
Unsynced pattern	None after insertion	Theme, plugin, database or directory	Post layouts, page sections
Synced pattern	Full, edited everywhere	Database	Contact details, notices, calls to action
Pattern with overrides	Shared design, content per instance	Database	Cards, testimonials, profiles
Template part	Shared by templates	Theme, then database if edited	Headers, footers
Content-only mode	Default since 7.0	Editor setting	Protecting layouts

Frequently asked questions

Are synced patterns the old reusable blocks?

Yes. WordPress 6.3 renamed reusable blocks to synced patterns, without changing how they work. The new part of that release was elsewhere: users can now create their own patterns in the editor, synced or not, whereas unsynced patterns from core and themes had existed since WordPress 5.5.

Can a theme ship a synced pattern?

Not in WordPress core as of October 2026: every pattern registered by a theme is unsynced. Only patterns created in the editor, and saved in the database, can be synced. A third-party plugin partly fills that gap.

Why can’t I move blocks inside a pattern since WordPress 7.0?

Because unsynced patterns are now inserted in content-only mode. Use the pattern’s full-editing button, or detach it. A developer can also turn this behavior off for the whole site with the dedicated filter, and since WordPress 7.1 anyone can suspend it for their own session from the command palette.

Can overrides change colors?

No. They only cover content: text, images, links, labels. Layout and styles remain those of the synced pattern.

How do I find where a synced pattern is used?

WordPress does not show it natively. The free Reusable Blocks Extended plugin adds a column to the pattern management screen listing the content that uses each synced pattern, next to the pattern’s last modification date.

Conclusion

Patterns have become the basic building block of layout in WordPress. Used well, they save you from rebuilding the same section ten times and ensure a piece of information changes everywhere at once. Misunderstood, they spread a mistake across a whole site, or block a writer who does not understand why nothing can be moved anymore.

Three decisions make the difference: what must be synced, who can lock and unlock, and how the team is trained on WordPress 7’s content-only mode. Make them explicitly, write them down, and the inserter becomes a tool again rather than a catalog.

Sources

LaFactory designs, builds and maintains WordPress and WooCommerce sites, and develops its own plugins. Talk to us about your WordPress project.

Francis Rozange

Former section editor at Libération, he runs LaFactory, an international web agency since 1996.