`get_block_wrapper_attributes` generates PHP notices.

[jmichaelward]

To replicate this issue:

1. Set both WP_DEBUG and WP_DEBUG_LOG in wp-config.php to true so that errors will be logged to wp-content/debug.log.
2. Using WP-CLI, run wp shell.
3. Call get_block_wrapper_attributes(); in the terminal.
4. Note the errors and call stack output in wp-content/debug.log. It will look something like this:

[18-Apr-2022 16:05:27 UTC] PHP Notice: Trying to access array offset on value of type null in wp-includes/class-wp-block-supports.php on line 94
[18-Apr-2022 16:05:27 UTC] PHP Notice: Trying to access array offset on value of type null in wp-includes/class-wp-block-supports.php on line 96

get_block_wrapper_attributes() makes a singleton call to retrieve the WP_Block_Supports object, which in turn calls apply_block_supports on that object. The apply_block_supports method presumes that there is an editor block already assigned to the object, and attempts to retrieve the block type by using the blockName set on in the array of the $block_to_render property. Since the default value on the WP_Block_Supports object is null, this generates the error.

It seems that the easiest solution here is to return an empty array from apply_block_supports if $block_to_render is not set. Since get_block_wrapper_attributes is a public function that does not accept a block, it can be called outside of a sequence where WP_Block_Supports might already have set properties on the object.

[costdev]

Hi @jmichaelward, thanks for opening this ticket!

I can confirm that this issue occurs going back to WordPress 5.6 when get_block_wrapper_attributes() was introduced.

Adding dev-feedback to get other opinions on the path forward.

• Update WP_Block_Supports::$block_to_render to be an array() by default.
• Add an additional check within WP_Block_Supports::apply_block_supports() before trying to access a key on the array when it doesn't exist.

Trac ticket: #55586

[callumbw95]

Hey Everyone,

I have just taken a look into this and believe I have a working fix based on @jmichaelward's suggestion. I have had to add an additional check within apply_block_supports() to see if self::$block_to_render has a key of blockName as this variable is now set as an array() by default.

I believe this completely resolves the issue, and this ​PR should be ready to test once the pipelines complete. 😃

@CallumBW95 ,hey i want to work on this. if possible please assign this work to me.