[wp-trac] [WordPress Trac] #60756: Block Hooks: Toggle (re-)inserts hooked block in wrong position (if added by filter)

[WordPress Trac]

#60756: Block Hooks: Toggle (re-)inserts hooked block in wrong position (if added
by filter)
-----------------------------+------------------------------
 Reporter:  Bernhard Reiter  |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------------------

Comment (by Bernhard Reiter):

 In order to make the toggle work reliably for hooked blocks injected via a
 filter, we'll have to provide the missing information (i.e. their relative
 positions) to the client. There are (at least) two ways that this could be
 done:

 == 1. Include the relative position in the `ignoredHookedBlocks` metadata,
 i.e. change the format to something like

 {{{
 <!-- wp:navigation
 {"metadata":{"ignoredHookedBlocks":{{"core/loginout":"after,"mycommerce
 /shopping-cart":"after"}}} -->
 }}}

 or

 {{{
 <!-- wp:navigation
 {"metadata":{"ignoredHookedBlocks":{"after":["core/loginout","mycommerce
 /shopping-cart"]}}} -->
 }}}


 This would amount to a format change for the `ignoredHookedBlocks`
 metadata attribute, which will require some additional
 fallback/compatibility logic in case the attribute was set using the "old"
 format.

 == 2. Add an endpoint (or a field) to list hooked blocks per anchor block
 in a given context

 It's not possible to simply extend the `hooked-blocks` endpoint to this
 end, as the set of hooked blocks for a given anchor block might vary
 depending on context (e.g. a "Like Button" block could be inserted by a
 filter below the Post Content block only when encountered within the
 `single` template).

 Instead, a new endpoint is required that allows the client to specify the
 context. This was discussed in #59574 and explored in this
 [https://github.com/WordPress/gutenberg/pull/58622 Gutenberg PR] (which
 was also filed as a solution for a separate issue). Ultimately, it was
 abandoned as overly complex.

 A variation of this solution would be to add a `hooked-blocks` ''field''
 to a number of existing endpoints (e.g. the templates or navigation ones);
 this would be context-dependent by definition. The downside is that it'd
 negatively impact separation of concerns for those controllers (requiring
 adding the same kind of logic and overhead to determine hooked blocks to
 all affected controllers). It might also translate poorly to the required
 state tree infrastructure (i.e. selectors etc.) on the client side.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60756#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform