Block Locking: Register the 'lock' attribute on the server

[Mamaduka]

What?

Resolves #40461.

PR fixes an error when locking server-side rendered blocks.

Why?

The block-renderer endpoint validates passed attributes, but the lock block attribute was registered on the client-side.

How?

Use register_block_type_args filter to register the lock attribute.

Testing Instructions

1. Open a Post or Page.
2. Insert the Latest Comments or any block that uses the ServerSideRender component.
3. Lock the block using block Options.
4. Confirm there's no "This block has encountered an error and cannot be previewed" error.

Screenshots or screencast

Before	After

[Mamaduka]

I'll create the WP core patch today or tomorrow 👍

[gziolo]

The lock functionality isn't technically a part of the block supports layer so I would appreciate some sanity check on the idea from @youknowriad, @andrewserong, and @ramonjd who helped with WP 6.0 Beta 1 backports in that area.

[Mamaduka]

@gziolo, the block locking UI can be controlled via block supports, but you're right attributes are registered for every block.

[gziolo]

@gziolo, the block locking UI can be controlled via block supports, but you're right attributes are registered for every block.

With the full context, it looks for me like a more legit use case then 👍🏻

[youknowriad]

I think we should include it by default in the "register" function like I said before, this is backend and frontend if needed as it's part of the "framework" and not an extension (which both hooks and block supports are).

So yeah, I think we should add it. I'd prefer it was baked in though but it's minor.

[gziolo]

I think we should include it by default in the "register" function like I said before, this is backend and frontend if needed as it's part of the "framework" and not an extension (which both hooks and block supports are).

I guess you are referring to this function call:
https://github.com/WordPress/wordpress-develop/blob/8ad5aec839679804a81f29252b1307869d3d6d01/src/wp-includes/class-wp-block-type.php#L348-L371

We could also simplify a lot of code by assuming that syle and className should be always set as well.

[Mamaduka]

I will update PR to use register_block_type_args and use :: set_props for core patch. We can move styles and className to use this new method as a follow-ups.

[Mamaduka]

@gziolo, updated registration method.

[gziolo]

Yes, I think it's a good way to handle this attribute 👍🏻

[gziolo]

I will update PR to use register_block_type_args and use :: set_props for core patch. We can move styles and className to use this new method as a follow-ups.

Yes, it's going to look different in WP core. styles and className is something that should be coordinated in WP 6.1 cycle with the ongoing work on the Style Engine.

[Mamaduka]

I don't think React Native test failure is related to this change, so I'll merge after the Performance test is green.