Synced Patterns vs Template Parts: Which to Use

Synced patterns vs template parts is a decision about one thing: whether you are reusing content or reusing structure. A synced pattern is content — one copy stored in the database, edited from the Patterns screen, pulled into as many posts as you like. A template part is structure — a region of a block theme’s layout that lives in the theme’s /parts folder and gets included by templates, not by posts.

Most of the confusion comes from a third thing that shares the same screen and the same inserter: the ordinary unsynced pattern, which copies its blocks into your post and then forgets where they came from. Those three cover almost every reuse case in a block theme. Picking the wrong one costs nothing on page one and a long afternoon on page fifty.

What each one actually is

All three arrive through the same Patterns screen in WordPress 7.1, which is exactly why they get muddled. Under the hood they are three different storage mechanisms with three different failure modes.

Unsynced patterns: a copy, and then you are on your own

Insert an unsynced pattern and the editor writes its blocks straight into post_content. There is no link back. Edit the pattern afterwards and the fifty pages already using it do not change, because they never pointed at it — they got a photocopy.

That is a feature, not a shortcoming. A hero section where every page needs a different headline and image wants exactly this behaviour. Unsynced patterns can come from your theme, from a plugin, from the Pattern Directory, or from blocks you select and save yourself.

Synced patterns: one copy, referenced everywhere

A synced pattern is stored as a post of type wp_block. That post type has been in core since WordPress 5.0, when the same feature was called a reusable block — the changeset that added it describes wp_block as “the reusable block post type”. WordPress 6.3 renamed reusable blocks to synced patterns and folded them into the unified Patterns screen; nothing about the storage changed, which is why a site that has been running since 2019 still has its old reusable blocks working.

The page that uses it stores only a reference:

<!-- wp:block {"ref":412} /-->

Because it is a post type, you can inventory synced patterns from the shell without any extra tooling:

# Every synced and unsynced user pattern on the site
wp post list --post_type=wp_block --post_status=publish \
  --fields=ID,post_title,post_name,post_modified

# Which posts use pattern 412
wp db query "SELECT ID, post_type, post_title FROM wp_posts
  WHERE post_content LIKE '%\"ref\":412%'" --skip-column-names

WP-CLI also has a dedicated wp block synced-pattern command with create, get, list, update and delete subcommands. Read the small print before you build a deployment script on it: the command reference states it is not yet in a stable WP-CLI release and requires the nightly build or the separate package. The wp post list approach above works on every install today.

Template parts: regions of the theme, not of the post

A template part is an .html file in the theme’s /parts folder containing block markup and nothing else. Nested folders are not supported, so every part sits directly in /parts. Templates do not pick them up automatically — a template has to include one explicitly, and the slug must match the filename without its extension:

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- Template content goes here. -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Register them in theme.json so they show up properly labelled in the Site Editor rather than as bare slugs:

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "templateParts": [
    { "area": "header", "name": "header", "title": "Header" },
    { "area": "footer", "name": "footer", "title": "Footer" },
    { "area": "uncategorized", "name": "sidebar", "title": "Sidebar" }
  ]
}

Core ships three areas: header, footer, and uncategorized, which the admin labels General. You can register your own with the default_wp_template_part_areas filter, supplying an area slug, an area_tag from the allowed set (div, article, aside, footer, header, main, section), a label, a description and an icon. Note the icon limitation: only header, footer and sidebar are supported, and anything else falls back to a generic icon rather than erroring.

Edit a part in the Site Editor and WordPress does not touch your theme file. It writes a database record that shadows it, the same way global styles shadow theme.json — which is the behaviour behind most “my theme update did nothing” reports. Customizing a block theme with theme.json or a child theme works through that cascade in detail, because it catches people on template parts exactly as it does on styles.

The criteria I judged these on

Stated up front so you can disagree with the weighting rather than the conclusion. These are the five questions that have actually decided it on client sites.

Synced patterns vs template parts vs unsynced patterns, compared

On a narrow screen this table stacks into one card per option.

Read down the “If you delete it” row before you do anything else. It is the row that explains why a synced pattern feels so convenient for six months and then costs you a bad morning.

Same layout, different content? Use pattern overrides

There is a case neither option handles well on its own: twenty author bio cards that must stay visually identical while each holds a different name, photo and blurb. A synced pattern gives you one shared copy of everything including the text. An unsynced pattern lets the twenty cards drift apart in padding and colour over two years.

Pattern overrides, added in WordPress 6.6, are the answer. You mark specific blocks inside a synced pattern as overridable; the design stays shared, and each instance supplies its own content.

1. Build the card, select the outer Group, and save it as a synced pattern.
2. Open it with Edit original so you are editing the pattern itself, not an instance.
3. Select a block, open the Advanced panel in the inspector, and click Enable overrides.
4. Give it a name. That name is the key WordPress uses to map each instance’s content to that block, so make it descriptive — “Author name”, not “Heading 2”.
5. Repeat for each editable block, then save. Named blocks show their names in List View.

Overrides are built on the Block Bindings API, so only blocks that support bindings can be overridden. As of WordPress 7.1 that is four block types: Heading, Paragraph, Image and Buttons. Attribute coverage is narrow too — Image exposes url, alt and title; Button exposes url, text, linkTarget and rel. If your card needs an overridable Columns block or a custom block, this is not yet your tool and there is no public opt-in to add one.

The API underneath reaches further than overrides do, and it is worth knowing about separately: it can pull a value from a custom field, a term, or a source you register yourself, and it covers two blocks — List Item and Post Date — that are not offered as overrides at all. The Block Bindings API and custom fields in core blocks covers that side of it, including how a bound block resolves inside a Query Loop.

In the pattern, an overridable paragraph carries a binding to the core/pattern-overrides source:

<!-- wp:paragraph {"metadata":{
  "name":"Author bio",
  "bindings":{"__default":{"source":"core/pattern-overrides"}}
}} -->
<p>Default bio text, shown until an instance overrides it.</p>
<!-- /wp:paragraph -->

The page using it then stores its own values on the reference block’s content attribute, keyed by the names you chose:

<!-- wp:block {"ref":412,"content":{
  "Author bio":{"content":"Writes about block themes and performance."}
}} /-->

Patterns in theme files beat patterns in the database

If you have file access, register patterns in the theme rather than saving them in the editor. A PHP file in /patterns with a header comment is all it takes, and you get a reviewable, deployable artefact instead of a database row nobody can diff:

<?php
/**
 * Title: Pricing callout
 * Slug: wpfairs/pricing-callout
 * Categories: call-to-action
 * Keywords: pricing, offer, cta
 * Block Types: core/post-content
 * Post Types: page
 * Viewport Width: 1280
 * Inserter: yes
 */
?>
<!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group">
  <!-- wp:heading -->
  <h2 class="wp-block-heading"><?php esc_html_e( 'Simple pricing', 'wpfairs' ); ?></h2>
  <!-- /wp:heading -->
</div>
<!-- /wp:group -->

Only Title, Slug and Categories matter for most patterns. The ones worth knowing about are the filters: Post Types restricts where it appears, Block Types associates it with a block so it is offered as a replacement for that block, Inserter: no hides it from the inserter entirely (useful for a pattern that exists only to be referenced from a template), and Template Types suggests it for specific templates such as home or single.

A template can then reference that pattern by slug instead of inlining it:

<!-- wp:pattern {"slug":"wpfairs/pricing-callout"} /-->

That gives you something close to the best of both: the markup lives in one file under version control, and every template referencing it picks up your next edit. It is how the default themes are built.

Worth checking the pattern files of a theme you trust before writing your own. Twenty Twenty-Five ships free with WordPress and is a good reference. The theme running this site organises its /patterns and /parts folders the same way — disclosure: I build and maintain Bloqra, the theme and block plugin used here — but nothing in this article is specific to it. Everything above is core behaviour, and a default theme is the better place to learn it because you can compare against the Handbook line by line.

Four ways this goes wrong

What changed in WordPress 7.1

Two changes in 7.1 matter here, and one of them will bite anyone maintaining editor JavaScript.

You can turn off content-only editing for template parts. Template parts default to content-only editing, which locks the structure and lets editors change text. WordPress 7.1 adds a disableContentOnlyForTemplateParts editor setting to restore standard block editing, settable from PHP via the block_editor_settings_all filter or from JavaScript:

wp.data.dispatch( 'core/block-editor' ).updateSettings( {
	disableContentOnlyForTemplateParts: true,
} );

One caveat from the release notes: in template-locked rendering mode, content-only editing for template parts stays disabled regardless of the setting. For a one-off change there is now a command-palette entry — “Enable/Disable content-only editing for patterns and template parts” — which covers patterns too and lasts for the session only. That is the right tool when a client reports they “can’t move anything” in the footer; you do not need a filter for a five-minute fix.

The @wordpress/reusable-blocks package is now a no-op. Its public APIs log deprecation warnings starting in WordPress 7.1, and the package reference states the module is deprecated: the menu item component renders nothing and the store’s conversion and editing actions do nothing. Core stopped using it in 2023. If you have a plugin importing from it, the replacement for entity work is @wordpress/core-data against wp_block entities — and be aware there is no public replacement for the conversion utilities or menu items, so code that converted blocks to reusable blocks programmatically needs rethinking rather than porting.

Nothing in 7.1 changed pattern overrides, so the four-block limit above still stands. The Block Bindings API did gain one block in this release — List Item — which is a bindings-only addition rather than an overrides one. If you are catching up on the release more broadly, the new responsive style controls are the change most likely to affect how you build a pattern in the first place.

So which should you use?

• Header, footer, sidebar, or a loop region: template part. There is no real contest — these are addressed by templates, and nothing else can be.
• A legal line, VAT number or disclaimer that appears mid-content on forty pages: synced pattern. One edit, forty pages, and an Editor-role user can do it without Site Editor access.
• A section layout authors should fill in differently each time: unsynced pattern, registered in the theme’s /patterns folder so it stays in Git.
• Identical design, different text, repeated many times: synced pattern with overrides — but only if your editable blocks are headings, paragraphs, images or buttons. Anything else, use an unsynced pattern and accept the drift.
• Identical design, different text, driven by data rather than typed per page: skip overrides and bind the blocks to custom fields instead. One pattern in a Query Loop fills itself in from each post’s own values.
• A client site with a deployment pipeline: put structure in theme files and keep synced patterns for content the client genuinely owns. Database-only reuse is invisible to your repo and to code review.
• No file access at all — managed host, no SFTP: synced and unsynced patterns saved in the editor are your whole toolkit, and that is fine. Keep a plain-text export of anything important somewhere outside WordPress.
• Coming off a page builder: patterns are the native replacement for its template library, and template parts for its theme builder. Comparing the major page builders against the block editor is worth reading before you commit either way, because the migration is the expensive part.

One habit that pays for itself: write down which reuse mechanism holds what. “Header and footer are template parts in the theme; the compliance footnote and the shipping banner are synced patterns; everything else is unsynced” is three lines in a README, and it saves the next person — usually you, in eight months — from editing a page and wondering why nothing changed.

Frequently asked questions

Sources

• Template Parts — WordPress Theme Handbook, for the /parts folder rules, the wp:template-part markup, templateParts in theme.json, and the area and area_tag values
• Registering Patterns and Usage in Templates — the pattern file header fields and the wp:pattern slug reference
• Core changeset 44146 — the commit registering wp_block as “the reusable block post type”
• Synced Patterns: The Evolution of Reusable Blocks — the 6.3 rename and the synced versus unsynced behaviour
• An introduction to overrides in Synced Patterns — the core/pattern-overrides binding, the per-block attribute coverage, and the opt-in limitation
• Explore synced pattern overrides — Learn WordPress, for the current four supported block types
• Miscellaneous editor changes in WordPress 7.1 — disableContentOnlyForTemplateParts, the command palette toggle, and the @wordpress/reusable-blocks deprecation warnings
• @wordpress/reusable-blocks — the no-op status and the @wordpress/core-data guidance
• wp block synced-pattern — WP-CLI command reference, including the note that it is not yet in a stable release
• Create Block Theme issue 894 — the Site Editor copying theme patterns into templates with metadata.patternName instead of keeping a reference