Block Hooks API: Add ignoredHookedBlocks meta when preparing REST API response

[tjcafferkey]

The block hooks toggle relies on the ignoredHookedBlocks when determining whether to show the toggle in the Site Editor UI. The current problem is that for uncustomized templates we don't add this meta data so to fix this problem we need to run the block hooks logic with the set_ignored_hooked_blocks_metadata callback when preparing the template for the response.

TODO:

• Unit test coverage
• Add filter to prepare_item_for_response() method
• Add filter callback to run block hooks logic and add metadata attributes

Trac ticket: https://core.trac.wordpress.org/ticket/59574

Testing instructions:

1. Add the below code to your themes functions.php file to add a hooked block.
2. Ensure the Single Posts template has all customizations cleared
3. Load the Single Posts template in the Site Editor and click the Post Content block to confirm it has the hooked block toggle.

function register_hooked_block( $hooked_blocks, $position, $anchor_block, $context ) {
	if ( $anchor_block === 'core/post-content' && $position === 'after' ) {
		$hooked_blocks[] = 'core/loginout';
	}

	return $hooked_blocks;
}

add_filter( 'hooked_block_types', 'register_hooked_block', 10, 4 );

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[tjcafferkey]

In our other filter here instead of documenting it we referenced the WP Posts controller since it is an identical filter.

In this case we can't do that since the second param is different and returns WP_Block_Template instead of WP_Post.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[ockham]

Thank you for taking this on! This is shaping up nicely 😄

I was originally thinking to tackle this at a different level, by basically composing a new callback from set_ignored_hooked_blocks_metadata and insert_hooked_blocks that we'd then pass as third argument to instances of make_{before|after}_block_visitor where we'd previously passed insert_hooked_blocks (or no third argument at all, since it's the default).

function set_ignored_hooked_blocks_metadata_and_insert_hooked_blocks ( &$parsed_anchor_block, $relative_position, $hooked_blocks, $context ) {
	$markup = insert_hooked_blocks( $parsed_anchor_block, $relative_position, $hooked_blocks, $context );
	set_ignored_hooked_blocks_metadata( $parsed_anchor_block, $relative_position, $hooked_blocks, $context );
	return $markup;
}

/ * ... */

if ( ! empty( $hooked_blocks ) || has_filter( 'hooked_block_types' ) ) {
	$before_block_visitor = make_before_block_visitor( $hooked_blocks, $template, 'set_ignored_hooked_blocks_metadata_and_insert_hooked_blocks' );
	$after_block_visitor  = make_after_block_visitor( $hooked_blocks, $template, 'set_ignored_hooked_blocks_metadata_and_insert_hooked_blocks' );
	}
$blocks            = parse_blocks( $template->content );
$template->content = traverse_and_serialize_blocks( $blocks, $before_block_visitor, $after_block_visitor );

The downside of my approach is that it'll inject the ignoredHookedBlocks attribute not only into the REST API response, but also into the frontend-rendered markup, where it's not needed (although it's also not harmful). In this regard, your approach arguably better preserves separation of concerns. Its downside is that it's going to parse and re-serialize block markup twice for REST API responses: Once at the low level for hooked block insertion, and once at the newly introduced REST API response hook for ignoredHookedBlocks attribute injection. Repeated parsing and re-serialization of block markup is something we've tried to avoid on the frontend, as it did impact performance measurably; it's probably a bit less critical for the REST API.

So I think we basically need to pick which trade-off we're willing to make 😄