Block Hooks: Apply to Post Content (on frontend)

[ockham]

Details to follow. Trac ticket: https://core.trac.wordpress.org/ticket/61074

What?

Apply Block Hooks to Post Content (frontend only).

Why?

We've seen some demand for this. A typical example would be a plugin that provides blocks that can be used in posts and that would like to provide extensibility for those blocks.

Why not?

Note that hooked blocks are inserted on the frontend, but not in the editor. This violates editor/frontend parity, which we've previously taken great care to preserve (when applying Block Hooks gradually to more contexts, such as templates, Navigation blocks, etc).

The alternative -- inserting hooked blocks into post content in the editor -- is also not without problems.

How?

By adding a filter to the_content that invokes apply_block_hooks_to_content.

Testing Instructions

You need a block that hooks to an anchor block that's present in your content.

I'm using the Like Button block, which I've modified locally to be inserted after the core/gallery block:

diff --git a/public/block.json b/public/block.json
index 4bb03d0..59873d1 100644
--- a/public/block.json
+++ b/public/block.json
@@ -18,6 +18,6 @@
        "render": "file:./render.php",
        "viewScript": "file:./view.js",
        "blockHooks": {
-               "core/comment-template": "lastChild"
+               "core/gallery": "after"
        }
 }

I've created a post with a Gallery block, followed by a paragraph.

When viewed on the frontend, that should cause the Like Button block to be inserted after the gallery (and before the paragraph).

Screenshots or screencast

(Note that the second Like Button that's visible in the screenshot is inserted by this code. If you'd like to remove it, you can comment out that filter, or edit the template to delete the block.

[gziolo]

As simple as that? apply_block_hooks_to_content util is really powerful at this point. What risks do you see with this approach? What if there are synced patterns inside the rendered content? I assume they all are annotated with block hooks to ignore at this point, so double processing should be a non-issue if we ignore the additional CPU usage.

[ockham]

Yeah, I was also really happy when I saw how straight-forward this was. apply_block_hooks_to_content was introduced by @tjcafferkey, and it really is a great high-level util to insert Block Hooks into a piece of block markup 😄

What risks do you see with this approach? What if there are synced patterns inside the rendered content? I assume they all are annotated with block hooks to ignore at this point, so double processing should be a non-issue if we ignore the additional CPU usage.

Yeah, intuitively I'd say this shouldn't duplicate any hooked blocks, but I do want to give it some good smoke testing to be sure.

[ockham]

I've filed a backport (WordPress/wordpress-develop#7889).

I'm also experimenting with an alternative in WordPress/wordpress-develop#7898 (easier to do in Core than in GB), which will insert hooked blocks both on the frontend and in the editor. Maybe we can get that to work after all.