Client‑Proofing WordPress: Locking Block Patterns in Full Site Editing (FSE)

Full Site Editing (FSE) gives non‑technical users unprecedented control over WordPress layouts. Unfortunately that power comes with risk: an enthusiastic client can accidentally drag rows into columns, remove essential buttons or change padding that breaks the responsive layout. Agencies spend hours perfecting a design only to see it unravel after a week of client edits. With WordPress 6.9 and the block editor continuing to mature, it’s time for a client‑proofing WordPress strategy that preserves creative freedom while protecting the structure.

Why clients break beautiful FSE sites

FSE turns templates, headers, footers and patterns into editable blocks. By default, every block can be moved or deleted through the block toolbar. WordPress 6.0 introduced a block‑locking UI in the options menu so designers can prevent certain blocks from being moved or removed. However, this feature is enabled for all users; without guardrails, a client might unlock a header block and remove it entirely. Removing a lock requires only a click, so agencies need deeper controls.

Another problem is that default themes expose every design control—colors, spacing, typography—to every user. Clients who only need to change copy and images can also adjust margins, swap flex layouts or insert additional columns, potentially breaking the layout. To deliver a resilient site, developers must curate the editing experience, hiding advanced controls and limiting where new blocks can be added.

Understanding block locking and template locks

Each block in WordPress can include a lock attribute with two keys: move and remove. Setting move: true in the markup disables the ability to drag a block to a new position, while remove: true prevents deletion. These settings can be applied directly in the block markup of a pattern or template to freeze the position of headers, logos, buttons and other critical elements.

For broader control, WordPress provides a template lock mechanism. Container blocks such as Group, Cover and Columns accept a templateLock attribute that governs how their inner blocks behave. There are three options:

• all – Users cannot insert, move or remove blocks inside the container.

• insert – Users cannot add new blocks but can move or remove existing ones.

• contentOnly – Introduced with WordPress 5.9, this mode hides block toolbars and design controls and lets users edit only text and media. It’s perfect for marketing teams who need to update copy or images but shouldn’t touch padding or columns.

When you apply templateLock: "contentOnly" to a container block, the editor hides non‑content blocks from the list view and disables their toolbars. Users can click directly into headings, paragraphs and images to modify the content. This mode offers what agencies want: a truly content‑only editing experience that shields the layout from accidental changes.

Building content‑only block patterns

To client‑proof a section, wrap your design in a container block with design settings (colors, padding, background images) and then nest a second container where actual content lives. Set the outer group’s design controls in code and add templateLock: "contentOnly" to the inner group. Brian Coords demonstrates this pattern by placing a nested group for editable content inside another group controlling the background and spacing. When registered as a pattern, editors see only the editable headings, paragraphs and images; they cannot add new buttons or break the alignment.

Here is a simplified example of a pattern file:

The inner group hides its toolbar, allowing only text edits. This approach ensures that the call‑to‑action button you placed outside the editable group stays aligned and styled correctly. Because contentOnly hides non‑content blocks, you should mark editable text and media fields with the __experimentalRole: "content" attribute to ensure they remain editable in the next releases.

Disabling locking for clients and controlling permissions

By default, any user can toggle the lock state of a block using the options dropdown. WordPress 6.0 added a canLockBlocks setting to the block editor configuration that allows developers to globally enable or disable this capability based on user roles. In the official dev note, George Mamadashvili shows how to hook into the block_editor_settings_all filter to restrict who can lock or unlock blocks. The example sets canLockBlocks to allow only users with the delete_others_posts capability (Editors and higher) and disables block locking for specific users or post types. This ensures that clients with Author or Contributor roles cannot unlock your carefully crafted patterns.

If you register custom blocks, you can also remove the locking UI entirely by setting supports.lock to false in the block definition. The block supports documentation explains that a block may want to disable the lock controls; by declaring "supports": { "lock": false } the block hides the lock/unlock UI. This prevents clients from toggling lock settings on structural blocks while still letting administrators unlock them in code.

Customising theme.json for a curated editing experience

Beyond locking, the theme.json file provides a central place to enable or disable design controls. You can remove color pickers, spacing controls, custom typography and more so that non‑technical users don’t accidentally change the design system. A curated experience might enable a few preset colors and typography options while hiding margin and padding controls. The Global Settings & Styles handbook notes that theme.json allows per‑block configuration of available settings—e.g., enabling font size controls for paragraphs but not headings. For even finer control, James Amner suggests using the wp_theme_json_data_theme filter to merge additional settings dynamically based on user capabilities. His article on restricting site editing shows how to apply a dynamic theme configuration so some users can edit content while others cannot change colours or alignmentamner.me.

If you’re building bespoke blocks, you can also disable design controls by setting supports.spacing or supports.color to false in the block registration. That way, even if a user edits the block directly in the site editor, they will only see the fields you want them to edit.

Creating “content‑only editing” modes with PHP

For classic themes or hybrid setups, you can implement content‑only editing entirely in PHP. Here’s a basic approach:

1. Register a block pattern in PHP using register_block_pattern() and include the nested group structure described above. Assign templateLock => 'contentOnly' to the inner group to limit editing to text and media.

2. Hide the locking UI on structural blocks by declaring supports => array('lock' => false) in your block’s block.json file or registration code. This prevents clients from changing lock states.

3. Restrict who can unlock blocks by hooking into block_editor_settings_all and setting canLockBlocks based on capabilities. The official example uses current_user_can( 'delete_others_posts' ) to restrict unlocking to editors and administrators.

4. Remove full site editing features if you want to preserve a classic workflow. Gutenberg Times notes that you can remove the template editor entirely by adding remove_theme_support('block-templates') in functions.php.

This combination gives developers granular control. Clients with lower capabilities see only the content they can edit, while editors and developers retain full access to lock and unlock blocks when necessary.

Best practices and gotchas

• Test your patterns in the editor. Even when locked, blocks retain their normal settings behind the scenes. A client with administrator privileges could still unlock and rearrange them. Communicate clearly who should have full access.

• Balance flexibility and rigidity. Locking everything can frustrate creative teams. Use contentOnly for sections where structure matters (hero banners, testimonials) and leave more open areas like blog posts flexible.

• Stay up‑to‑date. The WordPress core team continues to improve locking APIs. Monitor dev notes for updates like the ability to lock reusable blocks and assign canLockBlocks based on custom roles.

• Combine with revision control. Encourage clients to use the built‑in revision history to restore sections if they unintentionally modify a pattern.

• Provide training and documentation. Even the best technical solutions benefit from a short video or manual explaining how to edit content responsibly.

Conclusion: attract clients with unbreakable WordPress sites

Marketing teams love the ease of the block editor but dread the possibility of breaking a gorgeous design. By leveraging WordPress’s locking APIs, template locks and theme.json configuration, agencies can deliver “unbreakable” websites that empower clients to edit content without worry. The lock and templateLock attributes prevent accidental drags and deletions, while contentOnly editing hides complex controls and focuses clients on their copy and images. The canLockBlocks filter and block supports settings provide fine‑grained permission control so only trusted roles can unlock blocks. Combined with dynamic theme.json configuration and patterns, these tools create a curated editing experience that protects your layout, preserves your brand design, and lets clients focus on what they do best: publishing content.

With client‑proofing in place, agencies can confidently hand over FSE sites knowing that the underlying structure is safe. Offer a technical accessibility audit or a custom training session as a lead magnet to attract marketing teams seeking reliability and peace of mind.