Block Templates: Make conditional tags work when processing content for REST API

[Bernhard Reiter]

@ndiego brought up to me that it might be desirable to make ​conditional tags such as ​`is_singlular` or ​`is_user_logged_in` work in Block Hook related filters ([hooked_block_types](​https://developer.wordpress.org/reference/hooks/hooked_block_types/), hooked_block, hooked_block_{$hooked_block_type}).

These conditional tags will probably work on the frontend; the problem is that they won't work in the editor, which is why we it is not recommended to use them for hooked blocks, as they would produce a mismatch between what's in on the frontend and what's in the editor (e.g. a block that's conditionally hooked based on the return value of is_singular might correctly show up on the frontend, but not in the editor when rendering the single posts template).

To fix this, we'd likely need to set the relevant information during processing of a block template's content that precedes sending it to the client via the REST API (i.e. probably somewhere inside of ​`get_block_template()` and ​`get_block_templates()` or inside the functions that they call). In theory, the relevant information should be available, as the server knows which template(s) to respond with to a given request, and they are given as an argument ($id or $query, respectively) to the aforementioned functions.

However, implementing the fix is probably still non-trivial for Template Hierarchy related conditional tags, as they all return values based on the global $wp_query object; we'd thus need to set properties on that global during block template processing, or extend all Template Hierarchy related conditional tags to account for this scenario.

I'm not quite sure if this would benefit any code other than Block Hooks filters. Dynamic Blocks can largely use conditional tags already, since their PHP code is typically only run on the frontend, but not for populating the editor.

[Bernhard Reiter]

Note that getting ​`is_singular()` to work would allow users to inject a hooked block only when the current template is for a custom post type (e.g. if ( is_singular( 'book' ) ) { /* ... */ }), which seems to be a recurring request.

[Bernhard Reiter]

I gave this some more thought, and I'm not sure it's possible to implement this in a way that's compatible with the Site Editor.

I think there's a problem with using a conditional template tag (e.g. is_single( 'my-post' ) to check that the post with slug my-post is currently rendered) in a template that's less granular than that template tag (e.g. the Single Posts template).

Other -- more hypothetical -- examples could include a is_tag() (to check for a Tag Archives page), when used in a generic Archives template (which AFAICT the Site Editor doesn't currently support -- but might eventually). Refer to the ​Template Hierarchy for other possible scenarios.

The problem is that we have only have insufficient context available when editing a template in the Site Editor that (potentially) includes hooked blocks with more fine-grained criteria; as a consequence, we can't know whether or not to show a hooked block that's e.g. only injected into a single post with my-post as its slug, when we're currently editing the generic Single Posts template (which applies to all single posts, regardless of their slug).

[Bernhard Reiter]

Based on my recent comment, I'm afraid it doesn't seem likely that we'll be able to solve this problem.