Block: Give `traverse_and_serialize_block(s)`' post-callback access to block instance

[Bernhard Reiter]

Both the $pre_ and $post_callback functions that are given as arguments to traverse_and_serialize_block(s) receive a reference to the current block as their first argument. However, while any changes that the "pre" callback makes to the block are actually respected during serialization, the same isn't true for the "post" callback: Any changes that it makes are only applied after the block has already been serialized. For applications like #59646, we probably want to change that.

Both the $pre_ and $post_callback functions that are given as arguments to traverse_and_serialize_block(s) receive a reference to the current block as its first argument. However, while any changes that the "pre" callback makes to the block are actually respected during serialization, the same isn't true for the "post" callback: Any changes that it makes are only applied after the block has already been serialized. For applications like #59412, we probably want to change that.

Trac ticket: https://core.trac.wordpress.org/ticket/59669

[Bernhard Reiter]

In 56970:

Blocks: During traversal, allow post callback to modify block.

Both the $pre_callback and $post_callback functions that are given as arguments to traverse_and_serialize_block(s) receive a reference to the current block as their first argument. However, while any changes that the "pre" callback makes to the block are reflected by the serialized markup, the same wasn't true for the "post" callback: Any changes that it made were only applied after the block had already been serialized.

This commit changes the behavior such that $post_callback's changes to the current block are also reflected in the serialized markup.

See #59646.
Props gziolo.
Fixes #59669.

Committed to Core trunk in https://core.trac.wordpress.org/changeset/56970.

[Bernhard Reiter]

Re-opening for potential inclusion in 6.4. Requesting another committer's feedback/approval :)

I forgot to backport this to the 6.4 branch after committing to trunk. It might not be a "huge" bug (doesn't seem to affect Block Hooks in Core), but it might pose problems for third parties that want to use traverse_and_serialize_block(s) with a $post_callback that modifies the current block (as that won't work, without the fix). One use case could be the Gutenberg plugin, if we want to e.g. implement something like #59646 there first.

FWIW, traverse_and_serialize_block(s) was only introduced during the 6.4 cycle, so I believe the fix qualifies for backporting during RC.

[Bernhard Reiter]

Looks like the Type was set to enhancement. I've now changed that to defect (bug) because it actually is one :)

[hellofromTonya]

it might pose problems for third parties that want to use traverse_and_serialize_block(s) with a $post_callback that modifies the current block (as that won't work, without the fix).

Good catch @bernhard-reiter flagging this fix.

As the bug (and functions) was(were) introduced in 6.4, [56970] LGTM for backport to the 6.4 branch.

[Bernhard Reiter]

In 57043:

Blocks: During traversal, allow post callback to modify block.

Both the $pre_callback and $post_callback functions that are given as arguments to traverse_and_serialize_block(s) receive a reference to the current block as their first argument. However, while any changes that the "pre" callback makes to the block are reflected by the serialized markup, the same wasn't true for the "post" callback: Any changes that it made were only applied after the block had already been serialized.

This commit changes the behavior such that $post_callback's changes to the current block are also reflected in the serialized markup.

Reviewed by hellofromTonya.
Merges [56970] to the 6.4 branch.

See #59646.
Props gziolo.
Fixes #59669.

Backported to the 6.4 branch in https://core.trac.wordpress.org/changeset/57043.

[azaozz]

Just curious, why callbacks (as function params) and not filters? The (basic) difference between callbacks as params and filters is that with filters many plugins can apply callbacks at the same time, i.e. work in sync. With separate callbacks all plugins will have to rerun the same functions again and again.

Looking ast gthe code here, these callbacks seem like an anti-pattern in WP?

[hellofromTonya]

Looping back here. Today, there was a ​discussion in Make/Core slack about @azaozz (and my) concerns.

tl;dr

• The new functionality and functions are low-level and intended for internal Core-only usage.
• Architectural changes will be discussed in a separate ticket for a future release, as it's too late in the 6.4 cycle for new filters or architectural redesign to encapsulate this internal functionality.
• #59783 is now open to better document the intent of Core-only.