An editor wants to change the text on one service card. The developer wants the cards to keep sharing a consistent layout.
Both requests sound reasonable. The trouble begins when changing one sentence either updates every card on the site or requires detaching the whole section from the design it was meant to share.
WordPress 6.6, released in July 2024, introduces overrides for synced patterns.1 They allow supported content in individual instances to vary while the shared pattern continues providing the design.
It’s a useful middle ground. Think of giving each room its own welcome note without asking the editor to rebuild the hotel.
Try one reusable section before changing the whole site
Choose a simple recurring section with a clear purpose. A fictional service card with a heading, description, image and link makes a reasonable test.
Nick Diego’s introduction explains the mechanics behind pattern overrides.2 The important editorial decision is which parts should vary and which should remain shared.
Separate local content from shared design
A synced pattern ordinarily keeps its instances connected. That is useful for a call to action whose content really should change everywhere.
A service card may need the opposite relationship for its content: a different title, description and destination in each instance, with a common arrangement and style.
Identify that distinction before implementation. If the editor cannot predict whether a change is local or shared, the feature needs clearer guidance.
A control labeled Edit doesn’t automatically explain the radius of the consequences. We should probably help with that before the About page begins campaigning for the plumbing service.
Custom WordPress themes are our bread and butter. See our WordPress services.
Work within the supported capabilities
The 6.6 release describes overrides for supported content in Heading, Paragraph, Button and Image blocks within synced patterns.
That is a defined capability, not permission to assume every block attribute or plugin component can be overridden in the same way. Verify what the chosen version and blocks actually support.
The design remains a separate responsibility too. A shared pattern still needs sensible spacing, responsive behavior and accessible interactions. Linking several copies together can spread a good decision or an awkward one with equal enthusiasm.
Build the first example with realistic text and images before expanding its use.
Check both kinds of edit
Create more than one instance with different content. Change a local value and confirm that the other instance retains its own content.
Then rehearse a shared pattern-design change and inspect the instances again. Include a longer heading, an optional image scenario where supported and a narrow viewport.
This is a small acceptance test that teaches the team what the connection means. It is easier to learn with a demonstration page than with a sitewide call to action on a busy afternoon.
Also review the editor’s reset and recovery behavior so people know how to return to an intended value when necessary.
Compare the pattern with the content model you need
A structured ACF approach can solve related problems through developer-defined layouts and subfields.3 The theme renders those values through its templates.
That is different from native pattern overrides. ACF Flexible Content doesn’t become a synced pattern simply because both approaches help build repeated sections.
Worth reading next: The WordPress editor is part of the website experience.
| Synced pattern with overrides | ACF Flexible Content | |
|---|---|---|
| How it works | A shared pattern provides the design while supported content varies in each instance | Developer-defined layouts and subfields, rendered through the theme’s templates |
| What can vary | Supported content in Heading, Paragraph, Button and Image blocks (WordPress 6.6) | The fields the developer defines for each layout |
| Often suits | Editors comfortable in native blocks, where the supported overrides fit | Sections that need a more specific content structure, or an established ACF theme |
Choose for the editing task
If the editor works comfortably in native blocks and the supported overrides fit, a pattern-based approach may be attractive.
If the section needs a more specific content structure or is part of an established ACF theme, structured fields may provide a clearer experience. There may also be a sensible combination, provided the team can explain who controls each layer.
The choice shouldn’t be a referendum on which editor is more modern. Watch someone create the page they actually need to maintain.
Give the section a useful name, explain its local and shared values and avoid offering controls that invite accidental design drift. Flexibility is helpful when the available choices correspond to real work.
For an existing site, test compatibility and the intended editing flow before adopting the new feature broadly. A release improvement is an opportunity to evaluate, not an instruction to rebuild a working theme overnight.
What I like here is the possibility of giving editors more useful freedom with fewer styling decisions to remember.
The editor can change the welcome note. The hotel can keep its windows in roughly the same places.