Client editing should not require clients to understand how a page is assembled. When a carefully prepared layout contains columns, containers, spacing and content areas, an accidental move or deletion can change the intended structure. Agencies, freelancers and site owners therefore need a way to let clients update approved content without giving them unrestricted control over the layout.
WordPress offers two related approaches in the Block Editor. WordPress block locking provides targeted protection for selected blocks, such as preventing movement or removal. Content-only editing is broader: it creates a pattern- or template-level editing experience in which clients can work with content while structural design controls remain hidden or unavailable. These mechanisms control the editor experience and layout integrity. They are not a complete security boundary, a replacement for user permissions, or a substitute for backups and change-management procedures.
Why agencies need controlled client editing
A client may need to replace text, update an image or revise a content area regularly. At the same time, the agency may need the surrounding layout to remain consistent. Without a controlled workflow, a user who can edit content may also move a block, remove a required element or expose design controls that were not part of the handoff.
Block locking addresses specific editing actions. A block can be protected against movement, removal or both. This is useful when only selected elements need protection and the rest of the editor should remain flexible. Content-only editing addresses a wider scenario: the client should work with content inside a prepared structure while non-content blocks and design-focused controls are kept out of the normal editing experience.
The level of protection depends on how the layout is built and whether users retain permission to unlock blocks. Locked layouts should not be described as protection against malicious users or unauthorized access. Before applying either approach to a production pattern or template, maintain a current backup or revision path so changes can be reversed.
How to lock individual WordPress blocks
To lock a selected block in the WordPress Block Editor, first select the block you want to protect. Open the block’s More options menu and choose Lock. The lock settings allow you to enable Lock movement, Lock removal, or both. Apply the setting after choosing the protection required for that block.
Lock movement prevents the selected block from being moved within the layout. Lock removal prevents it from being removed through the normal editing workflow. These are separate controls, so the choice should reflect the intended client experience. For example, a block may need to remain in its position while still allowing other permitted editing actions, or it may need protection against both movement and deletion.
When at least one lock option remains enabled, a lock icon appears in the block toolbar and in List View. This gives editors a visible indication that the block has a protection setting. It also helps during handoff because the client can distinguish a protected element from an ordinary block without having to infer its status from the layout.
For a multi-block section, locking can be applied to blocks nested inside a containing block by enabling the option to apply the lock to all blocks inside. This is useful when a section includes several related elements that should remain together. However, the documented interface does not provide a general mass-lock operation beyond the nested-block option described there. Agencies should therefore design the section deliberately and confirm which blocks are included.
Before changing a production layout, test the result with the actual client role and the installed blocks. A current backup or revision path is also important, particularly when the locked structure is used by a template or reusable pattern.
Recognising a locked block
The lock icon is the main status indicator. Check the block toolbar when the block is selected, and use List View when reviewing the structure of a larger section. The icon remains visible while at least one lock option is enabled, helping editors identify protected blocks during routine content updates.
What content-only editing does
Content-only editing is intended for patterns or templates that need a broader protected editing experience. Instead of exposing the full set of design controls for every element, it hides design-focused tools and exposes the content blocks that users are expected to edit. The result is a simplified way to update content inside a prepared structure.
In this mode, non-content child blocks such as containers, spacers and columns are hidden from List View. They cannot be selected on the canvas or edited in the usual way. Additional child blocks cannot be inserted inside the protected container. These behaviors preserve the structure while allowing the user to work with the content areas that the pattern or template makes available.
This makes content-only editing different from simply locking one heading, image or group. The mode applies to a broader container and automatically protects the layout from movement and removal within that structure. It is intended for a client who should edit content without accessing the structural design controls used to create the layout.
Content-only editing uses the templateLock value contentOnly. According to the documented behavior, it is managed at code level rather than through a dedicated user-interface control for content locking. It should therefore not be presented as a universally available point-and-click setting. The actual theme, blocks and site configuration should be checked before handoff, especially when third-party blocks or page-building tools are involved.
Block locking vs content-only editing
The practical difference is scope. Individual WordPress block locking selectively protects existing blocks. Content-only editing establishes a broader content-entry mode around a protected pattern or template. The first approach is useful when only particular elements must stay in place or remain present. The second is useful when the client should work with content while the surrounding structure and design controls stay out of the editing workflow.
| Control | Practical purpose | Editing experience |
|---|---|---|
| Individual block locking | Protect selected blocks against movement, removal or both | Targeted protection within an otherwise editable layout |
| Content-only editing | Protect a broader pattern- or template-level structure | Content blocks remain available while structural blocks and design tools are hidden or unavailable |
These approaches can also be combined. Individual block settings may be applied inside templates, and block-level locking takes priority over templateLock settings. Template locking also includes levels such as contentOnly, all and insert, but the appropriate choice depends on the intended workflow rather than on a universal rule.
Choose targeted locking when the client needs normal editing freedom except for a few protected elements. Choose content-only editing when the handoff should expose only approved content areas inside a controlled structure. In both cases, confirm whether users with appropriate permissions can unlock blocks. If locking permissions are not separately controlled, a locked layout should not be described as permanently immutable.
Protecting reusable layouts with patterns and templates
Patterns and templates can provide the foundation for repeatable agency workflows. An agency can prepare a structure, decide which areas are intended for client editing, and then apply the protection level that matches the layout. Individual locking is appropriate when selected elements need protection. Content-only editing is appropriate when a complete content-entry experience is required within a pattern or template.
The choice between synced and unsynced patterns is equally important. A synced pattern keeps its content connected across uses: changes to the pattern appear wherever it is used. This is suitable when the same shared content should remain connected in multiple locations.
An unsynced pattern creates an independently editable copy when inserted. This is suitable for a reusable layout whose content should vary by placement. The layout can be reused, while each inserted copy can be edited independently. Before choosing, decide whether future changes should be shared everywhere or limited to one use.
Templates and patterns should not be treated as permanently immutable when users retain relevant permissions to unlock blocks. The protection level depends on the selected settings, the way the layout is constructed and the users who can manage locking. A clear handoff should explain which parts are reusable structure, which parts are client content and whether inserted copies are connected or independent.
Choosing synced or unsynced patterns
Use a synced pattern when changes should appear wherever the pattern is used. Use an unsynced pattern when each inserted copy should be edited independently. This decision should be made before handoff because synchronization affects how later content changes behave across the site.
Permissions, testing and handoff checklist
Protection should be validated as an editing workflow, not assumed from the presence of a lock setting. The documented behavior depends on user permissions and editor configuration. Users with editing access may be able to unlock blocks by default in relevant pattern or template scenarios, while locking permissions can be further restricted through editor settings. Exact behavior should be tested on the target configuration.
Before handing over a protected layout, review the following points:
- Test the actual client role. Confirm what the intended user can edit, move, remove, insert, lock and unlock.
- Use the real theme and installed blocks. Do not assume that behavior documented for the Block Editor is automatically identical for every third-party block, theme or page-building plugin.
- Check the complete structure. Review List View and confirm that the blocks intended to remain protected are covered by the selected settings.
- Maintain a backup or revision path. Keep a way to reverse changes before applying locking or content-only editing to production templates and patterns.
- Document the editing scope. State which text, images or other content areas the client may edit and which design controls are intentionally unavailable.
- Explain synchronization. Make clear whether a pattern is synced and changes wherever it is used, or unsynced and independently editable after insertion.
- Review unlock permissions. Do not describe the layout as permanently unchangeable unless the relevant permissions and configuration have been separately controlled and tested.
This process prevents a common handoff problem: the client sees a restricted editor but does not know whether a missing control is intentional or whether something is broken. A short explanation of the permitted workflow can reduce confusion and make support requests more precise.
It is also important to keep the purpose of these mechanisms clear. Block locking and content-only editing protect layout consistency and shape the editor experience. They do not replace user roles, access control, backups or broader change-management procedures. If the site uses third-party blocks, test the complete editing path rather than relying only on the behavior of the core documentation.
WordPress block locking is suited to targeted protection against movement and removal, while content-only editing provides a broader, code-configured content-entry mode for patterns and templates. Agencies can combine these controls with synced or unsynced patterns according to whether content should remain shared or vary by placement. Before handoff, match the mechanism to the client workflow, test the actual role and configuration, confirm unlock behavior, and preserve a way to reverse production changes. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.