FSE: Move initial template fetch to client #23186
Conversation
noahtallen
added
[Type] Bug
noahtallen
requested review from
spacedmonkey,
TimothyBJacobs and
youknowriad
as code owners
|
Size Change: +7 B (0%) Total Size: 1.13 MB
ℹ️ View Unchanged
|
Wait to show block editor until template is set
noahtallen
force-pushed
the
try/move-init-template-fetch-to-server
branch
from
c2df2c3
to
eb4fe79
Compare
| $settings['editSiteInitialState'] = array(); | ||
|
|
||
| $settings['editSiteInitialState']['homeTemplateId'] = $current_template_id; | ||
| $settings['editSiteInitialState']['templateId'] = $current_template_id; | ||
| $settings['editSiteInitialState']['templateType'] = 'wp_template'; |
There was a problem hiding this comment.
I guess we can also get rid of all of these except for showOnFront unless that is already in the site entity.
There was a problem hiding this comment.
Cool. I'll look into removing these in a follow-up :)
Yep, that's the crux here. We basically use the A nice alternative would be to have the
I think that's a perfectly legit fix 👍 |
| @@ -59,7 +59,7 @@ function gutenberg_add_template_loader_filters() { | |||
| * @param string $template_type A template type. | |||
| * @return string[] A list of template candidates, in descending order of priority. | |||
| */ | |||
| function get_template_hierachy( $template_type ) { | |||
Description
This PR solves in issue with initial homepage template resolution in the site editor.
If a theme specifies three block templates (home, singular, index), the following behavior should be true when visiting the root of your site:
singulartemplate is resolved.hometemplate is resolved.This behavior is correct on the front end, but in the editor, it loaded
indexin each case. This is because we initialize the editor with thefront-pagetemplate in PHP. Unfortunately, template resolution does not work like this: each template type does not resolve to its closest match. Rather, in most cases, each template type resolves to either itself or toindex.As a result, since the theme didn't have the
front-pagetemplate, it resolved toindex. Unfortunately, I did not see a clear way to do server-side template resolution because WordPress does not actually provide a function to give you the closest matching template. Instead, as it renders an individual page or post, it will use the first template which both exists and matches the criteria of the individual post. The emphasis here is that this happens during page/post render, and not via an easily consumable function.So I figured it'd be easiest for now to just use the existing front-end
findTemplatehelper by setting the page up front. It definitely solves the issue, but it does add some overhead to loading the editor. I've solved the overhead problem by displaying the editor even before the template loads. This should make the first meaningful paint more snappy in general, even without the client loading stuff.How has this been tested?
Locally in edit site
Screenshots
Types of changes
Bug fix
Checklist: