[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