Site Editor: Fix template resolution for templates assigned as home page #56326
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
youknowriad
added
[Type] Bug
youknowriad
requested review from
draganescu,
jameskoster,
ramonjd and
ntsekouras
youknowriad
commented
Nov 20, 2023
| @@ -54,7 +55,6 @@ function useResolveEditedEntityAndContext( { postId, postType } ) { | |||
| const { | |||
| getEditedEntityRecord, | |||
| getEntityRecords, | |||
| getDefaultTemplateId, | |||
There was a problem hiding this comment.
If this PR is considered good, I'm going to include the removal of this selector/resolver/reducer as well since it's something recent (a new API not in core) that is not needed anymore.
|
Size Change: +10 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
|
I can't comment on the code but I can confirm this is working correctly now 🙏
TT4 doesn't include a Front Page template by default. Perhaps the issue is caused by one of the patterns that is suggested when you create Front Page manually: 
|
Yeah, I guess I had a lingering front page template, so maybe it's an issue with any "page" template that contain a "query" |
ramonjd
reviewed
Nov 21, 2023
| const path = getPathAndQueryString( editedEntity.link ); | ||
|
|
||
| // If no template is assigned, use the link to fetch the right template. | ||
| return __experimentalGetTemplateForLink( path )?.id; |
There was a problem hiding this comment.
In my testing, this works well, i.e., the front page template is loaded in preference to the static home page in the reader settings.
However, I noticed that when opening the single page (Design > Pages > Static home page), the front page template is also loaded.
When on a page details view, should the page's template rather be loaded? The page's details in the left sidebar describe the page's meta but display's the front page template, which appears unrelated.
Trunk
On the static page's home details view, we get the pages template, e.g., twentytwentyfour//page.
This PR
Here we're loading twentytwentyfour//front-page
What's the preferred way to handle page details? Should we still load the page's true template so folks can edit it as per other pages?
There was a problem hiding this comment.
I think the "front page" should load even in that case because that's the actual template that is used for that specific page anyway in the frontend.
There was a problem hiding this comment.
That's correct, Front Page will be used for the site homepage regardless.
There was a problem hiding this comment.
Thanks for the confirmation. 👍🏻
I suppose I just found it confusing to see the page details on the left, including excerpt etc, and not the corresponding representation of that page on the right.
There was a problem hiding this comment.
Thanks for fixing this, this is testing better than on trunk for me 👍
| Before (uses page template) | After (uses front page template) |
|---|---|
 |
 |
One issue I ran into is that if I manually set the page itself to have a particular template set, then loading the site editor will still use that one, whereas the site frontend winds up using the Front page template. I think the cause is the early return if currentTemplateSlug is set?
| Site editor where custom template is shown as in use | Site frontend which uses front page template |
|---|---|
 |
 |
The second issue is that we have a bug in the "template preview" option under the "template" menu. If you disable "template preview", what we're trying to do is to guess which post blocks are used in the template and only show these in the editor, but the algorithm excludes all query block.
I think the bug appears to be slightly more than that — if the template doesn't contain a Content block, then I still get dropped into the editor in the content editing mode, but without any blocks being editable. In order to edit the template we need to click on a block in the template and switch to the template mode. I.e. this is how it looks when I open the editor without a Content block — nothing in the list view, and nothing under the Content panel on the right:
So in the case that there are no content blocks outside of the query loop, perhaps one option could be to default to the template editing mode, and hide the Template Preview toggle entirely?
Interesting, it's weird that the frontend continue using the front page template in this case 🤔 even if the user explicitly set a custom template. There are two ways to go about this:
The latter is probably safer as the former can also be seen as a breaking change but I also wonder if people raised this before on Core.
What about a fallback to "page title + page content" in this case. |
Afaik that's how the Front Page template has always worked. It will display the site homepage regardless of reading settings, or which template was originally applied to a static homepage. Related to this, it doesn't really make sense to allow the user to change the template applied to their static homepage when Front Page exists. |
I think I lean a little in this direction, as changing how the behaviour works when folks set a front page under Reading could feel like a breaking change, as you mention.
That sounds like a better fallback if no blocks are present, good idea 👍 |
|
Thanks for the reviews folks, I've opened an alternative PR in #56418 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
closes #56267
I think this is a regression that was introduced in #51477
What
If a page was set as "static home page", and you had a "front page" template on your theme, this template was not being picked as the template to use for your home page, instead we were always using the default "page" template regardless of whether that template exited.
This PR fixes that by avoiding the use of
getDefaultTemplateselector and instead uses__experimentalGetTemplateForLinkto resolve templates for specific pages if they don't have a fixed or edited "template" property defined.Why?
The template resolution mechanism is a bit complex and the previous implement was trying to reimplement it entirely locally, there's another solution where we could look at the presence or not of "front page" template before falling back to
getDefaultTemplatebut I thought that was too complex since we already had a way to ask the server for the fallback template.Testing Instructions
1- Create a random page and use it as "static home page" in your "reading" settings
2- Ensure that you have a front page template on your theme
3- Open the site editor: The front page template should be loaded for your page.
While working on this I noticed another slightly related bug. The "front page" template of the the 2024 theme contains a "query loop" and doesn't use "post title" and "post content" templates directly. This has a number of consequences that make the editor a bit different than the frontend.