[wp-trac] [WordPress Trac] #49442: Request: filter for parse_blocks() result

[WordPress Trac]

#49442: Request: filter for parse_blocks() result
---------------------------------------+---------------------
 Reporter:  dougwollison               |       Owner:  (none)
     Type:  feature request            |      Status:  new
 Priority:  normal                     |   Milestone:  6.9
Component:  General                    |     Version:  5.0
 Severity:  normal                     |  Resolution:
 Keywords:  has-patch needs-test-info  |     Focuses:
---------------------------------------+---------------------

Comment (by dmsnell):

 What @johnbillion said above is true: the class filter was added to allow
 folks to perform various kinds of parsing here. I think we are inviting
 trouble by encouraging filtering of `parse_blocks()` results, but also
 most people hopefully won’t be using the filter, so 🤷‍♂️

 Here’s one thing I think would be important for this work: if we’re adding
 the filter, the current proposed docblock is under-helpful. For one, the
 type of the blocks is `array`, but we know that it passes a tree of block
 objects, and it would be incredibly helpful to people to show that in some
 examples inside the comment. The top-level of the tree is a list of
 blocks, may be empty, and the tree is recursive.

 If we add this filter the way it is, I think it tends to give an
 impression that the result is a linear and flat list of blocks, which it
 is not. This is the trouble in exposing the filter here: it takes
 thoughtful intention to traverse the output properly, something not
 required when using `pre_render_block`, `render_block`,
 `render_block_data`, and `render_block_context` filters.

 > It works great but it's a bit of a round-about way.

 If I can ask, @dougwollison — if it works great, and you found the
 intended filter to provide this extensibility, in what ways does it feel
 “round-about” to you?

 > In support, we need look no further than the overreliance of the
 render_block/render_block_data hook for Block Supports and the resulting
 headaches when trying to work with that data in PHP

 @justlevine do you mind making some of these observations concrete? What
 is the over-reliance you are referring to? What are the headaches?

 ----

 One more-recent development is the introduction of
 [https://developer.wordpress.org/reference/functions/traverse_and_serialize_blocks/
 traverse_and_serialize_blocks()], which gives more direct control over the
 block tree as a filter. I know also that one can take the parsed block
 tree and modify it at will as the parsed data structure (for example,
 ensuring post structure is not necessarily a parsing-stage concern). Is it
 right to assume that by “ensure” you mean you are modifying the structure
 when something is missing or otherwise amiss?

 It would be useful to know which aspects of modifying the parsed block
 tree are inconvenient leading to the desire to filter the output. Are you
 also wanting to ensure that every single time block content is parsed that
 the filter runs? On parsing widgets, on parsing excerpts, in processing
 post comments, Woo products, etc…?

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