[wp-trac] [WordPress Trac] #59315: Merge consideration of block-templates with classic template hierarchy

[WordPress Trac]

#59315: Merge consideration of block-templates with classic template hierarchy
--------------------------+-----------------------------
 Reporter:  joemcgill     |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Themes        |    Version:
 Severity:  normal        |   Keywords:
  Focuses:  performance   |
--------------------------+-----------------------------
 For block themes, WordPress will first attempt to locate the appropriate
 PHP template in the theme for the request before considering a block
 template in `get_query_template`. However, any block template that is
 found at an equal or higher priority takes precedence over the PHP
 templates. This means that block themes perform several unnecessary
 `file_exists` checks to look for a PHP template, when a block template is
 the desired result.

 == Design considerations
 To fix this, the logic from `locate_block_template` that attempts to find
 an appropriate block template would need to be integrated into the foreach
 loop in `locate_template` so that the appropriate block template would be
 found prior to searching for a PHP template, in `get_query_template` if
 `current_theme_supports( 'block-templates' )` returns true. Alternatively,
 the order of those two functions could be reversed so that
 locate_block_template is called first if the theme supports block
 templates.

 == Benefits
 The benefit to this approach is that wasteful file operations would not be
 called if a more appropriate block template is available, speeding up
 template rendering. For example, when a block theme responds to a standard
 single post, `locate_template` will end up calling `file_exists` 9 times
 before even considering whether an appropriate block template exists.

 == Caveats and risks
 While `file_exists` checks have been shown to have a noticeable
 performance cost in lab profiling, the results of these calls are often
 cached internally by PHP (see:
 https://www.php.net/manual/en/function.clearstatcache.php), so the
 performance impact in the field may be negligible.

 Additionally, there are backwards compatibility considerations that will
 need to be accounted for with this implementation, as plugins are already
 making use of direct calls to `locate_template` and
 `locate_block_template` independently of how they’re used in
 `get_query_template`.

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