Request: filter for parse_blocks() result

[dougwollison]

I'd like to be able to access and if needed modify the parsed blocks for a page before it's rendered on the frontend. My particular use case invovles ensuring pages have a certain structure with some exceptions that can't reliably be address by simply using hasBlockType or filtering an individual block's data.

My current solution is to hook into the block_parser_class filter and return my own extension that simply filters the ouptut of WP_Block_Parser:parse(). It works great but it's a bit of a round-about way.

I think for sanity/caching friendliness it should be added in the return logic of parse_blocks().

[dougwollison]

Proposed 'parse_blocks' filter on parse_blocks() return value.

[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?

[dougwollison]

Replying to 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.