-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Description
Background
The block editor has had template locking support since very early on. Template locking allowed to designate the original content templates (the ones you could use on custom post types) to prevent insertion or moving blocks. Inner blocks also has supported a templateLock
attribute. This was extended in #26128 to be used directly in columns and group as attributes, not just as internal props of <InnerBlocks>
.
Limitations
While powerful on its own, template locking has not offered too much granular control nor has the UI adapted to communicate different locking states.
With block themes, the necessity for locking down elements of the page is more pronounced. For example, it might be desirable that by default the "post-content" block of a single
template is locked so that it cannot be removed. This extends to many other blocks and template parts in all sorts of ways.
Proposal
Let's establish a new block-level API representing lock
status. This is in addition to templateLock
. The lock attribute would allow control over what UI interactions are present.
Lock status needs to allow a few state options. A locked block could imply any or all of these:
- Cannot be removed.
- Cannot be moved.
- Cannot be edited.
- Worthwhile exploring (though complex) how specific attributes could be locked instead of the entire block. It might be better to keep this separate as a
lockAttribute
prop down the line.
- Worthwhile exploring (though complex) how specific attributes could be locked instead of the entire block. It might be better to keep this separate as a
While templateLock
separately governs the inner blocks state (blocks cannot be added, etc).
This lock status can be toggled by the user. A user can choose to lock down a block so that they don't accidentally remove it, like on most design applications.
This could be represented in the UI as follows:
Note: block locking has nothing to do with capabilities for editing and it only governs interface controls.
If a block lock state is editable by the user, clicking on the "lock" icon should bring about a modal with the lock configuration. If only "remove" is locked, the movers and drag handle should remain and the lock indication should go somewhere else (in the ellipsis menu, for example.)
Lock status should be reflected in more places than just the Toolbar:
- List View.
- Block Inspector.