Block Editor: Add layout lock option to lock modal - #78608
Conversation
|
Size Change: +122 B (0%) Total Size: 8.04 MB 📦 View Changed
ℹ️ View Unchanged
|
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
There was a problem hiding this comment.
Pull request overview
Adds a new “Lock layout” option to the Block Lock modal for blocks exposing a templateLock attribute, mapping it to templateLock: 'contentOnly' and ensuring existing lock affordances recognize this state.
Changes:
- Extend the Block Lock modal to include a “Lock layout” checkbox and update submission logic to write
templateLock: 'contentOnly'. - Update
isLockedBlockto treattemplateLock: 'contentOnly'on the block as a locked state. - Add unit coverage for
isLockedBlockwhentemplateLockis set tocontentOnly.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| packages/block-editor/src/components/block-lock/modal.js | Adds UI + state handling for “Lock layout” and updates how template locking is applied on submit. |
| packages/block-editor/src/store/private-selectors.js | Extends isLockedBlock to consider block-level templateLock: 'contentOnly'. |
| packages/block-editor/src/store/test/private-selectors.js | Adds a unit test ensuring isLockedBlock returns true for templateLock: 'contentOnly'. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Flaky tests detected in b0b045a. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/26366543389
|
|
Nice PR. Noting that I also have #79158 which tackles this same issue. I will say that the reason I went in a different direciton and created an explicit button, so as to maintain the explicit act of creating a pattern separate. This PR just creates the pattern immediately, unnamed it appears:
This is certainly a more elegant one step experience. The question is whether it's more confusing in that sense. |
|
Not sure if @richtabor already pushed that PR, but I liked the sub-menu variation with simplified options (#78612). I think the first step, which is self-contained, will be to refactor the options dropdown to use a modern menu component. |
|
Not bad. I like the grand vision for this, which appears to be making pattern editing even more ephemeral. I guess that may answer my question around how this affects pattern creation; it doesn't, it just locks the layout, literally. Pattern creation is a separate thing, and you choose that from the separate menu item. I like that quite a bit. Rich let me know if I got this instinct right, and how I can best support this work. |

What?
Adds a layout lock option to the block lock modal for blocks that expose a
templateLockattribute. Selecting the option storestemplateLock: 'contentOnly', while existing movement/removal lock options continue to map tolockand non-content-only template lock values.Why?
Blocks can already preserve their inner layout with
contentOnlytemplate locking, but the lock modal did not expose that state alongside the other lock controls. This makes the layout lock visible and editable from the same UI.Visual
How?
templateLock === 'contentOnly'attribute.all/insertbehavior.templateLock: 'contentOnly'as a locked state so existing lock toolbar/menu affordances remain available.isLockedBlockwithtemplateLock: 'contentOnly'.Testing Instructions
npm run test:unit packages/block-editor/src/store/test/private-selectors.js -- --runInBand.npm run lint:js -- packages/block-editor/src/components/block-lock/modal.js packages/block-editor/src/store/private-selectors.js packages/block-editor/src/store/test/private-selectors.js.npm run wp-env status,npm run wp-env startif needed, andnpm start.Lock layoutappears, can be checked and applied, and is still checked when reopening the modal.Lock layout, apply, and confirm it clears.Lock movement,Lock removal, andApply to all blocks inside; then check and uncheckLock layoutbefore applying. ConfirmApply to all blocks insideis preserved when layout lock is unchecked.Testing
npm run test:unit packages/block-editor/src/store/test/private-selectors.js -- --runInBandnpm run lint:js -- packages/block-editor/src/components/block-lock/modal.js packages/block-editor/src/store/private-selectors.js packages/block-editor/src/store/test/private-selectors.js