Template Part block: Use _build_block_template_result_from_post

[ockham]

What?

In the Template Part block's render method, use _build_block_template_result_from_post() to build a WP_Block_Template object instead of doing the same "post-processing" in a manual way.

Why?

In WordPress/wordpress-develop#5523, we're extending Block Hooks, which previously only worked for unmodified templates, template parts, and patterns to also work with modified ones. To that end, we're adding logic to _build_block_template_result_from_post() to conditionally insert hooked blocks, which is generally used to build a WP_Block_Template object from a template or pattern DB post object for the purpose of rendering it on the frontend or viewing it in the editor.

However, the Template Part block's render method isn't currently using that method; instead, it's using some lower-level "post-processing" of the DB post object. As a consequence, hooked blocks won't be inserted into Template Part blocks if the template part they're rendering has user modifications, unless the Template Part block code is updated to accommodate for them.

How?

There are two options to make sure that hooked blocks are also inserted into modified template parts:

• Duplicate the insertion logic into the Template Part block's render method, or
• Use _build_block_template_result_from_post in the Template Part block's render method.

This PR implements the latter, which has the advantage that it won't duplicate hooked blocks insertion (in the worst case scenario resulting in the same block being inserted twice, if not properly guarded by conditionals). Furthermore, it makes it easier to implement hooked blocks insertion separately (in _build_block_template_result_from_post in Core, or alternatively via a filter in Gutenberg) and will simply start working once that has been implemented.

Note that this PR is somewhat comparable to #52892, which did something similar for the _un_modified template part code path, using the get_block_file_template function.

Testing Instructions

Verify that template parts are still working as before. Check both the frontend and the editor.

Follow-up

In the long run, it would probably be best if the Template Part block used a high-level function such as get_block_template to fetch the template part it's supposed to render from either the DB or the theme file instead of duplicating that logic (in order to avoid e.g. the logic getting out of sync). The major obstacle seems to be the presence of the three actions fired by the Template Part block during rendering, introduced by #36884. However, we might be able to accommodate for that by moving those actions over to the respective helper functions in block-template-utils.php.

In order for WordPress/wordpress-develop#5523 not to get blocked, I'd like to tackle that separately, though. I'll file an issue for that once this PR is merged.

---

h/t @artemiomorales who discovered that we need to update the Template Part block to accommodate for hooked blocks insertion during a pair programming session today.

[gziolo]

Code changes look good and I can confirm that the modified template part works correctly both in the site editor and on the front end.

In the long run, it would probably be best if the Template Part block used a high-level function such as get_block_template to fetch the template part it's supposed to render from either the DB or the theme file instead of duplicating that logic (in order to avoid e.g. the logic getting out of sync). The major obstacle seems to be the presence of the three actions fired by the Template Part block during rendering, introduced by #36884. However, we might be able to accommodate for that by moving those actions over to the respective helper functions in block-template-utils.php.

That's a spot-on discovery. In particular, due to the fact that get_block_template uses internally another two additional filters pre_get_block_template and get_block_template which allows extenders to modify the template. The actions used in the Template Part block seem to be very specific, so maybe the only change we need to apply would be using get_block_template instead of the lower-level methods that the function abstracts.

There seems to be some subtle differences in how get_block_template works in comparison with the Template part block around WP_Query. In particular, the logic used in the block expects only templates with the post_status set to publish and it disables lazy_load_term_meta flag when passing params to the query.

[ockham]

Cherry-picked to the release/17.0 branch in 4dfbd25.

[ockham]

In the long run, it would probably be best if the Template Part block used a high-level function such as get_block_template to fetch the template part it's supposed to render from either the DB or the theme file instead of duplicating that logic (in order to avoid e.g. the logic getting out of sync).

Filed #55956.