[wp-trac] [WordPress Trac] #59776: Block Hooks: Allow traversal callbacks to modify parent block

WordPress Trac noreply at wordpress.org
Tue Oct 31 16:33:18 UTC 2023


#59776: Block Hooks: Allow traversal callbacks to modify parent block
-----------------------------+----------------------
 Reporter:  Bernhard Reiter  |      Owner:  (none)
     Type:  enhancement      |     Status:  assigned
 Priority:  normal           |  Milestone:  6.4
Component:  General          |    Version:
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+----------------------
 ''tl;dr:'' In 6.5, we'll need arguments to two functions introduced during
 the 6.4 cycle to become references. Since that can be deemed a back-compat
 breaking change, I'm suggesting to make that change already.

 ----

 The callbacks returned by `make_before_block_visitor` and
 `make_after_block_visitor`, respectively (which are passed as arguments to
 `traverse_and_serialize_block(s)`) currently accept three arguments, all
 of which are block arrays (i.e. with properties `blockName`, `attrs`,
 etc.):
 - A ''reference'' to the block they're currently visiting, `&$block`;
 - the block's `$parent_block`; and
 - the `$prev`ious block (for `make_before_block_visitor`), or the `$next`
 block (for `make_after_block_visitor`), respectively.

 Those arguments are passed to the "block visitor" callbacks by
 `traverse_and_serialize_block(s)` during traversal. The block that the
 callback is currently visiting is passed ''by reference'' to allow
 modifying it, which is e.g. used to inject the `theme` attribute into
 Template Part blocks.

 One major limitation with Block Hooks is that they currently only work
 with templates, parts, and patterns that ''don't have any user
 modifications'' (i.e. that come straight from the corresponding theme
 files, rather than the DB). For WP 6.5, we're planning to change that to
 also make Block Hooks work for templates, parts, and patterns that ''do''
 have user modifications: #59646.

 The way we'll make this work is by storing an attribute on the "anchor"
 block. This is currently being developed in https://github.com/WordPress
 /wordpress-develop/pull/5523.

 While working on that PR, I noticed that that means that we'll also need
 to allow the aforementioned callbacks to modify not only the currently
 visited `$block`, but also the `$parent_block` -- i.e. to pass the latter
 argument by reference, too. This is consistent with the requirement of
 adding an attribute to an anchor block, as it's not only the currently
 visited block that can serve as an anchor block (in the case of `before`
 or `after` sibling insertion), but also its parent (for `first_child` and
 `last_child` insertion).

 Per [https://wordpress.slack.com/archives/C02RQBWTW/p1698765741579409
 discussion] with @hellofromtonya, changing the `$parent_block` argument to
 become a reference can be considered a backwards-compatibility breaking
 change. I'm thus suggesting to make that change already as part of 6.4,
 which is the cycle where the relevant functions were first introduced.
 This should have no impact on existing code, since nothing currently
 relies on `$parent_block` remaining unmodified by the respective callback,
 nor is anything currently modifying that argument.

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


More information about the wp-trac mailing list