On Locking and TemplateLocking

[mtias]

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.

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.

[jameskoster]

Making templates contextually un-removable and/or un-editable (attributes) will be crucial in establishing an intuitive experience as one moves between editing content / template 👍

Some more background on that (and rough concepts) can be found in #27848.

Cannot be moved.

This one feels especially tricky because the position of a block is always relative to those around it. Even if a block is position-locked to the top of the tree, it can still effectively be "moved" by re-positioning the blocks around it. Is this perhaps something that can only be applied to container blocks, and cascades down to all the innerblocks? IE everything is position-locked, or nothing is.

[mtias]

TemplateLocking already handles the disabling of moving for all children. I don't think it's much of an issue that you can move something by moving the things around it, that will always be the case. This is more about the peace of mind and reduced overhead of controls that you don't need.

[paaljoachim]

I really like the iterations you made Matias!
Simple and straight forward.

I am wondering if it should contain a drop down of toggle options instead of a modal.
As one clicks the lock/unlock icon. A drop down is seen to where the administrator toggles various options on and off depending on what should be locked. Such as various levels of importance. Such as editing the block, moving, removing etc.