`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.

[r1k0]

Patch Testing Report

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/9656

Environment

• WordPress: 7.0-alpha-61215-src
• PHP: 8.2.29
• Server: nginx/1.29.4
• Database: mysqli (Server: 8.4.8 / Client: mysqlnd 8.2.29)
• Browser: Chrome 144.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Steps taken

1. Ensure you have wordpress-develop repo cloned and set up correctly.
2. Cd to wordpress-develop, and perform

   npm i
   npm run build:dev
   npm run env:start
   npm run env:install
   

3. Run npm run env:cli shell and call get_block_wrapper_attributes();.
4. In another terminal window, navigate to /wp-content/debug.log.
5. Check the contents of the debug.log.
6. ✅ Patch is solving the problem

Expected result

• The PHP warnings are silenced when you call get_block_wrapper_attributes();.

Additional Notes

• In the current WordPress and PHP versions, the notices are classified as warnings.
• Removing needs-testing and leaving dev-feedback for reviewers to look through the patch.

Screenshots/Screencast with results

• Screencast before:

​https://files.catbox.moe/u4j1w4.webm

• Screencast after:

​https://files.catbox.moe/x02siq.webm

Support Content

None