[wp-trac] [WordPress Trac] #59646: Block Hooks: Enable for user-modified templates/parts/patterns

[WordPress Trac]

#59646: Block Hooks: Enable for user-modified templates/parts/patterns
-----------------------------+------------------------------
 Reporter:  Bernhard Reiter  |       Owner:  Bernhard Reiter
     Type:  enhancement      |      Status:  assigned
 Priority:  normal           |   Milestone:  6.5
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------------------

Comment (by Bernhard Reiter):

 Per discussion with @matveb, the most straight-forward mechanism to
 achieve this is probably an extra attribute on the anchor block ''(not on
 the hooked block!'').

 It seems that we might not even need to store specifically ''whether'' a
 block was persisted or dismissed; it might be enough to simply store the
 information that an anchor block has had a dependent hooked block
 inserted. (Think of this as somehow mimicking the current approach of
 unmodified vs user-modified templates.)

 The syntax could be as follows:

 {{{
 <!-- wp:navigation {"blockHooks":{"after":["mycommerce/mini-cart"]}} -->
 }}}

 Here’s an example scenario:
 - Let’s assume we start with a "vanilla" theme, i.e. no user
 modifications.
 - We activate an eCommerce plugin that inserts a shopping cart block after
 the Navigation block. ''We want this to show immediately on the
 frontend.''
 - As the frontend is being rendered, we encounter a Navigation block. We
 check its `blockHooks` attribute to see if it contains the shopping cart
 block. It doesn't, so we proceed to inject the shopping cart block after
 the Navigation block.
 - The user opens the Header template that contains the Navigation block
 (and shopping cart block) in the editor. The templates REST API
 controller, upon encountering the Navigation block, adds a `blockHooks`
 attribute that's set to `{"after":["mycommerce/mini-cart"]}`.
 - The user modifies the header block; they either store it with the
 shopping cart block still in place, or remove it.
 - The next time the frontend is rendered, we encounter the `blockHooks`
 attribute on the Navigation block. Since it now contains the shopping cart
 block, we refrain from automatically injecting the shopping cart block,
 thus preventing extraneous insertion.

 - The user now activates a plugin that inserts a Login/out button block
 after the Navigation block (i.e. into the Header template that already has
 some user modifications).
 - Since the Navigation block's `blockHooks` attribute doesn't contain the
 Login/out button, it is rendered on the frontend.
 - If the user opens the Header template in the editor, the shopping cart
 block is added to the Navigation block's `blockHooks` attribute. This
 ensures that any further user modifications to the template will be
 reflected on the frontend; specifically, no extraneous instance of the
 Login/out block will be auto-inserted.

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