Block Hooks: Enable for post content

[Bernhard Reiter]

The Block Hooks mechanism is currently enabled for templates, template parts, patterns, and Navigation menu -- i.e. parts of a site's layout that are edited in the Site Editor. It is not enabled for post content: Hooked blocks won't be inserted into a post (or page), even if the latter contains the corresponding anchor block.

Prior to #59646, this was due to a technical limitation. However, with that limitation removed, we could consider enabling Block Hooks for post content.

This might have some benefits -- among other things, it might align better with users' expectations. But maybe there are also reasons to refrain from doing so?

[tomjcafferkey]

One potential downside of enabling this that I can think of vs templates is when a plugin has hooked a block into my Single Post/Page template I can remove that block from that one template.

If the block has been hooked into my content I'd have to potentially go through each individual post/page to remove it.

Port of ​https://github.com/WordPress/gutenberg/pull/67272.

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

Alternative exploration, based on #7889.

TODO:

• [ ] Hook update_ignored_hooked_blocks_postmeta into rest_pre_insert_post

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

I have drafted an alternative PR based on this one to explore also inserting hooked blocks into Post Content _in the editor_: ​https://github.com/WordPress/wordpress-develop/pull/7898

FYI @kmanijak. Maybe you can give this a try and let me know if it works for the purpose you're interested in! 😊

FYI @kmanijak. Maybe you can give this a try and let me know if it works for the purpose you're interested in! 😊

Thank you @ockham for working on this! 🚀 I gave it a try and at first glance it works as expected! I can achieve the goals raised in scope of the ​discussion in WooCommerce. I'll play with it more tomorrow to check if I see any problems.

One potential feature I can already see (but obviously not the scope for this PR!) is the ability for more strict selectors. For example: $anchor_block as core/post-title but only within Query Loop, not _any_ core/post-title, including the main post title. This very specific example can be workaround by checking if ($context instanceof WP_Post) { but wanted to give some generic example.

Anyway, looking good, thank you! 🙌

Just following up on @kmanijak's comments. We flagged this as an issue to the Woo team, specifically about hooking blocks into Woo's Product Collection block when it was included in pages. Unfortunately, the patch here doesn't appear to resolve the issues we were seeing (we're unable to add hooked blocks inside the Product Collection block).

It's possible that the issue is Woo-specific (or on our side), but I just wanted to drop my observations here in case it is fundamental to the solution.
​https://github.com/woocommerce/woocommerce/discussions/44776#discussioncomment-11414874

I'm testing with the WP 6.7.1 with the patch from this issue. Are there other dependent changes to make this work (ie would I have to start with WP trunk?)

Thanks a lot for testing, @leewillis77! I'm a bit puzzled as to why this wouldn't work if patched against 6.7.1; there shouldn't really be any dependent changes required for this.

Can you maybe try with the ​playground link (from ​this comment)?

For reviewers: @kmanijak ​has kindly tested this using the Woo Product Collection block and my ​Like Button block in a number of different scenarios 🙂

@ockham @kmanijak I've re-tested this today (fresh install, re-patch etc.), and can confirm that block hooks *are* fired correctly on posts/pages. No idea why we couldn't get this working last week.

However, trying our actual implementation rather than just artificial tests I don't think this is going to give us what we actually need (what was originally raised on the WooCommerce discussion) due to the lack of contextual information (as @kmanijak alluded to in ​https://github.com/WordPress/wordpress-develop/pull/7898#issuecomment-2506684117).

Ideally what we need in block hooks when we're deciding whether or not to hook a block in or not is the context of where it is. This is the same issue I originally raised in ​https://github.com/WordPress/gutenberg/issues/54904#issuecomment-1875449258. It's particularly bad here as the $context isn't even the top-level block, but a WP_Post object so we don't even have any idea what top-level block is being rendered so that we can make an informed decision about whether we should be hooking in or not.

Closing in favor of ​https://github.com/WordPress/wordpress-develop/pull/7898.

@gziolo Since insertion as the Post Content block's first or last child required changes to that block's PHP, I've updated the ​Gutenberg PR -- it also includes the required compat layer changes backported from this PR. Would you mind reviewing giving the GB PR a look?

There are a few open questions on this PR:

• ​Add filter to allow different post type/block type mappings?
• ​Use `rest_prepare_` hook to insert hooked blocks into REST API response, or add inline in controller?

However, I don't think that those should be blockers for the Gutenberg PR. Both of them deserve some more consideration, but we might do that as part of this PR -- possibly even after the GB PR has landed 😊

I was following the testing instructions from the description and when I add more headings the separator is not being added 😕

Testing Instructions, Part Two
…

• Save the post, and reload it on the frontend. Note that a separator has now been inserted before the newly added heading! ✨
• Finally, reload the post in the editor. Note that the separator is now also present there.

I was following the testing instructions from the description and when I add more headings the separator is not being added 😕

When I add more headers they all look like this, which I believe is _not_ intended according to the testing instructions:

<h1 class="wp-block-heading">text</h1>

@sirreal Good spot! Turns out @gziolo ​noticed the same thing over at the GB PR. I ​replied there. The _tl;dr_ is

Apologies, I think that this change in behavior is a side effect of some code I pushed after I wrote the testing instructions.
It's actually not bad in terms of UX -- a bit more predictable maybe. I'm happy to just consider it a happy accident and land it as-is.

So we might keep it this way. I'll add a note to the testing instructions.

[Bernhard Reiter]

In 59523:

Block Hooks: Enable for post content.

Block Hooks were previously only applied to layout elements such as templates, template parts, patterns, and navigation menus -- things that are edited in the Site Editor.

This changeset enables Block Hooks in post content. The parity between frontend and editor is preserved: Blocks inserted by Block Hooks are visible both on the frontend and in the editor, and any customizations made by the user are respected on the frontend.

This is possible thanks to setting the metadata.ignoredHookedBlocks attribute on anchor blocks (a technique first introduced in [57594]). For first child and last child insertion into a Post Content block, the corresponding post object's _wp_ignored_hooked_blocks post meta is set.

Props bernhard-reiter, gziolo, jonsurrell, karolmanijak, leewillis77.
Fixes #61074.

Committed to Core in https://core.trac.wordpress.org/changeset/59523.

I'll file some follow-up tickets/PRs to cover some open questions:

• ​Enable for synced patterns (`core/block`)
• ​Potentially add filter to extend set of block types and post types that Block Hooks are applied to
• ​Potentially inline code into Posts controller to cover "all" post types (rather than manually adding the filter to individual `rest_prepare_*` filters)