Pass the block name as a parameter to the dynamic block render callback

[johnbillion]

Description

See #4671. Implements the $name parameter for dynamic block callback functions.

How Has This Been Tested?

• Testing via registering a dynamic block callback.
• Unit tests have been updated to test the parameter is correctly passed.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code has proper inline documentation.

[aduth]

Noting that #4591 removes the $content argument from render_callback, which would conflict with changes proposed here.

Also seems like a strange requirement if the block name is known at the time of assigning a render callback. Admittedly to make this generic, the most obvious solution to me would require support for PHP closures (5.3+).

<?php

function my_plugin_generic_block_render( $block_name, $attributes ) {
	// ...
}

$block_names = [
	'my-plugin/foo',
	'my-plugin/bar',
	'my-plugin/qux',
];

foreach ( $block_names as $block_name ) {
	register_block_type( $block_name, [
		// ...

		'render_callback' => function() use ( $block_name ) {
			call_user_func_array(
				'my_plugin_generic_block_render',
				array_merge( [ $block_name ], func_get_args() )
			);
		}
	] );
}

(Or some equivalent pattern for function partial application)

[aduth]

Or alternatively, if we expect to need to know information about the block in the render callback, maybe it's enough to pass the entirety of the instance of the block to the render callback.

[aduth]

Per #4671, it's hard to provide judgment here without real-world use-cases, only "it might be useful if..."s

[johnbillion]

the most obvious solution to me would require support for PHP closures

Yeah that's exactly how we're doing it at the moment.

[johnbillion]

maybe it's enough to pass the entirety of the instance of the block to the render callback

That could be an option too.