Block Hooks

[abhansnuk]

Marked as needing a standalone dev note on the Gutenberg repo. Two tickets were combined in Oct 2023 to be one dev note on Block Hooks area.

For info, the full list and discussion on these tickets WordPress/gutenberg#54998

[github-actions]

Heads up @WordPress/docs-issues-coordinators, we have a new issue open. Time to use 'em labels.

[abhansnuk]

Updating this ticket to be a combined dev note for 'Block Hooks' as this has changed in the Gutenberg tracker.

Experiment: Auto-inserting blocks on the frontend and in the editor (via REST API) #51449- Dev Note tracking: Experiment: Auto-inserting blocks on the frontend and in the editor (via REST API) #51449

WordPress/gutenberg#54293
WordPress/gutenberg#51449

@Gzielo and @ndiego working on the dev note (TBC).

[ndiego]

@abhansnuk when do you need the Dev Note posted by?

[bph]

Hi @ndiego Ideally, we need it by Monday... but do check in if there are blockers...

[bph]

Draft in Progress https://make.wordpress.org/core/wp-admin/post.php?post=108745&action=edit

[abhansnuk]

Excellent dev note @ndiego and really like your explanation and dividing this into two clear points, plus explaining why this causes some limitations.

I have done the second review for time, and

• changed the reference to "let's us" to 'explore below" to avoid the reference to 'we' and 'us' in dev notes
• added Developer Blog to the link to the article (good link by the way) to raise awareness that this exists
• added an excerpt
• added tags
• added props line. Other collaborators or reviewers to be added to this

I wondered as this is going to be a very useful feature for eCommerce, whether there was a tag that has been used before on dev notes for flagging up notes particularly useful for eCommerce. @bph you might already know.

Thanks Nick for writing this dev note. Perhaps it is one that will give rise to some case study posts on the Dev Blog.

[ndiego]

Thanks @abhansnuk! I'll add a few additional props when you are out. The code blocks still need a final review tomorrow by @gziolo.

[bph]

I reviewed the post:

• changed title to Introduction to Block Hooks for dynamic blocks
• typo fixed: Blook Hooks to Block Hooks
• added an excerpt
• changed title "Plugins" to titled Plugins (Style guide: when referring to UI items, they need to be bolded)
• added review props

waiting for @gziolo's review to be published

[gziolo]

The example included could get some tiny changes:

function example_block_hooks( $hooked_blocks, $position, $anchor_block, $context ) {

	// Template/Template Part hooks.
	if ( $context instanceof WP_Block_Template ) {
		
		// Hooks the "Like" button block before the Post Title in the Single template.
		if ( 
			'core/post-title' === $anchor_block &&
			'before' === $position &&
			'single' === $context->slug
		) {
			$hooked_blocks[] = 'ockham/like-button';
		}

		// Hooks the Login/Logout link block after the Navigation block if the context of the template part is a header.
		if ( 
			'core/group' === $anchor_block &&
			'last_child' === $position &&
			'header' === $context->area
		) {
			$hooked_blocks[] = 'core/loginout';
		}
	}

	// Pattern hooks.
	if ( is_array( $context ) && isset( $context['slug'] ) ) {
		
		// Hooks into the Post Meta pattern in the Twenty Twenty-Four theme.
		if ( 
			'core/post-terms' === $anchor_block && 
			'after' === $position && 
			'twentytwentyfour/post-meta' === $context['slug']
		) {
			$hooked_blocks[] = 'ockham/like-button';
		}
	}

	return $hooked_blocks;
}

The list of proposed changes:

• Stylistic: code comments end with full stop 😅
• Stylistic: used 3rd person when starting code comments to align with coding standards 😅
• Stylistic: there were two spaces before “after the Navigation block`.
• It’s going to be better to check if an instance of $context is WP_Block_Template. This way, we ensure that all fields used later are defined.
• With patterns, we don’t have the luxury of well-defined API, so we must operate cautiously. The only mandatory fields for registered patterns are title and content, so that’s why we always need to use isset or similar constructs to ensure the value is defined. In general, we should account for future changes where a different array could get passed as $context.

[bph]

I added updated the code examples. Thank you, @gziolo

[bph]

Published: Introducing Block Hooks for dynamic blocks

[ndiego]

Thanks everyone. I see this has been published. Team effort 💪

[abhansnuk]

Published link https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/
Was added to Field Guide.