• Part of Block API #41236.
• Supersedes Include Block Hooks in WordPress 6.4 #53987.

Block Hooks have been formerly know as Auto-inserting Blocks.

Plans for WordPress 6.5

• Enable for user-modified templates/parts/patterns
  • Store information about known hooked blocks in anchor block metadata
  • Block Hooks: Set ignoredHookedBlocks metadata upon saving
• No toggle shown for hooked blocks added via filter (Will be be fixed by the enabling Block Hooks for user-modified templates/parts/patterns.) (Edit: No it won't)
  • Block Hooks: Display toggle for hooked blocks added via filter #59396 added it for modified templates/parts/... at least.
• Block Hooks: Sibling insertion incompatible with constrained layout
• Allow child insertion into Navigation block
• Allow passing block definitions
• Toggle removed if multiple anchor block instances exist, and one hooked block is deleted
• Block Hooks: Respect allowedBlocks field and control for users #53989
  • Originally touched upon here. We might want to give a block some level of control what blocks it allows as its (auto-inserted) children.
  • There's an allowedBlock attribute that's currently used by a number of blocks; AFAICT, it's only handled on the client side, and basically passed through to the InnerBlocks component as a prop. I'm a bit hesitant to use something like this as it seems currently really up to each individual block, with no standardization, especially on the server (e.g. in the shape of block-supports).
  • Implementing this later might amount to an API change: Blocks that were previously auto-inserted might cease to be if their parent disallows them 😕

Other

• Performance: Try refactoring get_hooked_blocks() to check impact wordpress-develop#5399
• Block Hooks: Update the compatibility layer #58468 (Backport filter mechanism to Gutenberg.)
• Add higher-level test coverage (integration and/or e2e).
  • Largely follow "Possible scenarios to cover" section in this comment.
  • Add small test plugin that includes an auto-inserting block -- probably based on https://github.com/ockham/like-button.
• Respect template locks.
  • I need to read up on them, but I imagine we shouldn't auto-insert into a locked template? 😬
• Respect "multiple": false.
  • Blocks can stipulate they only be inserted once. Auto-insertion should probably respect that; @nerrad made a PoC PR during WCUS Contributor Day: Rough POC of respecting "supports multiple" in the auto-inserted block metadata #53925
  • Some prior discussion: "It could also be that autoInsert works upon the first encountered block of the specified type, so it doesn't get repeated if there are multiple navigation blocks in a page. Or maybe this is also a flag like useOnce."
  • This still doesn't give control over which navigation block that is (but will default to the first one encountered); we might want a mechanism to select that, too. See next item for a somewhat related problem.
  • Finally, note that the multiple field was originally introduced for a post editor context; it isn't really well-defined in a template/Site Editor, as @gziolo has observed.
• Notify user that there’s a new auto-inserted block available (after activating a new plugin that includes that block).
  • In the editor, or even wp-admin? Needs design.
  • How it could be implemented: Make list of registered blocks before and after plugin activation, compare; see if newly added block.json has autoInsert field? (Doesn't cover blocks that are auto-inserted programmatically.)