Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#56799 closed defect (bug) (fixed)

PHP notice in class-wp-block-supports.php

Reported by: petitphp's profile petitphp Owned by: hellofromtonya's profile hellofromTonya
Milestone: 6.1 Priority: normal
Severity: normal Version: 6.1
Component: Editor Keywords: has-patch commit
Focuses: Cc:

Description

On Core trunk with the TwentyTwentyThree theme with debug mode, a notice is visible on the frontend :

 Notice: Undefined index: attrs in /var/www/src/wp-includes/class-wp-block-supports.php on line 97

This come from the WP_Block_Supports::apply_block_supports method which expect the block data to contain an attrs key :

public function apply_block_supports() {
    $block_attributes = self::$block_to_render['attrs'];
    $block_type       = WP_Block_Type_Registry::get_instance()->get_registered(
			self::$block_to_render['blockName']
    );
    ...

Change History (10)

This ticket was mentioned in Slack in #core by petitphp. View the logs.


2 years ago

#2 @desrosj
2 years ago

  • Milestone changed from Awaiting Review to 6.1

Moving to the milestone for investigation.

This ticket was mentioned in PR #3442 on WordPress/wordpress-develop by petitphp.


2 years ago
#3

  • Keywords has-patch added

This ticket was mentioned in Slack in #core by desrosj. View the logs.


2 years ago

#5 @spacedmonkey
2 years ago

Maybe related: #56801

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


2 years ago

#7 @petitphp
2 years ago

To add more context, this seem to come from the core/page-list block which doesn't declare any attributes. That seem to cause the self::$block_to_render to not contain a key attrs in the PHP side.

This in turn was causing a warning in wp-includes/block-supports/custom-classname.php, reported in #56801

Version 0, edited 2 years ago by petitphp (next)

#8 @hellofromTonya
2 years ago

  • Component changed from General to Editor
  • Keywords commit added
  • Owner set to hellofromTonya
  • Status changed from new to reviewing

I am able to reproduce the reported issue. The PR resolves the issue and is ready for commit. Self-assigning. Will commit shortly.

#9 @hellofromTonya
2 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 54498:

Editor: Fix PHP notice in WP_Block_Supports when no attributes declared.

A check is added to verify if the block's 'attrs' key exists before accessing it. If no, it defaults to an empty array.

How was this found?
WP 6.1 removed the attributes from the core/page-list block. When this block is being processed by WP_Block_Supports::apply_block_supports(), the key 'attrs' does not exist in self::$block_to_render.

This commit includes a tiny micro-optimization by moving this line of code after the existing guard clause. Why? If the guard clause is triggered, the method bails out early, meaning the attributes code is not used. By moving it after the guard clause, it saves a tiny bit of memory and processing if this happens.

Follow-up to [49310], [54399].

Props petitphp, spacedmonkey, hellofromTonya.
Fixes #56799.

hellofromtonya commented on PR #3442:


2 years ago
#10

Committed via changeset https://core.trac.wordpress.org/changeset/54498. Thank you @petitphp for your contribution!

Note: See TracTickets for help on using tickets.