Make WordPress Core

Opened 8 weeks ago

Last modified 8 weeks ago

#61078 new enhancement

Block Hooks: Consider introducing a dedicated endpoint

Reported by: bernhard-reiter's profile Bernhard Reiter Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: General Keywords:
Focuses: Cc:

Description

It might be worth revisiting a dedicated endpoint for Block Hooks (as originally discussed in #59574 and attempted in https://github.com/WordPress/gutenberg/pull/58622). Such an endpoint would accept an anchor block (and optionally a context) as its arguments, and return the list of hooked blocks in each relative position for that anchor block. Specifically, its syntax would likely be something like this:

/wp/v2/hooked-blocks/core/post-content?entity=template&id=twentytwentythree/single
/wp/v2/hooked-blocks/core/page-list?entity=navigation&id=4

(Which would return a list of all blocks hooked to the Post Content if located inside of the TT3 Theme's Single Posts template, or to the Page List block if located inside the Navigation menu with ID number 4.)

So far, we've managed to avoid the need for an extra endpoint, and instead used the actual markup -- in particular the metadata.ignoredHookedBlocks attribute, plus the presence of hooked blocks in their expected position(s) -- to infer e.g. the state of the Block Hooks toggle. However, we're starting to push the limits of what's possible with that information. For example, in order to fix #60756, we'd need to change the format of ignoredHookedBlocks to include the relative position.

Change History (2)

#1 @Bernhard Reiter
8 weeks ago

A dedicated endpoint would allow us to:

  • Remove ignoredHookedBlocks injection on DB write (since we could instead inject the attribute into any newly added blocks in the editor) (introduced in #60506, further refined in #60671 and #60754).
  • Avoid storing the relative position in ignoredHookedBlocks in order to fix toggle insertion (#60756).
Last edited 8 weeks ago by Bernhard Reiter (previous) (diff)

#2 @Bernhard Reiter
8 weeks ago

In order to better integrate the endpoint with where it'd likely be used (i.e. chiefly in the Site Editor) and to reduce the number of HTTP requests, @gziolo has suggested to embed it in e.g. the Templates endpoint.

Last edited 8 weeks ago by Bernhard Reiter (previous) (diff)
Note: See TracTickets for help on using tickets.