--- title: "How WordPress Block Locking Works" date: 2026-01-12 author: "Imtiaz Rayhan" featured_image: "https://wpblocksuite.com/wp-content/uploads/2026/08/featured-how-wordpress-block-locking-works.png" categories: - name: "Block Editor" url: "/blog/category/block-editor.md" --- # How WordPress Block Locking Works WordPress block locking can prevent a block from moving, being removed, or both. Template locking can also restrict insertion and changes inside a container. These controls protect layouts from accidental editing. Locks are editorial guardrails, not security boundaries. Authorised users may retain ways to unlock them. Code, permissions, and project workflows determine stronger control. Use the smallest lock matching the real risk. Prevent removal when deletion is dangerous. Prevent movement when order carries meaning. ## WordPress locking options compared ControlPreventsTypical scopeMovement lockReordering one blockIndividual blockRemoval lockDeleting one blockIndividual block`templateLock: insert`Insertion and removalContainer inner blocks`templateLock: all`Insertion, removal, and movementContainer inner blocks`contentOnly`Structural and design editingCurated container content Individual block locks and template locks can interact. Block-level values can override inherited template locking. Test the complete nested structure. ## How to lock a block through WordPress 1. Select the intended block. 2. Open the block toolbar’s options menu. 3. Choose the Lock action. 4. Enable movement locking, removal locking, or both. 5. Apply the selected controls. 6. Check the lock icon within List View. 7. Save and reopen the document. 8. Verify the blocked actions through the intended role. The [official block guide](https://wordpress.org/documentation/article/work-with-blocks/) documents these toolbar controls. Locked blocks display an icon in the toolbar and List View. ## Movement and removal locks are separate A movement lock keeps the block in its current order. Editors can still change its content or delete it unless another control prevents deletion. A removal lock prevents deletion. Editors can still move the block unless movement is locked. They can often edit content and styling too. Choose each option intentionally. A required disclaimer may need removal protection. A carefully ordered process may need movement protection as well. Locking both prevents two structural actions. It does not freeze the entire block. Content and design controls can remain available. ## Applying locks to nested blocks Container blocks can hold deeply nested structures. The locking interface can apply movement and removal settings to nested blocks. This accelerates protection for complex patterns. Review the result in List View. Mass locking can protect blocks that editors genuinely need to change. One convenient action can create broad friction. Unlock specific blocks when their purpose demands flexibility. Test inherited and explicit values. Nested exceptions should remain easy for maintainers to understand. ## How the lock attribute works WordPress stores individual movement and removal choices in a block’s `lock` attribute. The values use `move` and `remove` boolean properties. ```

Protected content

``` This markup prevents moving and removing that Paragraph block. It does not automatically prevent text editing. WordPress interprets the attributes within the editor. Developers and theme authors can include locks within registered patterns or templates. Building through the interface first reduces syntax mistakes. ## What is template locking? Template locking controls an InnerBlocks area inside a container or registered content template. It can restrict insertion, removal, and movement for the nested structure. The word “template” can mislead here. It can describe a nested block template, not only a Site Editor template. Groups and custom containers can participate. The [official block-template reference](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-templates/) documents `all`, `insert`, and `contentOnly`. It also explains inheritance and block-level priority. ## How templateLock all works The `all` value prevents inserting new inner blocks. It also prevents moving or removing existing inner blocks. Content and available settings may remain editable. This fits fixed compositions requiring stable order and membership. A profile card can preserve its image, name, role, and link positions. Do not apply it to an open editorial canvas. Writers then cannot add needed sections. Use fixed templates only where structure has a real contract. ## How templateLock insert works The `insert` value prevents adding or removing inner blocks. It still permits reordering existing blocks. Membership stays fixed while order remains flexible. This narrower control can suit sections with required components and variable sequence. Test whether movement can break meaning or design. Use `all` when order must remain fixed. Explain the allowed action to editors. A missing inserter can look like an error. Good patterns and documentation make constraints predictable. ## How lock inheritance works Nested InnerBlocks areas can inherit locking from their parent. Explicit child configuration can change some inherited behaviour. Individual block locks take priority over template locking. This supports deliberate exceptions within protected structures. One paragraph can remain removable while siblings stay fixed. Hidden exceptions can also confuse future maintainers. Inspect the entire tree after changes. Test every permitted and forbidden action. Do not infer behaviour from the parent attribute alone. ## Can users unlock WordPress blocks? Users with sufficient editing access can often unlock blocks through the same options menu. Default locking prevents accidents. It does not prevent determined authorised changes. Projects can restrict the locking interface through editor settings and permissions. Agencies may remove unlock capabilities for selected roles. Implement and test those restrictions carefully. An administrator can still change code, plugins, or database content. Block locks are not access-control security. Use WordPress roles and operational controls for authority. ## What block locking does not prevent - It does not necessarily prevent content editing. - It does not necessarily hide design controls. - It does not secure confidential information. - It does not prevent authorised code changes. - It does not replace user-role permissions. - It does not guarantee valid or accessible content. - It does not protect against broken plugin updates. Use [content-only editing](https://wpblocksuite.com/blog/content-only-editing-wordpress/) when the design interface needs stronger curation. Use roles when authority needs restriction. Use backups and review for recovery. ## Block locking versus content-only editing Ordinary locks target movement and removal. Content-only editing hides structural and design controls while exposing nested content. Their editor experiences differ substantially. Content-only mode also flattens visible content within List View. Container blocks become unavailable for normal selection. Additional inner blocks cannot be inserted. Choose ordinary locks for targeted guardrails. Choose content-only mode for curated patterns and client-safe content replacement. The next guide covers that workflow fully. ## Good block-locking use cases - Protect a required legal disclaimer from deletion. - Keep process steps in a meaningful order. - Protect header structure within a template. - Preserve required metadata blocks in a pattern. - Prevent deletion of a Post Content placeholder. - Keep a designed card’s required components. Each use protects a specific structural or content requirement. The lock should be explainable in one sentence. Otherwise, it may be unnecessary. ## Weak block-locking use cases - Locking every block without a risk assessment. - Preventing editors from fixing legitimate content problems. - Using locks instead of training and naming. - Treating locks as access-control security. - Hiding an overcomplicated block structure. - Protecting temporary decorative preferences permanently. Over-locking creates support tickets and workarounds. Editors may copy content elsewhere to regain control. That outcome weakens the intended [design system](https://wpblocksuite.com/blog/reusable-wordpress-design-system/). ## Accessibility and editorial usability Locks can preserve accessible structure. They can protect heading order, required labels, or keyboard-friendly components. They cannot guarantee correct replacement content. Locked controls need understandable feedback. Icons alone can confuse new editors. Training should explain unavailable movement, deletion, and insertion actions. Test keyboard editing through every intended role. Confirm that content remains reachable and clear. A protected layout should not create an unusable editor. ## Locking patterns and templates Theme authors can ship locks inside registered patterns and block templates. Inserted structures then begin with intended guardrails. Editors receive the constraints immediately. Ordinary pattern copies retain their inserted lock attributes. Updating the source pattern does not update old copies. Fixes may require a content audit. Template locks can govern post-type starting structures too. The content template defines initial blocks and allowed operations. Test new and existing posts separately. Do not lock placeholder content accidentally. Editors must replace examples and incomplete links. Guardrails should protect structure while exposing every required editorial field. ## What happens when locked blocks are copied? Copying block markup can carry lock attributes into the new document. A pasted block may therefore remain locked. Inspect List View after copying. Duplicating a locked block can behave differently based on allowed actions and editor context. Test the specific workflow. Do not assume duplication removes constraints. Exported patterns can also preserve locking configuration. That supports portability. It can spread unsuitable assumptions across sites with different user roles. Review imported locks before publishing. Confirm their reason still applies. Remove project-specific restrictions lacking value on the destination site. ## How plugins and themes affect locking Blocks can declare whether the locking interface appears. A custom block may hide lock controls. That setting affects UI availability, not saved markup alone. Plugins can filter editor settings and restrict locking authority. Themes can ship locked patterns. Several layers may therefore influence one editor experience. Deactivate candidate providers on staging when controls disappear unexpectedly. Inspect stored attributes before editing them. The visible symptom may have several owners. ## Client handoff for locked layouts Show clients the lock icon and its intended meaning. Demonstrate content that remains editable. Then demonstrate one blocked structural action. Provide a clear request path for legitimate layout changes. Locks should reduce mistakes, not create secret dependence. Name the role authorised to review exceptions. Keep an unlocked master on staging when appropriate. Use it for redesigns and testing. Deploy reviewed structural changes through the normal process. Review support questions after launch. Repeated unlock requests reveal missing flexibility or unclear training. Adjust the design system, not only documentation. Schedule a lock audit after major redesigns. Compare every constraint with current responsibilities. Remove obsolete locks, retest permitted actions, and update the handoff guide. Small audits prevent permanent friction. They also reveal unprotected structures introduced after the original handoff. Record every change and responsible reviewer. Future maintainers need reasons, not unexplained boolean values buried inside block markup. Keep that evidence permanently available. ## A block-locking governance checklist - Name the exact risk each lock prevents. - Choose movement, removal, insertion, or complete structure. - Document any child exceptions. - Assign authority for unlocking shared structures. - Test every actual publishing role. - Keep a clean unlocked source when appropriate. - Review locks after workflow or design changes. - Remove constraints lacking current value. Governance prevents locks from becoming unexplained archaeology. Every constraint needs a current owner. Old guardrails can obstruct new legitimate work. ## How to troubleshoot unexpected locking 1. Select the block through List View. 2. Check its individual lock indicator. 3. Inspect the nearest container’s template lock. 4. Check inherited parent containers. 5. Test the same content as an administrator. 6. Review editor permission filters and plugins. 7. Inspect block markup on staging. 8. Change one lock value per test. 9. Restore the intended constraint after diagnosis. Do not remove every lock to solve one symptom. That destroys useful safeguards. Locate the controlling layer and adjust the smallest value. ## A safe implementation workflow 1. Build the complete unlocked structure first. 2. Test its content and responsive behaviour. 3. List every dangerous editor action. 4. Apply the narrowest matching locks. 5. Document intentional unlocked exceptions. 6. Reopen and test the saved structure. 7. Test author, editor, and administrator roles. 8. Check copying, patterns, and template contexts. 9. Train users on visible lock feedback. 10. Review after real publishing use. Begin on staging. Locking failures rarely damage the frontend directly. They can still block urgent publishing or enable accidental structural loss. ## Frequently asked questions What does locking a WordPress block do? It can prevent movement, removal, or both. Other content and design editing may remain available. Can a locked WordPress block still be edited? Usually, yes. Movement and removal locks do not freeze content. Content-only mode provides broader interface curation. Can WordPress users unlock blocks? Users with suitable authority often can. Projects can restrict locking controls through editor settings and permissions. What is templateLock in WordPress? It controls insertion, removal, movement, or content-only editing within a nested block template or container. Does block locking secure WordPress content? No. It prevents editor actions and accidents. Roles, permissions, authentication, and operational controls provide security boundaries. ## The verdict Verdict **Use block locks:** prevent specific accidental movement, removal, or insertion. **Do not claim:** security or complete editing prevention. **Best rule:** apply the narrowest guardrail with a named reason. Thoughtful locks let teams use specialised blocks without damaging approved layouts. WP Block Suite works inside WordPress’s native editor. Try every free plugin first. Then [compare the $299 lifetime suite](https://wpblocksuite.com/#pricing) for several Pro needs.