PHP Warnings when featured image blocks have a sizeSlug but not classname

[tomjn]

Description

If i use the following block I get PHP warnings in core:

<!-- wp:post-featured-image {isLink":true,"sizeSlug":"medium"} /-->

The addition of sizeSlug is the instigator, and it's related to the className attribute.

I can resolve this by using the render_block_data to filter the block data and ensure that if className is unset it has an empty string value:

function render_block_data( array $parsed_block ) : array {
	if ( $parsed_block['blockName'] === 'core/post-featured-image' ) {
		if ( ! isset( $parsed_block['attrs']['className'] ) ) {
			$parsed_block['attrs']['className'] = '';
		}
	}
}

This is the warning:

array_key_exists() expects parameter 2 to be array, null given

And it appears in 2 locations in core every time the block is rendered:

wp-includes/block-supports/align.php:48
wp_apply_alignment_support()
wp-includes/class-wp-block-supports.php:119
WP_Block_Supports->apply_block_supports()
wp-includes/class-wp-block-supports.php:176
get_block_wrapper_attributes()
wp-includes/blocks/post-featured-image.php:77
render_block_core_post_featured_image()
wp-includes/class-wp-block.php:258
WP_Block->render()
wp-includes/class-wp-block.php:244
WP_Block->render()
wp-includes/blocks.php:1051
render_block()
wp-includes/blocks.php:1089
do_blocks()
wp-includes/blocks/template-part.php:146
render_block_core_template_part()
wp-includes/class-wp-block.php:258
WP_Block->render()
wp-includes/class-wp-block.php:244
WP_Block->render()
wp-includes/blocks/post-template.php:98
render_block_core_post_template()
wp-includes/class-wp-block.php:258
WP_Block->render()
wp-includes/class-wp-block.php:244
WP_Block->render()
wp-includes/class-wp-block.php:244
WP_Block->render()
wp-includes/class-wp-block.php:244
WP_Block->render()
wp-includes/class-wp-block.php:244
WP_Block->render()
wp-includes/blocks.php:1051
render_block()
wp-includes/blocks.php:1089
do_blocks()
wp-includes/block-template.php:240
get_the_block_template_html()
wp-includes/template-canvas.php:12

and:

wp-includes/block-supports/custom-classname.php:48
wp_apply_custom_classname_support()
wp-includes/class-wp-block-supports.php:119
WP_Block_Supports->apply_block_supports()
wp-includes/class-wp-block-supports.php:176
get_block_wrapper_attributes()
wp-includes/blocks/post-featured-image.php:77
render_block_core_post_featured_image()
wp-includes/class-wp-block.php:258
WP_Block->render()
wp-includes/class-wp-block.php:244
WP_Block->render()
wp-includes/blocks.php:1051
render_block()
wp-includes/blocks.php:1089
do_blocks()
wp-includes/blocks/template-part.php:146
render_block_core_template_part()
wp-includes/class-wp-block.php:258
WP_Block->render()
wp-includes/class-wp-block.php:244
WP_Block->render()
wp-includes/blocks/post-template.php:98
render_block_core_post_template()
wp-includes/class-wp-block.php:258
WP_Block->render()
wp-includes/class-wp-block.php:244
WP_Block->render()
wp-includes/class-wp-block.php:244
WP_Block->render()
wp-includes/class-wp-block.php:244
WP_Block->render()
wp-includes/class-wp-block.php:244
WP_Block->render()
wp-includes/blocks.php:1051
render_block()
wp-includes/blocks.php:1089
do_blocks()
wp-includes/block-template.php:240
get_the_block_template_html()
wp-includes/template-canvas.php:12

Step-by-step reproduction instructions

Try to use a sizeSlug attribute on a featured image block in a block theme

Screenshots, screen recording, code snippet

No response

Environment info

WP 6.2 with a block theme

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[carolinan]

Is this markup copied from an actual block that was inserted in the editor?

What I mean is, if this attribute is added manually in the markup, for example, in an HTML template, the attribute is incorrect, because the markup is invalid and the warning would be accurate.

[tomjn]

No it’s based on attributes declared in the block that don’t have GUI anymore. Trying to resolve blurry featured images when an image tag is large but has been given a tiny height and width by WP. It seems that core assumes the class name attribute has a value which isn’t a safe assumption

…

On Thu, 6 Apr 2023 at 08:51, Carolina Nymark ***@***.***> wrote: Is this markup copied from an actual block that was inserted in the editor? — Reply to this email directly, view it on GitHub <#49615 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOLZ2R4CCSGYY3YLGJGVLW7ZYZTANCNFSM6AAAAAAWUEV7WY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[carolinan]

I understand now.

I am not sure if that could be handled in the deprecation of the featured image block 🤔 It probably assumes the class name should be preserved.

[tomjn]

Even still I'd assume there'd be a logic issue rather than a warning, this is the place it occurs in one of the stack traces:

function wp_apply_custom_classname_support( $block_type, $block_attributes ) {
	$has_custom_classname_support = block_has_support( $block_type, array( 'customClassName' ), true );
	$attributes                   = array();
	if ( $has_custom_classname_support ) {
		$has_custom_classnames = array_key_exists( 'className', $block_attributes );

I'm unsure why $block_attributes would be null in this specific scenario. I've been unable to reproduce the issue using other attributes and blocks and my workaround to ensure a null className attribute is set to '' is still working strong.

Noting I've yet to test this with the GB plugin

[t-hamano]

I am attempting to reproduce this problem but have not yet been able to output a warning error. Is this problem related to the size of the images, or the media settings?

[tomjn]

It's using the specific markup I posted in the opening issue, the sizeSlug reliably reproduces this issue for me. Removing it removes the issue.

Somewhere there's an assumption that a value is always a string or array when it is not and it's being passed down and causing a PHP warning. In this case, checking if className is null and replacing it with an empty string in a filter avoids the PHP warnings

Note that I have not tested this with the gutenberg plugin, only stock WP 6.2 and a block theme

[carolinan]

Are you saying the markup is not produced by placing a block in the editor and then upgrading WordPress?

[carolinan]

If a block expects both an attribute and a class name, then removing one makes the markup invalid and the error is correct. The solution is to correct the markup, not the expectation...

[tomjn]

The featured image is displayed on the frontend despite the PHP warnings, the HTML is not the problem.

As I mentioned, this is enough to reproduce the problem reliably at my end in WordPress 6.2:

<!-- wp:post-featured-image {isLink":true,"sizeSlug":"medium"} /-->

sizeSlug is an attribute declared and supported by that block.

But even if sizeSlug was arbitrary and unknown to WordPress I would not expect a PHP warning

I'm also unsure where upgrading WordPress is coming from, I did not mention WordPress upgrades. Just that the above block in WordPress 6.2 generates PHP warnings for me, and that I had to write a filter to give className a non-empty value to resolve this

[tomjn]

If you are suggesting that the className should have been added also, then this is unclear, but also reinforces that the code handling this is brittle and prone to PHP warnings, and should be handling the false assumption. className may be missing for other reasons, e.g. faulty filters. I would much prefer a doing it wrong style message in this situation than a cryptic PHP warning resulting from unhandled bad values

[carolinan]

I asked how the markup was generated, and you replied:

it’s based on attributes declared in the block that don’t have GUI anymore.

I assumed that if the UI is gone, there has been a change in the block code, and the error, like a missing class name, should have been resolved by a deprecation when the block code was changed.

So yes, because it did not sound like the user had manually added incomplete markup, I thought there was a block placed in a previous version of WordPress or Gutenberg and that updating either caused the error.

[carolinan]

If you are suggesting that the className should have been added also, then this is unclear, but also reinforces that the code handling this is brittle and prone to PHP warnings, and should be handling the false assumption. className may be missing for other reasons, e.g. faulty filters. I would much prefer a doing it wrong style message in this situation than a cryptic PHP warning resulting from unhandled bad values

I agree

[carolinan]

It is very unclear because not all attributes have a class name, and some class names replace attributes that have been removed or renamed to keep backward compatibility.