Pattern overrides solve the most frustrating limitation of synced patterns in WordPress: you want a consistent structure site-wide, but content editors need to customize specific parts on a per-use basis. Introduced via the Block Bindings API in WordPress 6.6 and expanded into a fully stable, first-class feature in WordPress 7.0, pattern overrides remove the all-or-nothing constraint that made synced patterns impractical for real client content.
This post covers how the feature works technically, what WordPress 7.0 adds specifically, how to implement it in a block theme, and what the expanded block support means for the kinds of patterns you can build. If you deliver block themes to clients or maintain a shared component library, this is the WordPress 7.0 feature with the most immediate practical impact on your day-to-day theme development.
The Problem Pattern Overrides Solve
Before pattern overrides, synced patterns (previously called reusable blocks) in WordPress had a binary behavior: either every instance of a pattern was identical, or you broke sync and each instance became fully independent. Neither option worked well for common block theme components.
Consider a team member card. You want the layout, the image placement, the heading hierarchy, the typography, the spacing, to be consistent across every instance on every page. That is exactly what synced patterns are for. But you also need each instance to show a different person’s name, photo, title, and bio. With a fully synced pattern, editing one card changes every card on the site. With a non-synced pattern, you lose layout consistency and structural updates must be made manually to every instance.
The same constraint affected testimonials, pricing tiers, feature cards, and any other repeating structural component where layout is shared but content differs. Theme developers worked around it by building these as separate non-synced patterns or custom blocks, both of which add maintenance overhead that synced patterns were supposed to eliminate.
Pattern overrides change the model entirely. You define which blocks within a synced pattern are locked (structure, styling, layout) and which are overrideable (content). Editors can customize the overrideable blocks per-instance without affecting any other instance and without breaking structural sync across the site.
How Pattern Overrides Work Technically
Pattern overrides are built on top of the Block Bindings API, which was introduced in WordPress 6.5. The Block Bindings API provides a way for block attributes to pull their values from registered data sources. Pattern overrides register core/pattern-overrides as one of those sources, meaning specific block attributes can bind to instance-level override data stored with the pattern usage, not the pattern definition.
When a block inside a synced pattern has its attribute bound to core/pattern-overrides, WordPress separates that attribute from the shared pattern data. The block’s overrideable attribute gets stored with each individual instance of the pattern on the page or template it appears in, while the rest of the pattern’s blocks remain fully synced. Editing one instance’s bound attributes does not touch any other instance.
The Block Markup
In block markup, a pattern override is declared using two fields in a block’s metadata attribute: an id (unique within the pattern) and a bindings object that maps specific block attributes to the core/pattern-overrides source:
The id field is how WordPress links the per-instance override data to the correct block. It must be unique within the pattern, two overrideable blocks in the same pattern cannot share an id. The bindings object specifies which attributes are overrideable; only those attributes can be edited per-instance, everything else remains synced.
The Editing Experience
In the block editor, overrideable blocks within a synced pattern are visually distinct. When an editor clicks into a synced pattern, overrideable blocks are highlighted as editable while structural blocks remain locked. The editing UI shows which blocks can be customized for this instance and which are locked to the pattern definition.
When an editor modifies an overrideable attribute, the change is stored on the specific block that includes the pattern, a block with a ref pointing to the stored pattern post. Other instances of the same pattern on other pages are unaffected. If a theme update later changes the pattern’s locked structure, those structural changes propagate to all instances, but the per-instance content overrides are preserved.
What WordPress 7.0 Changes
The March 16 make.wordpress.org announcement covering the WordPress 7.0 pattern overrides changes includes several significant improvements over the 6.6 implementation.
Stable APIs: Experimental Prefix Removed
Several Block Bindings and pattern override APIs that shipped with __experimental prefixes in 6.5 and 6.6 are stabilized in WordPress 7.0. This matters for theme and plugin developers because experimental APIs are not considered part of the public API surface and can change without notice between major versions. Code built on experimental APIs accumulates technical debt as those prefixes are removed or signatures change.
With WordPress 7.0, the pattern overrides binding source (core/pattern-overrides) and the block binding registration functions move out of experimental status. You can now build production block themes targeting pattern overrides without the risk of API-level breakage on the next WordPress update.
Expanded Block Support
WordPress 6.6 supported pattern overrides on four core blocks: Paragraph, Heading, Image, and Button. WordPress 7.0 expands the list of blocks that can be configured as overrideable within a synced pattern. The expanded support includes additional block types that appear commonly in real-world theme components, reducing the need for custom block development to fill the gap.
Concretely, this means patterns like product cards, event listings, and content modules that previously required custom blocks or workarounds can now be built as synced patterns with appropriate attributes marked as overrideable. The range of overrideable attributes also expands, the Image block, for example, gains override support for additional attributes beyond the basic url and alt that were available in 6.6.
Site Editor Integration Improvements
The WordPress 7.0 Site Editor includes UI improvements specifically for pattern override management. Pattern instances with active content overrides are now marked in the pattern list, making it easier to audit which instances have been customized. There is also improved handling for the case where a synced pattern is updated to remove a block that previously had an override, the orphaned override data is now cleaned up rather than silently stored.
Performance: Override Data Storage
WordPress 7.0 improves how per-instance override data is stored and retrieved. In 6.6, override data was embedded in the block comment delimiter of the block that used the pattern, which created performance issues for pages or templates using many instances of the same pattern with overrides. The 7.0 storage model reduces the per-instance data size and improves how it is handled by the block parser, which is relevant for themes using patterns heavily in their templates.
Implementing Pattern Overrides: A Practical Example
Here is a complete implementation of a team member card pattern with overrides, one of the most common use cases. The pattern is synced so the card layout stays consistent, but the image, name, role, and bio are all overrideable per-instance.
The pattern file goes in your theme’s /patterns/ directory. The header comment declares it as synced and assigns it to the appropriate category:
A few things to note about this implementation. First, the outer Group block has no override bindings, its layout, styling, and spacing are part of the locked structure. Changing the card’s padding in the pattern definition will update every instance on the site. Second, every overrideable block has a unique id within the pattern, member-photo, member-name, member-role, member-bio. Third, the Image block binds both its url and alt attributes, which means the editor can update both when customizing an instance.
When an editor inserts this pattern and then clicks into a single instance, they see the image placeholder, name, role, and bio fields as editable. They type directly into the blocks just as they would in a regular post, no custom UI, no metaboxes, no shortcodes. Saving updates only that instance. The layout, colors, spacing, and any locked blocks remain identical to every other instance across the site.
Syncing the Pattern on Theme Activation
Pattern files in the /patterns/ directory are registered as unsynced by default when WordPress reads the directory. To create a synced pattern from a theme file, you need to either use the Synced: true header in the pattern file (supported since WordPress 6.3) or register it explicitly in PHP. The Synced: true header approach is simpler and recommended for most use cases, WordPress handles creating the corresponding wp_block post on theme activation and keeps it in sync with the pattern file.
Supported Blocks and Attributes in WordPress 7.0
The following core blocks support pattern overrides in WordPress 7.0, along with the specific attributes that can be bound to core/pattern-overrides:
Paragraph
Supports override on the content attribute, the visible text content of the paragraph. This is the most commonly used override and covers the majority of text-based content customization needs.
Heading
Supports override on the content attribute. The heading level (h2, h3, etc.) is part of the locked structure and cannot be overridden per-instance. If you need editors to control heading level, use a Paragraph block instead and style it to match.
Image
Supports override on url, alt, and title. In WordPress 7.0, the Image block also gains override support for caption and linkDestination. When an editor customizes an image override, they use the standard image replacement UI, the block’s override fields appear in the block toolbar and sidebar rather than inline.
Button
Supports override on text, url, and linkTarget. This makes Button blocks inside synced patterns usable for real call-to-action components, editors can set the button label and destination URL per-instance while the button’s styling (colors, border-radius, font size) remains locked to the design system.
What Is Not Supported
Structural attributes, block-level alignment, color settings, typography settings, spacing, are not overrideable per-instance through pattern overrides. This is by design: if every instance could override its own colors and spacing, the consistency guarantee of synced patterns would be meaningless. Block overrides are specifically scoped to content attributes, not design attributes.
Complex blocks like Query Loop, Cover, and Columns do not support content overrides directly, though they can contain overrideable blocks (a Paragraph inside a Column inside a Columns block can be overrideable). If you need per-instance control over a complex block type, custom block development is still the right path.
Real-World Use Cases for Block Theme Developers
Team Member Cards
The canonical example: a card layout with consistent styling across all cards, with the photo, name, job title, and bio as overrideable per-instance. Build once, maintain the design in one place, allow content team to add new team members without touching the Site Editor’s pattern management.
Testimonials
Testimonial components with consistent quote formatting, attribution styling, and layout, with the quote text, attribution name, and company as overrideable. When you update the testimonial card design (border, background, typography), every testimonial on the site updates. Content stays in place.
Feature and Pricing Cards
Pricing tier cards where the plan name, price, feature list description, and CTA button text and URL are overrideable, but the card structure, color scheme, and spacing are locked. A design update to the pricing section, changing the card border or button style, propagates to all tiers simultaneously.
Hero Sections with Custom CTAs
Hero sections where the headline, subheadline, and call-to-action button text and URL are overrideable but the background, layout, and visual treatment are locked. This is especially useful for landing page templates where each page gets a consistent visual frame but its own headline and CTA copy.
Service or Product Cards
Repeating content modules for services, products, or case study summaries, where the card structure is identical but the title, description, and link vary. Pattern overrides eliminate the need to register a custom Query Loop template part or a custom block just to handle repeating differently-titled items.
Pattern Overrides vs Block Bindings: Understanding the Distinction
Pattern overrides use the Block Bindings API, but they are a specific source within that API, not the same thing as Block Bindings in general. It is worth understanding the distinction because the two features are frequently confused in documentation and tutorials.
The Block Bindings API allows block attributes to bind to any registered source. Built-in sources as of WordPress 7.0 include core/post-meta (reads from post meta fields), core/site-data (reads from site settings like title and tagline), and core/pattern-overrides (reads from per-instance override data stored on the pattern usage).
When you bind a block attribute to core/post-meta, the block displays a value from a post meta field, the same field for every post, but the value changes based on which post the template is rendering. This is useful for custom post type templates where structured data is stored in meta fields.
When you bind to core/pattern-overrides, the value comes from override data specific to that instance of the pattern, set directly in the editor per-instance, not from a database field. The distinction is who sets the data: pattern overrides are set by whoever is placing the pattern on a page or template, while post meta bindings are set by the post’s meta values.
For most content component use cases in block themes, cards, callouts, testimonials, core/pattern-overrides is the right choice. For template parts that need to display structured data from posts or custom post types, core/post-meta bindings are more appropriate. The two approaches can coexist in the same theme.
Patterns with Overrides in Block Theme Development Workflows
Documenting Overrideable Blocks for Clients
When you hand off a block theme that uses synced patterns with overrides, the editor experience is intuitive enough that most clients figure it out without documentation. But it is still worth noting which blocks within a pattern are locked versus overrideable in your theme documentation or client onboarding materials. The visual indicator in the editor (locked blocks appear non-interactive when the cursor moves to them) is a hint, but a written note in the client handoff, “each team member card lets you change the photo, name, title, and bio, but the card layout and styling are managed centrally”, prevents support tickets.
Using Overrides in Starter Theme Patterns
For starter themes or theme frameworks, pattern overrides are worth designing around from the start. Building your common reusable components, cards, callouts, hero sections, as synced patterns with appropriate override bindings from the beginning is significantly easier than converting non-synced patterns later. The conversion requires recreating the pattern as synced and migrating any existing content into the override model, which is a manual process on deployed sites.
For block theme patterns that ship with a theme and are intended to be customized by the theme user after activation, the synced patterns workflow applies: the theme registers patterns on activation, editors customize them per-instance using overrides, and structural updates to the pattern propagate through the theme update mechanism.
Handling Override Data in Staging and Production
Per-instance override data is stored in post content (in the block comment delimiters), not in a separate database table. This means it moves with post content when you export and import or synchronize a staging environment to production. If you use WP-CLI’s wp export/wp import workflow or a database sync tool, override data travels with the posts that contain the pattern instances. There is no additional step to migrate override data separately.
However, the synced pattern itself (the wp_block post that defines the shared structure) is also a database record. Pattern posts need to be included in any database migration or they will appear as missing patterns on the destination environment. If you are managing pattern data across environments, ensure your sync process includes the wp_block post type.
Common Implementation Mistakes
Duplicate Block IDs Within a Pattern
The most common error when building patterns with overrides is assigning the same id value to multiple overrideable blocks within the same pattern. WordPress uses the id to look up the correct override data for each block; duplicate IDs cause the wrong data to be displayed or for overrides to silently fail. Every overrideable block in a pattern needs a unique id string.
Overriding Non-Content Attributes
Attempting to bind design attributes, backgroundColor, fontSize, textAlign, to core/pattern-overrides will not work. The override system is specifically scoped to content attributes. Design attribute bindings at the instance level require either custom block development or a different approach entirely. If you are trying to allow per-instance color choices, you are outside the scope of what pattern overrides are designed for.
Nested Synced Patterns
Nesting a synced pattern inside another synced pattern and attempting to use overrides on the inner pattern produces unreliable results in WordPress 6.6 and earlier. WordPress 7.0 improves handling for this case but it is still an edge case worth avoiding. If your design requires nested reusable components, structure them as a single pattern with appropriately scoped override blocks rather than nested synced patterns.
Forgetting the Unique ID Per Pattern Instance vs Per Pattern Definition
Block IDs in the metadata.id field only need to be unique within a single pattern definition, not globally across all patterns on the site. Two different patterns can both have a block with "id": "heading" and this is fine, because the override data is always scoped to the specific pattern it belongs to. The uniqueness constraint is per-pattern, not per-site.
What to Read Before and After This
Pattern overrides build on several foundational concepts. If you are new to synced patterns, our guide to synced patterns in block themes covers the creation, registration, and management workflow before you add override bindings. If you are coming from an unsynced pattern workflow, the guide to custom block patterns explains how patterns are registered and structured, the same fundamentals apply to synced patterns.
For the broader context of block theme development in WordPress 7.0, the theme.json reference guide covers how global styles interact with pattern styling, relevant because locked pattern attributes pull their visual treatment from theme.json settings, and understanding how to layer block-level styles on top of global settings determines how much design flexibility patterns inherit versus require explicit overrides.
Summary
Pattern overrides in WordPress 7.0 represent the feature reaching production-ready maturity. Stable APIs, expanded block support, improved storage performance, and better Site Editor integration combine to make synced patterns with overrides the right default approach for reusable content components in block themes, not an experimental workaround.
The technical model is straightforward once you understand the distinction: the pattern definition holds the structure (locked, synced, updated via theme or pattern manager), and the core/pattern-overrides bindings hold the content (per-instance, edited directly in the block editor, stored with the content). Every team member card, testimonial, and pricing tier that previously required a custom block or a fragile non-synced pattern copy is now a cleaner implementation using a synced pattern with the right bindings.
Build your reusable theme components as synced patterns with appropriate override bindings from the start. The maintenance benefit, update the design in one place, content stays in place, is significant, and with WordPress 7.0 the API foundation is stable enough to build on for the long term.