First step towards hybrid themes: Fallback to PHP templates#29026
First step towards hybrid themes: Fallback to PHP templates#29026draganescu merged 10 commits intotrunkfrom
Conversation
|
Size Change: 0 B Total Size: 1.39 MB ℹ️ View Unchanged
|
|
I have tested this by adding a block-templates folder inside Twenty Seventeen. I was also able to: I added 404.php and archive.php files to a full site editing theme. I added a category.php file and this was used correctly for category archives. I then tried creating a new 404 template in the site editor. |
|
@carolinan for custom 404 templates there is an unrelated issue with the slugs which prevents numeric values as a slug. If you check the slug for the created 404 template you should see it's |
|
In Appearance > Templates there is no 404 template saved for the FSE theme. There is a saved 404 from Twenty Seventeen 🤔 |
|
What's blocking this? Do you think it's ready to be tried? Do we want to add some documentation first? Maybe to this page https://developer.wordpress.org/block-editor/how-to-guides/block-based-theme/ |
draganescu
left a comment
There was a problem hiding this comment.
@youknowriad nothing is blocking us from landing this and seeing how it works.
|
Some documentation for this would be good though |
The block template resolution algorithm is quite complex, as it has to cover quite a lot of different possible cases resulting from various combinations of - WP's "old" template hierarchy (including custom page templates, and child themes) - block templates. Things become especially complex when there are e.g. "oldschool" PHP templates with higher specificity than the available block templates; or when a child theme has a PHP template with equal specificity as the parent theme's corresponding block template. For more discussion on this, see #31399. Examples of previous iterations that sought to refine the algorithms' behavior include #29026, #30599, #31123, and #31336. This PR's goal is to eventually cover all of those cases.
This is the 1st step towards hybrid themes - see #29024 for details.
Adds a backwards-compatibility layer to the FSE templating system, allowing themes to fallback to legacy (.php) templates depending on the specificity/priority of php templates & block templates.
Important note: This PR only addresses the frontend without changing anything on the editor side. It is not meant to be a complete implementation, but it is a good way to start thinking about what comes next.
Example:
Loading a page with title "About" and ID = 1725 will try to load templates in the following order:
page-about.phppage-1725.phppage.phpsingular.phpindex.phpIf it doesn't find the 1st one then it will try the 2nd one and so on. The same hierarchy & priorities are used for block templates, however there is a disconnect and FSE will be either on, or off. If FSE is on, then it will look at the block templates only. If FSE is off, it will look at the PHP templates only.
With this PR, if a theme has an
indexblock-template, it will be used as a fallback. If the theme has apage.phpfile, it will be used for pages. If the user creates apageblock-template, it will override the php file. If they create apage-1725.phpfile in their theme, it will override the block-template.This allows for more granular control and will eventually allow themes to start migrating parts of their templates.
How has this been tested?
Tested by creating block templates in an FSE theme and then PHP templates, making sure that block templates override php templates on the same level (
pageblock-template overridespage.phpbut notpage-1725.php)Backwards-compatibility:
Nothing changes for existing FSE themes. This is not a complete solution for hybrid themes, but it is the 1st step to allow further improvements and doesn't break backwards-compatibility with anything we've done so far.
Checklist:
I've included developer documentation if appropriate.I've updated all React Native files affected by any refactorings/renamings in this PR.