The WordPress Block Editor makes it easy to assemble a page from independent blocks. That flexibility is useful until someone accidentally deletes a call-to-action, moves a column out of alignment or changes a shared layout that other pages depend on.
Block locking gives site owners and theme developers a way to protect selected editor actions. The important detail is that “locked” does not always mean “nothing can be edited”. You can protect structure while leaving text or media editable, which is often a better fit for a team site.
Summary
- Use block locking when the structure of a section must remain stable across edits.
- Decide whether to prevent movement, removal or broader design changes; do not lock everything by default.
- Test who can unlock blocks, because the normal editor experience may still allow users with editing access to override locks.
What block locking controls
The WordPress Block Locking API can restrict actions on specific blocks. The documented controls include preventing a block from being moved or removed. The Navigation and Reusable blocks also have an option related to editing their contents. At a higher level, template locking can control insertion and editing inside a container.
This gives you several useful patterns:
- A header section whose inner blocks cannot be moved or deleted.
- A testimonial pattern whose wording can change but whose spacing and button placement should remain consistent.
- A landing-page section where writers can edit text and media without seeing every design control.
WordPress introduced the Block Locking API in 6.1. The current documentation also warns that users with editing access can, by default, unlock blocks in the editor. That means a lock is an editing guardrail, not automatically a permission boundary.
Choose the smallest useful lock
Start with the failure you are trying to prevent. If the problem is accidental deletion, lock removal. If a section must stay in sequence, lock movement too. If the goal is a controlled content-only pattern, consider templateLock: "contentOnly" at the container level.
Avoid locking a whole page simply because one component is fragile. A writer who cannot fix a typo, replace an image or add an approved section will work around the system, often by asking an administrator to make routine changes.
A practical setup sequence
1. Identify the repeatable section
Choose a header, event card, pricing section or other pattern that appears in more than one place. Write down which parts are structural and which parts are content.
2. Test the editor UI first
Create a copy in a staging site or a test post. Use the block Options menu to apply a lock and try the normal actions as an editor. Confirm that the protection matches the desired behavior before committing code to a theme or custom plugin.
3. Lock only the risky actions
For a block-level decision, move: true prevents movement and remove: true prevents deletion in the block markup. A simplified example looks like this:
<!-- wp:paragraph {"lock":{"move":true,"remove":true}} -->
<p>Approved introductory copy</p>
<!-- /wp:paragraph -->
The exact markup belongs in the pattern, template or registered block where the section is defined. Keep a backup and test the rendered page after changing it.
4. Consider content-only editing
For a pattern that should preserve design while allowing approved content edits, the documentation describes templateLock: "contentOnly" on a container such as a Group, Cover or Columns block. This approach can hide structural child blocks from the ordinary List View and keep design settings out of the editor’s way.
Content-only editing is a design decision, not a universal security setting. Confirm that editors can still replace the media, update text and understand which fields are intentionally available.
5. Decide who can unlock
The Block Editor documentation describes the canLockBlocks editor setting, which can be changed with the block_editor_settings_all filter. A site may choose to let only users with a design-related capability lock or unlock blocks. If non-administrators can access the Code Editor, the site also needs to consider whether they can remove the lock attribute from the markup.
Do not paste permission code into production without testing the affected post types, roles and Site Editor context. Put the rule in a small custom plugin or a version-controlled theme component so another administrator can find it later.
6. Test the complete workflow
Create a checklist for the people who will use the pattern:
- Insert the pattern into a test page.
- Edit the allowed text and media.
- Try to move and remove protected blocks.
- Preview and publish a test revision.
- Check the front end on mobile and desktop.
- Test an editor role and a design administrator role.
- Confirm that an update to the theme or plugin does not silently remove the protection.
When not to use it
Do not use locking to compensate for a confusing content model. If every page needs a different structure, a reusable pattern may be the wrong abstraction. Do not lock blocks that editors routinely need to reorder. Do not use a lock as a substitute for backups, revisions or role design.
Locking can also add friction during a redesign. Before changing a pattern or template, document which pages use it and decide how existing content will be migrated. A lock that prevents mistakes today can make an unplanned migration harder tomorrow.
Why it matters
The value is consistency without taking every editorial task away from the content team. A carefully designed lock reduces accidental layout damage, makes reusable patterns more trustworthy and gives developers a concrete place to encode the boundaries of a design.
My Take
I treat block locking like a seat belt: useful for common mistakes, but not a replacement for a good road. Start with one fragile section, lock one or two risky actions and observe the editors’ experience. If the result requires constant administrator intervention, the pattern is too rigid or the content model needs work.
Bottom Line
WordPress block locking is most effective when it protects structure while preserving the content changes people are hired to make. Define the failure, choose the narrowest lock, control unlock permissions deliberately and test the workflow with real roles before rolling it out.