Expand get_post's $filter parameter to allow a blocks as a return shape

[gziolo]

Part of "PHP APIs Overview" in Gutenberg: ​https://github.com/WordPress/gutenberg/issues/8352.

get_posts accepts three arguments at the moment:
​https://developer.wordpress.org/reference/functions/get_post/#parameters

The proposal is to expand the $filter parameter to accept also blocks as an option:

(string) (Optional) Type of filter to apply. Accepts 'raw', 'edit', 'db', or 'display'.
Default value: 'raw'

The implementation details are still to be defined but it would probably require a ​`parse_block` function call.

[matveb]

To expand a bit on the rationale: this aims to make consuming content in block format, if so desired, better supported at a lower level in WordPress.

[TimothyBlynJacobs]

This doesn't seem right to me. The purpose of filter is to apply certain transformations to the WP_Post properties. So in this case, blocks would have to be a proxy for one of the other filter values for the other fields. Then if you wanted blocks, you'd lose the ability to set a desired filter for the other fields.

Instead, it seems like we can introduce a blocks property on WP_Post like ancestors and lazily parse_blocks when called.

[gziolo]

Instead, it seems like we can introduce a blocks property on WP_Post like ancestors and lazily parse_blocks when called.

I was only moving the existing issue to Trac from Gutenberg so I don't have strong opinions here. The solution you proposed sounds good as well. @matveb should know better how to proceed.

[gziolo]

@jonsurrell opened a new ticket #62653, that tracks progress on adding CSS selectors support to HTML API. That is a step towards having an efficient way to extract on the server sourced attributes from HTML saved for blocks.