[wp-trac] [WordPress Trac] #54515: Block template themes: Parent theme block template takes precedence over child theme PHP template

[WordPress Trac]

#54515: Block template themes: Parent theme block template takes precedence over
child theme PHP template
-----------------------------+------------------------------
 Reporter:  Bernhard Reiter  |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Editor           |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------------------

Comment (by Bernhard Reiter):

 I’ve looked a bit into the problem, and I’ll try to describe my findings
 here.

 The unit test is for `locate_block_template( $template, $type, array
 $templates )`. It is called after „classic“ (i.e. pre-blocks, PHP theme)
 WP template resolution is run. If the latter has found a potential
 candidate template (PHP) file, its path is passed as the `$template`
 argument to `locate_block_template`. The other two arguments contain the
 template `$type` (e.g. `page`, `category`, `single`, etc), and the
 template candidate hierarchy (e.g. `page-home.php`, `page-123.php`,
 `page.php` — see [https://developer.wordpress.org/themes/basics/template-
 hierarchy/ template hierarchy documentation]).

 `locate_block_template()` then invokes `resolve_block_template( $type,
 $templates )`, whose job it is to return the one block template file
 that's the best match for the given template hierarchy (if any). To do so,
 it tries to be clever: If we did get a (PHP) template candidate in
 `$template`, then it only passes the part of the `$templates` hierarchy
 array up to that specificity. E.g. if our theme has a `page-123.php`
 template, we already know that we're not looking for any block templates
 with lesser specificity, so we shorten `$templates` to only look for
 `page-home.html` and `page-123.html` (but not `page.html`).

 `resolve_block_template()` then creates a `$query` based on these
 criteria, and calls `get_block_templates( $query )`, whose job it is to
 find matching block templates, both in the DB (as user-created
 `wp_template` CPTs), and as HTML files in the current theme.

 In order to find the latter, it uses `_get_block_templates_files(
 $template_type )` (the argument being either `wp_template` or
 `wp_template_part`). This function will fetch all block template files of
 a given theme; and, if the theme is a child theme, also of its parent!

 We then go back up the stack track (and through a few extra steps of
 processing), ending up with candidate block templates from both the theme
 and its parent (if any), of equal or higher specificity of the PHP
 fallback template.

 ---

 Due to the current architecture (function signatures, separation of
 tasks), it's not obvious where to check if a candidate block theme is
 coming from the current theme's parent, and if the fallback PHP theme has
 the same specificity, but should be preferred since it's coming from the
 child theme.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54515#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform