When locking a container block, offer option to lock all blocks within

[annezazu]

What problem does this address?

Currently, when locking blocks, the locking only applies to the block in question. However, in some cases, like a Group block, you might want to lock all blocks within it too. The only way to do this is to lock each block individually. This came up during the 6.0 walkthrough.

What is your proposed solution?

Provide a way to cascade locking properties down to the blocks within a container block. This would be slightly different from locking a reusable block, in that you can still edit the contents, you just can't move/delete the items inside. Perhaps one approach would be to offer a toggle inside the locking modal saying: "apply to all blocks inside".

cc @Mamaduka @critterverse

[Mamaduka]

It is already doable using the templateLock attribute on container blocks, and then you can use block lock for more granular control.

More details can be found in the dev note - https://make.wordpress.org/core/2022/01/08/locking-blocks-in-wordpress-5-9/#working-alongside-templatelock.

Edit: I watched the "Product Walk-Through" video, so now I've more context 😄 My question now is if we want to use templateLock or directly apply the lock attribute to each inner block.

[critterverse]

I think the simplest option from a UX point of view might be to directly apply the lock attribute to each inner block so that the lock icon is visible in the inner block toolbars, but make it so that you can't access the modal from the inner blocks when the option is applied on the container.

The UI could look like this, with an extra toggle at the bottom of the modal to "apply to inner blocks:"

It might make sense to hide the toggle when no options are selected. Also the “apply to inner blocks” option isn't really applicable when “restrict editing” is selected for the Reusable block (as being explored in #39950) so maybe the toggle could be hidden if that's the only option selected as well 🤔

[paaljoachim]

It is a good idea with a toggle to give the option to hide the inner blocks.
There is a but....
What happens if the user goes to one of the inner blocks and clicks the lock to make it do something different or have it unlocked compared to other blocks.... Hmmm...

[annezazu]

To ground this work in some great user insights, here's some feedback from the thirteenth call for testing for the FSE Outreach program that touches on this exact scenario:

With part 14, I had expected that after locking the group block at the header, the cover block contained in it (for example) could also not be moved. But that was possible without any problems.
In my opinion, another option would make sense here:
Lock all blocks contained in the block.
If a group block contains several other blocks, it would be very time-consuming to lock all of them.

When I selected the three dots menu on the overall menu No Results > Select “Lock” > Check “Prevent Removal”, I expected the “Prevent Removal” to be applied to all the child blocks. (I know it’s something in the works, I’m still reporting for feed back)

[paaljoachim]

I agree. This means if one locks a parent container that everything inside the container should automatically also become locked.

[jameskoster]

This one is tricky! In general I agree that locking a container should also lock the children by default. But this raises a couple of questions:

1. Do the child blocks inherit the parents specific lock status? IE if the parent is only move-locked, can the children be edited and deleted, but not moved as well? I think it's probably a 'yes', but the UI may need to communicate that somehow.
2. Can a child block override its parents lock status? IE if the parent totally locked and I select a child, would clicking the lock icon enable me to unlock just the child?
   1. Should it even be possible to select a child if the parent is totally locked?

---

Side note: We might need a visual treatment in List View to communicate child lock status as well, Figma uses a dot aligned with the parent lock icon, which might work here?