Block Patterns and Pattern Overrides Clients Keep Using

#The editor clients abandon

A block theme is handed over. The client opens the editor to add a testimonial section, faces a blank canvas and a block inserter with two hundred options, tries to rebuild what the designer made, gets something slightly wrong, and gives up. Six months later every content change is an email to the developer, and the block editor's promise, that clients can build pages themselves, has quietly failed.

The editor experience is not the block editor. It is what the theme gives the client to start from and how much it lets them break. Patterns, synced patterns with overrides, and locking are the tools, and used together they produce an editor clients keep using.

#Patterns: the starting points

A pattern is a pre-built arrangement of blocks the client inserts as a unit: a hero with heading, text and button; a three-column feature grid; a testimonial with photo and quote; a pricing table; a CTA band. Once inserted, it is ordinary blocks the client edits freely.

Register them in the theme's patterns/ directory as PHP files with a header:

<?php
/**
 * Title: Testimonial with photo
 * Slug: acme/testimonial-photo
 * Categories: acme-sections
 * Description: A quote, the client's name and role, and a photo.
 */
?>
<!-- wp:group {"className":"testimonial","layout":{"type":"constrained"}} -->
<div class="wp-block-group testimonial">
  <!-- wp:quote -->
  <blockquote class="wp-block-quote"><p>Quote goes here.</p><cite>Name, Role</cite></blockquote>
  <!-- /wp:quote -->
  <!-- wp:image {"sizeSlug":"medium"} --><figure class="wp-block-image"><img alt=""/></figure><!-- /wp:image -->
</div>
<!-- /wp:group -->

Register a custom pattern category with the client's name so their patterns sit together at the top of the inserter, and hide the core patterns they will never use (remove_theme_support('core-block-patterns')). A client who sees eight patterns named for their site's sections, and nothing else, builds pages.

Patterns should use the theme's design tokens (colours, spacing, font sizes from theme.json) by name, not hard-coded values, so they stay on-brand when the tokens change.

#Synced patterns and overrides: locked structure, editable content

A regular pattern is a template; once inserted, the client can change anything about it, including breaking the layout. A synced pattern (what used to be a reusable block) is a single source: edit it once, every instance updates. That is right for a footer CTA that must be identical everywhere and wrong for a testimonial where each instance has different text.

Pattern overrides, since WordPress 6.6, resolve this. A synced pattern can mark specific blocks as overridable: the heading text, the paragraph, the image, the button label and URL. Every instance shares the structure and styling from the source; each instance has its own content in the overridable slots. The client cannot move the image below the quote or change the padding, because those are not overridable. They can change the words and the photo, because those are.

In the editor: create the pattern, select a block inside it, enable "Allow overrides" in the Advanced panel and give it a name. Currently overrides support paragraph, heading, button and image content. For anything structural, this is the pattern to reach for.

#Locking: what cannot move

For templates and for patterns where even a regular block should not be moved or removed, block locking. On any block, the lock options prevent moving, removing, or both, and can apply to inner blocks. In a pattern's markup:

<!-- wp:group {"lock":{"move":true,"remove":true},"templateLock":"insert"} -->

templateLock on a container controls what happens inside it: "all" prevents any change to which blocks exist; "insert" allows reordering but not adding or removing; "contentOnly" hides all block controls and shows only content fields, which is the strongest form and often the right one for client-facing sections.

Locking is reversible by anyone who can edit the block's code, so it is a guardrail, not a security boundary. Combine it with a role: clients as Editors, who by default cannot unlock, with the unlock capability left to Administrators via block_editor_settings_all filters.

#Templates and template parts

Page templates in a block theme are block markup too. A "Service" template with a locked structure (hero pattern, content area, related services, CTA) and contentOnly locking on everything except the content area means a new service page is: choose the template, fill in the fields, publish. The client never sees a blank canvas.

Template parts (header, footer, sidebar) are edited in the site editor by the client for things like the phone number, and locked for everything else.

#theme.json: the design system as guardrails

Patterns and locking control structure. theme.json controls the choices available inside it:

• Palette: only the brand colours, with custom colours disabled ("custom": false). The client cannot pick an off-brand red.
• Font sizes and families: the type scale only, custom sizes disabled.
• Spacing: a spacing scale, custom spacing disabled.
• Layout: content and wide widths set, so alignments stay consistent.
• Per-block settings: disabling options that the design does not use (drop caps, duotone, border radius on images) so the sidebar is short.

A client editing a paragraph sees five colours, four sizes and nothing else. That is the constraint that makes the editor feel like their site rather than a generic tool.

#The checklist for a client-ready editor

1. A pattern category named for the client, with eight to fifteen section patterns, using theme tokens.
2. Core patterns hidden.
3. Synced patterns with overrides for repeated structural sections.
4. contentOnly locking on templates outside the free content area.
5. theme.json with custom colours, sizes and spacing disabled; unused block options off.
6. Clients as Editors; unlocking reserved for Administrators.
7. A recorded walkthrough showing how to insert each pattern and edit the overrides.

#Where this sits

This is how we build the editor on every block-theme WordPress project, and it is the part of the build clients notice most, because it is the part they touch. A theme that looks right on launch day is table stakes. A theme the client is still confidently editing a year later is the thing patterns and overrides buy.