Post and Comment Template blocks: Change render_block_context priority to 1

[ockham]

What?

Block context relevant for the Post Template and Comment Template blocks (i.e. post ID and type, and comment ID, respectively) is set via the render_block_context filter. This PR changes that filter's priority from the default 10 to 1 (i.e. as early as possible).

This PR is based on @dhl01's WordPress/wordpress-develop#4780.

Why?

As explained in https://core.trac.wordpress.org/ticket/58699, block context for those blocks was previously directly passed as an argument to the WP_Block constructor. During the 6.3 cycle, we changed that to use the render_block_context filter instead (in #50313 and #50279, later amended by #50883). Overall, the filter-based approach has some benefits that we'd rather keep; however, I missed at the time that any other (3rd-party) render_block_context filter with priority of 10 or less would no longer receive that block context.

How?

This PR remediates that problem by assigning the earliest possible priority to both filters.

Testing Instructions

We have automated test coverage for this:

gutenberg/phpunit/blocks/render-comment-template-test.php

Lines 80 to 123 in e72a740

	public function test_rendering_comment_template_sets_comment_id_context() {
	$parsed_comment_author_name_block = parse_blocks( '<!-- wp:comment-author-name /-->' )[0];
	$comment_author_name_block = new WP_Block(
	$parsed_comment_author_name_block,
	array(
	'commentId' => self::$comment_ids[0],
	)
	);
	$comment_author_name_block_markup = $comment_author_name_block->render();
	$this->assertNotEmpty(
	$comment_author_name_block_markup,
	'Comment Author Name block rendered markup is empty.'
	);
	$render_block_callback = static function( $block_content, $block ) use ( $parsed_comment_author_name_block ) {
	// Insert a Comment Author Name block (which requires `commentId`
	// block context to work) after the Comment Content block.
	if ( 'core/comment-content' !== $block['blockName'] ) {
	return $block_content;
	}
	$inserted_content = render_block( $parsed_comment_author_name_block );
	return $inserted_content . $block_content;
	};
	add_filter( 'render_block', $render_block_callback, 10, 3 );
	$parsed_blocks = parse_blocks(
	'<!-- wp:comment-template --><!-- wp:comment-content /--><!-- /wp:comment-template -->'
	);
	$block = new WP_Block(
	$parsed_blocks[0],
	array(
	'postId' => self::$custom_post->ID,
	)
	);
	$markup = $block->render();
	remove_filter( 'render_block', $render_block_callback );
	$this->assertStringContainsString(
	$comment_author_name_block_markup,
	$markup,
	"Rendered markup doesn't contain Comment Author Name block."
	);
	}

Other than that, make sure that the Post Template and Comment Template blocks still work as before on the frontend. (This should be fairly straight-forward to verify in a current Block Theme, e.g. TT3.)

[github-actions]

Flaky tests detected in 10e8d8c.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5473873188
📝 Reported issues:

• [Flaky Test] should change image when user is changed #43593 in /test/e2e/specs/editor/blocks/avatar.spec.js

[dlh01]

Thanks for picking this up @ockham! Just noting I'm at @dlh01 if I can help with anything, not dhl 😄

[ockham]

Thanks for picking this up @ockham! Just noting I'm at @dlh01 if I can help with anything, not dhl 😄

Ahh, my bad! Apologies, I'll try to finally commit your GH handle to memory 😅

[cbravobernal]

Work as expected.

[cbravobernal]

I think this would need a cherry pick to Gutenberg 16.1 @tellthemachines @ramonjd

[ramonjd]

I think this would need a cherry pick to Gutenberg 16.1 @tellthemachines @ramonjd

Thanks for the ping. How egregious are these errors? Could they be part of 16.2.0 RC1?

I see a recent point release has been created for 16.1.2 - are you comfortable doing something similar if you think it should be in 16.1?

[tellthemachines]

I just cherry-picked this PR to the update/beta-4-second-round branch to get it included in the next release: 69236dc

[cbravobernal]

Thanks for the ping. How egregious are these errors? Could they be part of 16.2.0 RC1?

I think they could be. I've seen they are included in beta 4, so is OK with that.

Thanks for everything!

[ockham]

Yeah, this doesn't need a 16.1.x IMO. I'll cherry-pick it into 16.2 though!

[ockham]

Forgot to say Thank You All!

[ockham]

Yeah, this doesn't need a 16.1.x IMO. I'll cherry-pick it into 16.2 though!

Done in 07ef985.