useBlockLock: Always check inherited 'templateLock' status#40263
Conversation
|
@critterverse, I think we originally wanted to hide lock status from the toolbar for this case. But this would be the correct visual representation of the block lock status. @talldan, unfortunately, Widget Areas will display the lock icon in the sidebar. I'm not sure if we can fix this without adding a special case to the check. |
|
Size Change: -28 B (0%) Total Size: 1.22 MB
ℹ️ View Unchanged
|
b538766 to
ca76abd
Compare
|
Do we need to backport this bug fix for WordPress 6.0 release? I like how this hook gets simpler with the changes proposed 👍 |
Interesting. Maybe that's ok. What do you think @critterverse? It might be another thing to add to the discussion at #33254. |
There was a problem hiding this comment.
Thanks @Mamaduka. This fixes things for me.
Do we need to backport this bug fix for WordPress 6.0 release?
I think it'll need to be in the current Gutenberg release candidate because of the change to the function signature (and implicit behaviour of the function). So I guess that'll mean it ends up in 6.0.
Actually, I don't think this is a public API (yet), so ignore what I just said 😄 .
I think it's ok to backport at a later date.
|
This was cherry-picked to |

What?
PR updates
useBlockLockto always check the parent's inheritedtemplateLockstatus.Props, @talldan, for discovering the issue.
Why?
The
templateLockprovides default lock status on post type or block level. Without this check, blocks can be incorrectly represented as locked or unlocked.How?
Removed
checkParentargument.Testing Instructions
Exampe Post Type
Screenshots or screencast