Closed youknowriad closed 5 months ago
cc @ntsekouras as I believed you worked on some of this (well me as well :P)
@youknowriad, can you reproduce the issue? In that case, would you mind adding the reproduction steps?
The obvious guess is that the useAvailableTemplates
hook doesn't return all available templates.
I can't really reproduce actually :) I'll ask more information about it.
Download 2024 Theme
Run wp-env in 2024 Theme folder
Remove customTemplate
array from theme.json
, save theme.json
Open the backend of the site
Navigate to Site Editor
Select Template section
Observe custom templates are still listed under Custom: page-no-title
, page-wide
, page-with-sidebar
, single-with-sidebar
Navigate back to dashboard Add new Page Open Page panel Observe Swap template is missing
I think I know where regression is coming from. The old component was merging values from REST API and editor settings availableTemplates
. This was a requirement for Template Editing mode. Classic themes with special support flags can have mixed templates — block and PHP.
Unfortunately, this behavior also covered a bug for the block themes, where querying the templates endpoint by postType
was returning incorrect results.
availableTemplates
setting results different?availableTemplates
is populated via WP_Theme::get_post_template
and, due to its data structure, uses a different filtering method.get_block_templates( [ 'post_type' => 'page' ], 'wp_template )
, and this is where we have a bug when filtering file-based block templates. The filtering happens much earlier than we have all the information about the template.Short-term for minor release: Merge template values like before. This won't work. The availableTemplates
setting returns just the slug => title
template map. Block themes need the whole object.
Fix underlying bugs in PHP functions. I'll start working on the fix on Monday, and then we can evaluate its inclusion in a minor release.
@oandregal, I tracked down this regression to this performance ticket - https://core.trac.wordpress.org/ticket/57756.
The problem with 55687 changeset:
_get_block_templates_files
isn't aware if the file is a custom template. So, it does strict post-type checks.A fix is ready for testing #61244. I would like to add PHPUnit tests before landing them in the core, but I still haven't figured out the best way.
Based on the test instructions provided by @mike-henderson I'm unconvinced this needed any fixing, and #61244 introduces a performance regression (timeToFirstByte, front-end).
I've shared what I know at https://github.com/WordPress/gutenberg/pull/61244#issuecomment-2089975586 to gather feedback. The TLDR is: how custom templates are registered by block themes? Via customTemplates
in theme.json
(my expectation) or by merely being present in the templates/
folder?
Description
Possible the same as https://core.trac.wordpress.org/ticket/60997 Potentially related to #60946
In a block theme, by default, The Template setting in the Post/Page panel only has Edit template, Create new template, and Template preview. I can see the custom templates registered in the site editor under the Custom section of Templates. The "Swap Template" menu item is not visible when you have custom templates.
Apparently adding the
customTemplate
setting totheme.json
shows the templates there.It seems that it used to be visible in previous version of WordPress.
Step-by-step reproduction instructions
Just open the post editor for a block theme where you created or has custom templates.
Screenshots, screen recording, code snippet
No response
Environment info
No response
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Yes