• Part of Block API #41236.

Block Hooks are formerly know as Auto-inserting Blocks.

We've merged a basic version of auto-inserting blocks in #51449, and are currently working on adding UI controls in #52969. Generally, we seem to be on track for inclusion of this new feature in WordPress 6.4, whose feature freeze is on September 26 -- a little less than a month from now.

We've previously discussed auto-inserting blocks in #39439, which has also served as a tracking issue of sorts. I think it's time to close that issue in favor of a new tracking issue for the remaining tasks for inclusion in WP 6.4.

For Gutenberg 16.6.0

RC1: August 30
Stable release: September 6

• Auto-inserting blocks: Add block inspector panel #52969 (Adress feedback, merge.)
• Auto-inserting blocks: Remove toggle if block is present elsewhere #54024
• Auto-inserting blocks: Add block icon to block inspector panel toggles #54029
• Rename "auto inserting blocks" to "block hooks" #54147

For Gutenberg 16.7.0

RC1: September 20. Last Gutenberg version to be included in WP 6.4!

• Block Hooks: Incorrect placement in the parent container for hooked blocks #54307 that will get fixed with Blocks: Fix incorrect placement for hooked blocks in the parent container #54349.
• Make sure the panel doesn't show up outside of Site Editor - it happens in the Post Editor.
• Remove __experimental status (Block API: Stabilize Block Hooks feature #54293).
• Plugin: Ensure that Block Hooks work correctly after landing in WP core #54651

For WordPress 6.4

Feature Freeze: September 26

• Port PHP code to Core.
• Allow limiting auto-insertion by template type/template part type/post type etc. (Done in Blocks: Insert hooked blocks wordpress-develop#5261.)
  • This is a feature that most people basically request the moment they learn about auto-inserting blocks; I've most recently discussed it with @nerrad at the WCUS Contributor Day. IIRC, @mtias was somewhat skeptical about prioritizing a syntax in block.json for this.
  • One idea we've been discussing was some kind of filter. I'm happy to give that a try; one downside I see is that we'd fragment the API for auto-insertion a bit, by allowing specifying the anchor block and relative position in block.json, but only programmatically allowing limiting to certain template types etc.
  • The function signature I have in mind would at a minimum pass the current template type/template part type to the filter; maybe also the number of blocks that have already been inserted into the same template (see previous item). It might work similar to some of Core's pre_-prefixed filters that allow short-circuiting an operation (to avoid auto-insertion, in this case).
• Blocks: Introduce filter to allow easy addition of hooked blocks wordpress-develop#5271
• Blocks: Remove inject_hooked_block_markup filter wordpress-develop#5292
• Blocks: Add more unit test covering edge cases for Block Hooks wordpress-develop#5279
• Blocks: Change get_hooked_blocks() to returned hooked blocks grouped by relative position wordpress-develop#5297
• Templates: Deprecate _inject_theme_attribute_in_block_template_content(). wordpress-develop#5307
• Templates: Move old theme attr injection function to deprecated.php wordpress-develop#5317
• Templates: Introduce _remove_theme_attribute_from_template_part_block function wordpress-develop#5316
• Patterns: Add test coverage for patterns registry wordpress-develop#5299
• REST API: Improve the block type schema for the name field wordpress-develop#5278

Later

See #54904.

I'd say the above list sounds ambitious 😅 but not all items I've listed might be hard requirements for WP 6.4; keeping some of them for later will greatly reduce the workload. I'd be curious to hear y'all's thoughts on which ones you think should definitely go into 6.4.

The biggest risk IMO is currently the limitation to certain template types/post types, especially if we'd like to have syntax in block.json to accommodate for that (and not lock down the autoInsert field to a more basic syntax already). If we'd like to tackle that for WP 6.4, I could use a hand working on that 😬 @gziolo How's your availability in the next couple of weeks? 😅

It'd be great to give the feature some extended user testing once the block inspector panel lands (i.e. GB 16.6). @annezazu Is that something you could help with (or can you point me to someone else if your plate is full enough already)?

We'll need to eventually remove __experimental status, and add the autoInsert field to the block.json schema. Ideally, I'd like to give it a bit more time and only do so in time for 16.7 RC1 (which is the final version for inclusion in WP 6.4 if I'm not mistaken); please LMK if y'all feel that we should already do so for GB 16.6.

cc/ @priethor @mtias for feedback/project planning/general visibility 😄