[wp-trac] [WordPress Trac] #59313: Implement Block Hooks

[WordPress Trac]

#59313: Implement Block Hooks
-------------------------------------------------+-------------------------
 Reporter:  Bernhard Reiter                      |       Owner:  Bernhard
                                                 |  Reiter
     Type:  enhancement                          |      Status:  closed
 Priority:  high                                 |   Milestone:  6.4
Component:  Editor                               |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch gutenberg-merge has-unit-  |     Focuses:
  tests commit                                   |
-------------------------------------------------+-------------------------
Changes (by Bernhard Reiter):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"56649" 56649]:
 {{{
 #!CommitTicketReference repository="" revision="56649"
 Blocks: Implement automatic block insertion into Block Hooks.

 Block Hooks allow a third-party block to specify a position relative to a
 given block into which it will then be automatically inserted (e.g. a
 "Like" button block can ask to be inserted after the Post Content block,
 or an eCommerce shopping cart block can ask to be inserted after the
 Navigation block).

 The underlying idea is to provide an extensibility mechanism for Block
 Themes, in analogy to WordPress'
 [https://developer.wordpress.org/plugins/hooks/ Hooks] concept that has
 allowed extending Classic Themes through filters and actions.

 The two core tenets for Block Hooks are:

 1. Insertion into the frontend should happen right after a plugin
 containing a hooked block is activated (i.e. the user isn't required to
 insert the block manually in the editor first); similarly, disabling the
 plugin should remove the hooked block from the frontend.
 2. The user has the ultimate power to customize that automatic insertion:
 The hooked block is also visible in the editor, and the user's decision to
 persist, dismiss (i.e. remove), customize, or move it will be respected
 (and reflected on the frontend).

 To account for both tenets, the **tradeoff** was made to limit automatic
 block insertion to unmodified templates (and template parts,
 respectively). The reason for this is that the simplest way of storing the
 information whether a block has been persisted to (or dismissed from) a
 given template (or part) is right in the template markup.

 To accommodate for that tradeoff,
 [https://github.com/WordPress/gutenberg/pull/52969 UI controls (toggles)]
 are being added to increase visibility of hooked blocks, and to allow for
 their later insertion into templates (or parts) that already have been
 modified by the user.

 For hooked blocks to appear both in the frontend and in the editor (see
 tenet number 2), they need to be inserted into both the frontend markup
 and the REST API (templates and patterns endpoints) equally. As a
 consequence, this means that automatic insertion couldn't (only) be
 implemented at block ''render'' stage, as for the editor, the
 ''serialized'' (but ''unrendered'') markup needs to be modified.

 Furthermore, hooked blocks also have to be inserted into block patterns.
 Since practically no filters exist for the patterns registry, this has to
 be done in the registry's `get_registered` and `get_all_registered`
 methods.

 Props gziolo.
 Fixes #59313.
 }}}

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