Block Locking: prevent override of parent's Template Lock#42825
Block Locking: prevent override of parent's Template Lock#42825dougwollison wants to merge 1 commit intoWordPress:trunkfrom
Conversation
When testing if a block can be locked, check the parent's template lock; if the parent has template locking in place, the user should not be able to override that.
Mamaduka
added
the
[Feature] Block Locking
Mamaduka
left a comment
Mamaduka
left a comment
There was a problem hiding this comment.
Thanks for contributing, @dougwollison, and sorry for the late reply.
The current UI matches the API design introduced in WordPress 5.9. If we apply the proposed change interface will be inconsistent with the API.
I recommend curating the Block locking experience with existing tools.
|
Okay but how do we address the issue I described with post-type level templateLock virtually bricking the editor? If I have a post type with a fixed content template, but the user overrides the lock on each block and removes them, they can't add anything to the editor. |
|
@dougwollison, you can also disable the block lock controls for the post type with Example: add_filter( 'block_editor_settings_all', function( $settings, $context ) {
if ( ! $context->post ) {
return $settings;
}
$post_type_object = get_post_type_object( $context->post->post_type );
if ( $post_type_object->template_lock ) {
$settings['canLockBlocks'] = current_user_can( 'edit_theme_options' );
}
return $settings;
}, 10, 2 ); |
|
@Mamaduka yes but I have use cases where we want to allow block locking on stuff within child blocks of the template. |
|
@dougwollison, I agree there is definitely room for improvement for more granular controls. Maybe instead of using @mtias, @jorgefilipecosta, what do you think? |
2 participants
What?
Prevent users from overriding the locks on a block imposed by the parent via
templateLock.Why?
Currently, if a post type or parent block uses
templateLock, users can override those movement/removal restrictions on individual inner blocks. I feel this is counter-intuitive; if I intend a block's content to be fixed, the user should not be able to override it.This can actually render the block or entire block editor unusable. For example, say I have a post type with a template set to a single main content block, and set the template_lock to "insert"; the intention is that the main block cannot be removed and nothing can be added above/below it. Currently, the user would be able to override that lock, delete the block, and be left with now way to insert content, because the insert prevention is still in place.
The only current workarounds are to either disable lock support on the applicable blocks, or set the canLockBlocks setting to false. Neither of which are ideal as there may be instances within that same page where locking is permitted on the blocks involved.
How?
While not comprehensive (as lock overrides can still be set via other means), this PR adds a check to the
useBlockLockhook to check if there is a parent lock in place when calculating thecanLockflag, rather than solely on the lock-ability of the block's type. I can see some edge cases where you'd want to programatically allow removing blocks from an otherwise fixed template.Testing Instructions
template_lockset to "insert" or "all"lock.removeoverride ({"lock":{"remove":false}})