Block API: Preserve unknown, respect null in server attributes preparation

[aduth]

This pull request seeks to revise the behavior of the server-side BlockType::prepare_attributes_for_render with regards to validation:

• Skip validation where there is no attribute definition, but keep the attribute value
  • Previously, the attribute would be omitted from the attributes passed to render_callback.
  • Notably, this resolves an issue where render_callback cannot receive a block's align and customClassName attribute values, since these are defined as a client-side filter (related).
• Validate null as a proper value in its own right
  • Previously, a client implementation of a block could track {"attribute":null} as an explicitly empty value, and the server would wrongly initiate defaulting behavior.
  • The new behavior will now only populate a default value if the attribute is not defined at all, including when unset in its being invalid per the attribute schema.

This is partly intended to serve for consistency:

• The prior implementation already had a shortcutting condition to return the attributes verbatim if there were no attributes defined. An unknown attribute would be kept, but only if the block type had no attributes.
• Omitting the invalid attribute type when no default exists aligns with the client implementation
  • e.g. wp.blocks.parse( '<!-- wp:latest-posts {"className":2} /-->')[ 0 ].attributes.className === undefined

One potential downside is a newly introduced inconsistency in that the client still does not respect unknown attributes. This may be simple enough to add support if desired.

Testing instructions:

Ensure PHP tests pass:

npm run test-php phpunit/class-block-type-test.php 

Optionally, you may try registering server-side a render_callback for a block which supports alignment or custom class name in the client, ensuring that the value is passed to the render_callback.

Possible future tasks:

• supports attributes should be defined by the server. This is likely to be blocked by broader conversation of Block API: Server-side awareness of block types #2751.
• Respect unknown attributes in the client parse.

cc @mtias @azaozz

[aduth]

Funny enough, I caught myself staring at @azaozz 's #11973 wondering: How does render_callback work at all? If all the attributes are defined in the client and thus unknown to the server, and without this pull request we omit unknown attributes, shouldn't then render_callback receive no attributes at all?

Well, in fact, this ties back to the following note of the original comment:

The prior implementation already had a shortcutting condition to return the attributes verbatim if there were no attributes defined. An unknown attribute would be kept, but only if the block type had no attributes.

So a render_callback would receive the attributes, but only because it doesn't define attributes at all. This feels like a very fragile and inconsistent behavior, since we're very much not omitting unknown attributes as the PHPDoc would have you believe, at least not consistently.

In master, you'd find the following, which appears nonsensical to me:

( new WP_Block_Type( 'core/dummy', [] ) )->prepare_blocks_for_attributes( [ 'exists' => 'keep' ] );
// [ 'exists' => 'keep' ]

( new WP_Block_Type( 'core/dummy', [ 'attributes' => [] ] ) )->prepare_blocks_for_attributes( [ 'exists' => 'keep' ] );
// []

[chrisvanpatten]

Notably, this resolves an issue where render_callback cannot receive a block's align and customClassName attribute values, since these are defined as a client-side filter (related).

This is huge. Right now you have to (annoyingly) register align and className as attributes on your server-rendered blocks manually, which is obviously inconsistent from the JS representation.

It would be nice if these (and any other "protected" properties) could be validated on the server as well, but that's a discussion for the future.

This feels like a very fragile and inconsistent behavior, since we're very much not omitting unknown attributes as the PHPDoc would have you believe, at least not consistently.

You can say that again!

Figuring out how server-registered attributes worked was a huge time sink for me when we first started building blocks. This seems like a huge step forward into making this behaviour more consistent and easily understandable.

[mtias]

What's this change about?

[noisysocks]

It's indicating that we expect that 'wrongType' will not appear in $prepared_attributes.

[mtias]

I agree with this update and the reasoning.

[noisysocks]

👍 this logic makes a lot more sense to me.

I tested this by registering a render_callback on paragraph blocks and checking that it renders className and align properly.

register_block_type(
	'core/paragraph',
	array(
		'render_callback' => function( $attributes ) {
			return '<p>' . json_encode( $attributes ) . '</p>';
		},
	)
);