[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:  Future Release
Component:  General          |     Version:  5.0
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+-----------------------------

Comment (by dougwollison):

 Replying to [comment:1 johnbillion]:
 > I think this is the intention of the `block_parser_class` filter a few
 lines above. If you need to heavily customise the block parsing and result
 then you can use this filter to specify your own class that does so. If
 you extend the `WP_Block_Parser` class then you can reuse its methods.
 >
 > Does that suit your needs @dougwollison or do you think there's still
 value in having a filter applied to the parsed result?

 That's my current solution, and it works fine for my use case with a
 custom-tailored theme, but I'm worried this isn't very extensible should a
 3rd party plugin need the same capabilities. If my code and some 3rd party
 plugin are replacing the parser class, then only one of ours will be used,
 depending on what priority our filters are.

 I guess it could work as-if is if both implementations use a higher-order-
 component style aproach, instantiating the previous class inside another
 one to wrap/proxy the parse() method. Even then, that feels like it
 overcomplicates the normally simply act of adding a hook to filter an
 array. I think there's some potential messiness involved in having 2+
 differently named filters that all do the same thing in such a scenario,
 but I'm already overthinking it.

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