#53176 closed task (blessed) (fixed)
Block Editor: Backport the FSE infrastructure required to make the template editor work for classic themes.
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 5.8 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Editor | Keywords: | has-patch has-unit-tests |
Focuses: | Cc: |
Description
This includes:
- The Template CPT.
- The Template REST API endpoint and controller.
- The Template loader logic that allows loading custom block templates assigned to pages.
- A change to the list of available templates for pages to include saved custom block templates.
The template-part related code can be left out of Core for WordPress 5.8.
Change History (21)
#2
@
4 years ago
In Gutenberg, we're currently hooking into all the `{type}_template` filters.
The overall sequence in Core looks about like this:
- WordPress detects that the current route maps to an entity of type
{type}
(e.g. apage
orcategory
). - It calls
get_{type}_template()
(e.g.get_page_template()
), which in turn passes an array of candidate template slugs (with.php
file extension) to `get_query_template()`. - Internally,
get_query_template()
calls, in order:- the `type_template_hiearchy` filter, which can modify the template candidate list.
- `locate_template`, to find the template file with the highest specificity that matches the candidate list.
- the `type_template` filter, which can modify that result (the path to the template file).
Gutenberg only hooks into the latter filter, to "redirect" WordPress to its special template-canvas.php
template file, which will render the best matching block template (if any). The reason for this is that WP expects a (PHP) file _path_ -- and in GB, we can't guarantee that there's always a template file, since block templates can also come from a wp_template
post object.
OTOH, it means that Gutenberg is conflating concerns within that filter, rather than aligning them within the framework of e.g. get_{type}_template()
and locate_template()
.
#3
@
4 years ago
Some more thoughts:
The wp_template
post objects are clearly the the major challenge. The rest of the logic would scale fairly well to block templates:
locate_template()
seems suffix agnostic -- it could probably find.html
files (even if located in ablock-templates
subfolder) as easily as.php
ones.- We could change either the
get_{type}_template
methods, or use thetype_template_hiearchy
filter, to add theblock-templates/*.html
counterpart for each PHP template. E.g.
array(
'page-slug.php',
'page-123.php',
'page.php',
);
becomes
array(
'block-templates/page-slug.html',
'page-slug.php',
'block-templates/page-123.html',
'page-123.php',
'block-templates/page.html',
'page.php',
);
The duplication might look a bit heavy-handed, but it's at least representative of what the get_{type}_template
function (or the type_template_hiearchy
) are supposed to do, which is nominating template file candidates.
#4
@
4 years ago
What get_{type}_template
and {type}_template_hierarchy
cannot really capture is the presence of wp_template
post objects as template candidates. The obvious place for this to go is probably locate_template
-- which would mean changing its character rather significantly, from a rather simple check for existence of a file at a given path to something that also involves a moderately complex DB query. Combined with the ideas laid out in the previous comment(s), locate_template
would check for the existence of a wp_template
object for each .html
file it sees in the $templates
candidates array.
This ticket was mentioned in Slack in #core-editor by bernhardreiter. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-editor by bernhardreiter. View the logs.
4 years ago
This ticket was mentioned in PR #1267 on WordPress/wordpress-develop by ockham.
4 years ago
#7
- Keywords has-patch has-unit-tests added
Early draft. Details to follow.
Trac ticket: https://core.trac.wordpress.org/ticket/53176
#8
@
4 years ago
JFTR, I'm focusing on integrating Gutenberg's current template logic as-is into Core in https://github.com/WordPress/wordpress-develop/pull/1267 (which is tricky enough). If we decide to align template resolution concerns more with locate_template
et al (as discussed in the above comments), we'll need to do so in a follow-up.
youknowriad commented on PR #1267:
4 years ago
#9
Some updates here:
- Removed all changes related to the WP-Admin menus for the CPT (these are not going to be shipped).
- Moved some files that are not "admin" into "wp-includes".
- Enable the block-templates support by default.
The next step for me is going to make everything work as it should in the UI before attacking the code cleaning.
youknowriad commented on PR #1267:
4 years ago
#10
@ockham I removed all the logic that fetches templates from files (block based themes) from the code and left just the part about custom template (the CPT). I wonder if resolve_block_template
is still necessary. At least I think there's a few things we can remove from the resolution logic (as we don't care about theme files)
youknowriad commented on PR #1267:
4 years ago
#11
@ockham I wanted to add that I had to change the "prepare_for_database" function in the REST API controller because the create_item unit test was failing (compare it with Gutenberg). I think the failure was legitimate and we probably should fix that function similarly in Gutenberg as well, though not sure why the unit test was not failing there.
(Just wanted to note this comment somewhere so I don't forget about it :P )
4 years ago
#12
Pushed a few changes; feel free to revert if you disagree.
This LGTM overall. I haven't reviewed the controller closely, but I think this PR should be in good enough shape to merge.
#13
@
4 years ago
- Owner set to youknowriad
- Resolution set to fixed
- Status changed from new to closed
In 51003:
4 years ago
#16
@ockham I wanted to add that I had to change the "prepare_for_database" function in the REST API controller because the create_item unit test was failing (compare it with Gutenberg). I think the failure was legitimate and we probably should fix that function similarly in Gutenberg as well, though not sure why the unit test was not failing there.
(Just wanted to note this comment somewhere so I don't forget about it :P )
Working on a fix here: https://github.com/WordPress/gutenberg/pull/32233
#18
@
4 years ago
Thanks for the commit @jorbin we should probably do the same thing in the Gutenberg plugin (for plugin users, as this is overriden there)
#19
@
4 years ago
@youknowriad done. tagged you on https://github.com/WordPress/gutenberg/pull/32700
I'll start tackling this one. I'll probably use this issue to discuss potential approaches -- we might want to massage the API a bit when carrying it over from Gutenberg to Core (rather than copying it 1:1).
Some relevant discussions here:
https://github.com/WordPress/gutenberg/pull/31604#pullrequestreview-655398786
https://github.com/WordPress/gutenberg/issues/31652#issuecomment-836553438