Block Hooks: Store information about known hooked blocks in anchor block metadata

[Bernhard Reiter]

In order to allow injection of hooked blocks into modified layouts (i.e. templates, parts, and patterns) (see #59646), we need a different technique for the frontend to know whether or not to insert a hooked block.

An example scenario is described in https://core.trac.wordpress.org/ticket/59646#comment:2. It is shown there that an attribute of the anchor block is a suitable location to persist that information; the global metadata field is an obvious choice, as it is guaranteed to be available in any possible block.

[Bernhard Reiter]

Re-linking an existing PR doesn't seem to have worked, so here goes: ​https://github.com/WordPress/wordpress-develop/pull/5712

[Bernhard Reiter]

In 57157:

Block Hooks: Store ignored hooked blocks metadata in anchor block.

The biggest tradeoff that was made in the implementation of Block Hooks was that they were limited to layouts (i.e. templates, template parts, and patterns) that didn't have any user modifications (see #59313 for the reason). This changeset is a preparatory step to remove this limitation, so they’ll eventually also work with user-modified layouts.

The crucial problem to solve is how to acknowledge that a user has opted to remove or persist a hooked block, so that the auto-insertion mechanism won't run again and inject an extraneous hooked block on the frontend when none is solicited.

This is achieved by storing all known blocks hooked to a given anchor block in the metadata attribute on that anchor block; specifically in a field called ignoredHookedBlocks inside of the metadata. Hooked blocks are only rendered on the frontend if they're absent from that field; OTOH, they're injected into that field (via the REST API) when first loaded in the editor.

This simple logic guarantees that once a user modifies a given layout, those changes are respected on the frontend; yet if a plugin that includes a hooked block is activated after those modifications have taken place, the hooked block will be rendered on the frontend. This new technique supplants the one previously used (i.e. rendering hooked blocks on the frontend only if a layout doesn't have any modifications) in a rather direct way.

Note that this changeset only introduces the new metadata field and relevant logic; it does not yet enable hooked block insertion into modified layouts. That will be done in a subsequent step (see #59646).

Props gziolo.
Closes #60008.

[Bernhard Reiter]

In 57172:

Block Hooks: Fix @ticket references in tests, add missing ones.

Some tests that were added in [57157] erroneously set their @ticket reference to #59646, rather than #60008.
This changeset rectifies that mistake.

Additionally, it adds ticket references to #60008 to tests that were modified by [57157].

Follow-up to [57157].

See #60008.

[wypitowesyga1962]

i hope this is make it easy to understand it !

Imagine we're giving our anchor block a bit of a makeover, like adding a pocket where it can store notes about its friends, the hooked blocks. We'll call it the "Hooked Block Diary" for our anchor block.

Personality Upgrade: Our anchor block is getting a new feature called the Hooked Block Diary. It's like giving it a memory to remember its buddies.

Accessorizing: We're adding a special section in the anchor block's diary to jot down names of its hooked block friends. Each name gets a checkbox, like a friend list.

Social Check: When the anchor block wants to place a hooked block in its layout, it flips through its diary to see if the friend's name is checked. If it is, the hooked block gets an invite to the party!

Custom Tailoring: We'll tailor the diary's pages to fit nicely with the anchor block's style, making sure it blends seamlessly into its design.

Friendship Testing: We'll do some testing to make sure the anchor block knows when to invite its hooked block buddies and when to leave them out, ensuring smooth interactions.

Keeping a Journal: We'll document all the changes we made, like how we upgraded the anchor block's diary and taught it to be a good host to its hooked block friends.

Fit and Finish: Once everything looks good and works smoothly, we'll integrate these changes into our system and make sure they play well with the rest of the team.

Feedback Session: We'll chat with the other team members to see if they like the anchor block's new diary and make any tweaks based on their suggestions.

Launch Party: Finally, when everything's just right, we'll roll out the updated anchor block with its fancy new diary to the world, ready to host all its hooked block friends with style!