WordPress.org

Make WordPress Core

Opened 8 weeks ago

Last modified 8 weeks ago

#49442 new feature request

Request: filter for parse_blocks() result

Reported by: dougwollison Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 5.0
Component: General Keywords:
Focuses: Cc:

Description

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().

Attachments (1)

49442.diff (586 bytes) - added by dougwollison 8 weeks ago.
Proposed 'parse_blocks' filter on parse_blocks() return value.

Download all attachments as: .zip

Change History (3)

@dougwollison
8 weeks ago

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

#1 follow-up: @johnbillion
8 weeks ago

  • Milestone changed from Awaiting Review to Future Release
  • Version changed from trunk to 5.0

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?

Last edited 8 weeks ago by johnbillion (previous) (diff)

#2 in reply to: ↑ 1 @dougwollison
8 weeks ago

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.

Note: See TracTickets for help on using tickets.