[wp-trac] [WordPress Trac] #60852: Block Templates: Make conditional tags work when processing content for REST API

[WordPress Trac]

#60852: Block Templates: Make conditional tags work when processing content for
REST API
-----------------------------+----------------------------
 Reporter:  Bernhard Reiter  |      Owner:  (none)
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Future Release
Component:  General          |    Version:
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+----------------------------
 @ndiego brought up to me that it might be desirable to make
 [https://developer.wordpress.org/themes/basics/conditional-tags/
 conditional tags] such as
 [https://developer.wordpress.org/reference/functions/is_singular/
 `is_singlular`] or
 [https://developer.wordpress.org/reference/functions/is_user_logged_in/
 `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
 [https://developer.wordpress.org/reference/functions/get_block_template/
 `get_block_template()`] and
 [https://developer.wordpress.org/reference/functions/get_block_templates/
 `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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60852>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform