Block Hooks: Allow passing block definitions to hooked_block_types filter (and thus, hooking patterns)

[ockham]

Another alternative to #5811 and #5835. Uses some code from #5609.

Implements an idea originally conceived of in https://core.trac.wordpress.org/ticket/59572:

We might want to allow providing a full, parsed-block style, block definition, at least for the filter:

array( 'mycommerce/mini-cart', array(
        'isPreview'    => true,
        'miniCartIcon' => 'bag',
) )

In addition, this PR seeks to also explore a possible solution for https://core.trac.wordpress.org/ticket/60126: With the ability to pass attributes for hooked blocks, we can now hook patterns (by giving core/pattern as the block type, and setting the slug attribute to the desired pattern).

To demonstrate the latter, apply the following patch to the Like Button block code:

diff --git a/like-button.php b/like-button.php
index 65acbc3..08a54c1 100644
--- a/like-button.php
+++ b/like-button.php
@@ -22,5 +22,35 @@
  */
 function create_block_like_button_block_init() {
 	register_block_type( __DIR__ . '/build' );
+
+	register_block_pattern(
+		'ockham/like-button-wrapper',
+		array(
+			'title'       => __( 'Like Button', 'like-button' ),
+			'description' => _x( 'A button to like content.', 'Block pattern description', 'like-button' ),
+			'content'     => '<!-- wp:group {"layout":{"type":"constrained"}} --><div class="wp-block-group"><!-- wp:ockham/like-button /--></div><!-- /wp:group -->',
+			'inserter'    => false
+		)
+	);
 }
 add_action( 'init', 'create_block_like_button_block_init' );
+
+function insert_like_button_pattern_after_post_content( $hooked_blocks, $position, $anchor_block ) {
+	if ( 'after' !== $position ) {
+		return $hooked_blocks;
+	}
+
+	if ( 'core/post-content' !== $anchor_block ) {
+		return $hooked_blocks;
+	}
+
+	$hooked_blocks[] = array(
+		'blockName' => 'core/pattern',
+		'attrs'     => array(
+			'slug' => 'ockham/like-button-wrapper',
+		),
+	);
+
+	return $hooked_blocks;
+}
+add_filter( 'hooked_block_types', 'insert_like_button_pattern_after_post_content', 10, 3 );
diff --git a/src/block.json b/src/block.json
index 99660d4..1cd5685 100644
--- a/src/block.json
+++ b/src/block.json
@@ -19,7 +19,6 @@
 	"viewScript": "file:./view.js",
 	"usesContext": [ "postType", "postId", "commentId" ],
 	"blockHooks": {
-		"core/comment-template": "lastChild",
-		"core/post-content": "after"
+		"core/comment-template": "lastChild"
 	}
 }

TODO:

• Think about downsides: Still doesn't allow flexible setting of the layout type depending on adjacent blocks (only hard-wired). Or do patterns support anything of the sort?
• Allow specifying attributes for hooked blocks in block.json after all?

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

---

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.

[ockham]

FYI @andrewserong @tellthemachines @yansern @TimBroddin
(Note that this is an early-stage exploration.)

[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]

@gziolo had another suggestion:

Suggested change

	$hooked_block_types = apply_filters( 'hooked_block_types', $hooked_block_types, $relative_position, $anchor_block_type, $context );
	$hooked_block_types = apply_filters( "hooked_blocks_{$anchor_block_type}", $hooked_blocks, $relative_position, $anchor_block, $context );

or even

Suggested change

	$hooked_block_types = apply_filters( 'hooked_block_types', $hooked_block_types, $relative_position, $anchor_block_type, $context );
	$hooked_block_types = apply_filters( "hooked_blocks_{$relative_position}_{$anchor_block_type}", $hooked_blocks, $anchor_block, $context );

which would allow a syntax like

add_filter( 'hooked_blocks_before_ockham/like-button', ... );

[ockham]

Advantages of this approach

• Couples addition/removal of hooked blocks with specifying attributes, thus allowing e.g. using a core/pattern block with its slug attribute specified (as demonstrated by the code in the PR desc), which isn't really possible with the hooked_block filter approach in Block Hooks: Introduce a new hooked_block_{$block_type} filter #5835, as explained here.

Downsides of this approach

• By allowing parsed block arrays as entries of the array in the first arg, we're bending the notion of hooked block types quite a bit 😅
• While it might be appealing to be able to use a pattern (and specify its slug) as a hooked block, that's not quite enough to solve https://core.trac.wordpress.org/ticket/60126, as we cannot dynamically set the containing group block's layout attribute.
• What's more is that even if we don't use a pattern but e.g. use a Group block wrapper (and set its inner block to be a Like button), we don't know wha the adjacent anchor block's layout attribute is set to (if any) as we only have access to anchor_block_type (but not the actual anchor block instance that includes attributes etc).
  • To remediate, we would either need to add yet another argument to the filter (the full $anchor_block instance), which would be very ugly; or alternatively, to change the existing $anchor_block_type to implement PHP's ArrayAccess trait, and __toString. But that's a bit too much magic _on top of allowing $hooked_block_types's entries to arrays of parsed block arrays.
• If a filter wants to remove a hooked block, lookup in the $hooked_block_types array becomes harder; rather than just searching a string, it now also needs to account for the possibility that an array entry could be an parsed block array, and would need to compare the search string to that array's blockName field.

[tellthemachines]

I just reported the spam comments above to GH, not sure if I should delete them now or leave them here as evidence 🤔

[andrewserong]

I just did the same 😄
Do you have an option to hide the comments in the ellipsis menu on each comment? (I don't have access to in this repo)

[tellthemachines]

Great idea @andrewserong! Done.

[ockham]

Thanks, folks!

I wonder what keeps attracting spambots to this PR; I already reported another one about a week ago 😕

[ockham]

Closing this in favor of #5835. Per discussion on #5811, #5835 (comment), and #5837 (comment), I believe that #5835 is the better design and has fewer drawbacks.