[wp-trac] [WordPress Trac] #61078: Block Hooks: Consider introducing a dedicated endpoint

[WordPress Trac]

#61078: Block Hooks: Consider introducing a dedicated endpoint
-----------------------------+----------------------------
 Reporter:  Bernhard Reiter  |      Owner:  (none)
     Type:  enhancement      |     Status:  new
 Priority:  normal           |  Milestone:  Future Release
Component:  General          |    Version:
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+----------------------------
 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61078>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform