Block Hooks: Suppress insertion of hooked blocks in before/after position into post object content

[ockham]

As of WordPress 6.8, Block Hooks are also applied to post content. In order to allow for first/last child insertion of a hooked block into the Post Content block, we wrap the block's post content (as obtained from the DB) in a temporary <!-- wp:post-content --> wrapper block, run the apply_block_hooks_to_content_from_post_object function on the resulting markup, and remove the wrapper block.

In #63287, @obenland reported that there was a problem when using Block Hooks to insert a block before or after a Post Content block. See that ticket for more details about how the bug manifested itself.

After some thought, I believe that we need to exempt hooked blocks that are meant to be inserted before or after a Post Content block from the apply_block_hooks_to_content_from_post_object algorithm when it is run on a post object's content wrapped in a temporary wrapper block. Arguably, a block that is supposed to be before or after a given block should not be absorbed into the latter's content; instead, it should remain outside. (This is in contrast to first/last child insertion, where it makes sense to absorb the child block inside of the anchor block.)

(Instead, if a block is supposed to be inserted before or after a Post Content block, it should be the job of the containing markup entity -- typically a template -- to absorb it.)

The present PR implements this idea by adding logic to a pre-existing filter that is run with "latest" priority on the hooked_block_types hook. Specifically, that logic checks if the given context is a post object, and if so, verifies that the anchor block matches the post object's corresponding block type. (This means that it isn't limited to the Post Content block, but also applies to the Synced Pattern and Navigation blocks.)

---

Includes test coverage for the following scenarios:

• Hooked block inserted before/after Post Content block via block registration. 34c6493 This is the case that led to the bug being detected, see #63287.
• Hooked block inserted before/after Post Content block via hooked_block_types filter. 6e12f44
• Hooked block inserted in before/after position inside of Post Content block. Already covered by pre-existing test.
• Hooked block inserted before/after Post Content block contained in other context (e.g. inside a template). 8f53c8b This modifies an existing test case to use the Post Content block as anchor block.

Props @obenland @aaronjorbin @gziolo.

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

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props jorbin, bernhard-reiter, gziolo.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[ockham]

We should probably check what happens if the user modifies a template in the Site Editor that contains a Post Content block that has a block hooked before or after it.

[gziolo]

There are some reported coding style issues. Otherwise, all tests pass including newly added coverage for the advanced use case of using hooked_block_types filter. Nice work!

[Copilot]

Copilot wasn't able to review any files in this pull request.

Files not reviewed (3)

• src/wp-includes/blocks.php: Language not supported
• tests/phpunit/tests/blocks/applyBlockHooksToContent.php: Language not supported
• tests/phpunit/tests/blocks/applyBlockHooksToContentFromPostObject.php: Language not supported

[github-actions]

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 60173
GitHub commit: e800c60

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.