Navigation: Update the fallback block list to avoid a PHP Warning

[dd32]

What?

This PR avoids PHP Warnings in traverse_and_serialize_block() which expects that innerContent and attrs are set.

I'm unsure if this is the proper place for the fix, or if the above function needs updating to properly handle a $block variable of [ 'blockName' => 'core/block-name' ] without the before mentioned parameters. I can see reasons for both.

Based on

gutenberg/packages/block-library/src/navigation/index.php

Lines 1376 to 1381 in b859f54

	$mock_anchor_parent_block = array(
	'blockName' => 'core/navigation',
	'attrs' => $attributes,
	'innerBlocks' => $inner_blocks,
	'innerContent' => array_fill( 0, count( $inner_blocks ), null ),
	);

this probably belongs here, but perhaps it should also be setting innerBlocks too like that?

It appears this was recently introduced with #57754 cc @tjcafferkey

Why?

Note: These warnings are on wordpress.org/showcase with Gutenberg 17.x, warning weren't present on 16.8

The code as-is, causes the following notices on WordPress Trunk:

WARNING: wp-includes/blocks.php:1114 - Undefined array key "innerContent"
require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('wp-includes/template-canvas.php'), get_the_block_template_html, do_blocks, render_block, WP_Block->render, render_block_core_template_part, do_blocks, render_block, WP_Block->render, render_block_core_pattern, do_blocks, render_block, WP_Block->render, WP_Block->render, render_block_core_navigation, WP_Navigation_Block_Renderer::render, WP_Navigation_Block_Renderer::get_inner_blocks, WP_Navigation_Block_Renderer::get_inner_blocks_from_fallback, block_core_navigation_get_fallback_blocks, block_core_navigation_insert_hooked_blocks, traverse_and_serialize_block, traverse_and_serialize_block

WARNING: wp-includes/blocks.php:1114 - foreach() argument must be of type array|object, null given
require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('wp-includes/template-canvas.php'), get_the_block_template_html, do_blocks, render_block, WP_Block->render, render_block_core_template_part, do_blocks, render_block, WP_Block->render, render_block_core_pattern, do_blocks, render_block, WP_Block->render, WP_Block->render, render_block_core_navigation, WP_Navigation_Block_Renderer::render, WP_Navigation_Block_Renderer::get_inner_blocks, WP_Navigation_Block_Renderer::get_inner_blocks_from_fallback, block_core_navigation_get_fallback_blocks, block_core_navigation_insert_hooked_blocks, traverse_and_serialize_block, traverse_and_serialize_block

WARNING: wp-includes/blocks.php:1149 - Undefined array key "attrs"
require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('wp-includes/template-canvas.php'), get_the_block_template_html, do_blocks, render_block, WP_Block->render, render_block_core_template_part, do_blocks, render_block, WP_Block->render, render_block_core_pattern, do_blocks, render_block, WP_Block->render, WP_Block->render, render_block_core_navigation, WP_Navigation_Block_Renderer::render, WP_Navigation_Block_Renderer::get_inner_blocks, WP_Navigation_Block_Renderer::get_inner_blocks_from_fallback, block_core_navigation_get_fallback_blocks, block_core_navigation_insert_hooked_blocks, traverse_and_serialize_block, traverse_and_serialize_block

How?

Sets the missing array indexes.

Testing Instructions

Unknown. It's triggered on wordpress.org/showcase, I'm assuming that a navigation menu block is used without a fallback menu present.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core SVN

If you're a Core Committer, use this list when committing to wordpress-develop in SVN:

Props: dd32, tomjcafferkey, youknowriad.

GitHub Merge commits

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: dd32 <dd32@git.wordpress.org>
Co-authored-by: tjcafferkey <tomjcafferkey@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[tjcafferkey]

Thanks @dd32 I'll try and get around to reviewing this today!

[tjcafferkey]

Nice catch. I've confirmed there is a PHP error when:

• Users Navigation block does not reference a post ID aka have a ref attribute.
• There is either no wp_navigation post in the database, or there is but its post_content is empty after filtering out null blocks.

In the above scenario it will just return a core/page-list block as the fallback for the sites Navigation.

Block Hooks API does assume block data is present when traversing and serializing these inner blocks to insert hooked blocks, which is where the error occurs as you've pointed out.

I've confirmed this PR does fix the error and the Block Hooks work continues to work as expected for the navigation so I'm going to approve.

cc @ockham and @youknowriad I'm not sure what next steps are for this. Does it need to be included in the next RC/release? I'm unfamiliar with the process myself.

[youknowriad]

This is in the block-library package and Gutenberg 17.7 will be entirely included in WordPress 6.5, which means there's no follow-ups required to this PR, it will be automatically backported to Core in the next package release/update.

[ockham]

Thanks a lot for the fix @dd32. Apologies, I missed this earlier.

I'm unsure if this is the proper place for the fix, or if the above function needs updating to properly handle a $block variable of [ 'blockName' => 'core/block-name' ] without the before mentioned parameters. I can see reasons for both.

I think this place is fine 👍

Based on

gutenberg/packages/block-library/src/navigation/index.php

Lines 1376 to 1381 in b859f54

	$mock_anchor_parent_block = array(
	'blockName' => 'core/navigation',
	'attrs' => $attributes,
	'innerBlocks' => $inner_blocks,
	'innerContent' => array_fill( 0, count( $inner_blocks ), null ),
	);

this probably belongs here, but perhaps it should also be setting innerBlocks too like that?

It might not hurt to add an innerBlocks setting for completeness' sake, but IIRC, in practice, GB will only attempt to iterate over that if it can successfully iterate over innerContent. Since the latter is set to an empty array, it shouldn't be a problem.