Template field: Fix default label and skip wasted front-page lookup#78338
Open
ellatrix wants to merge 1 commit into
Open
Template field: Fix default label and skip wasted front-page lookup#78338ellatrix wants to merge 1 commit into
ellatrix wants to merge 1 commit into
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
github-actions
Bot
added
[Package] Core data
|
Size Change: -156 B (0%) Total Size: 7.96 MB 📦 View Changed
ℹ️ View Unchanged
|
ellatrix
changed the title
|
Flaky tests detected in 7f8df18. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/25915215214
|
`getTemplateId` called `getHomePage()` (and `getPostsPageId()`)
unconditionally before checking `postType === 'page'`.
`getHomePage()` internally calls `getDefaultTemplateId({ slug: 'front-page' })`,
which fires `GET /wp/v2/templates/lookup?slug=front-page` — wasted on every
non-page post type since the result is discarded by the subsequent
post-type guard.
Move the `postType === 'page'` check ahead of both resolver calls. Matches
the short-circuit pattern already used in `template-edit.tsx`
(`data.type === 'page' && getHomePage()`).
Also: `useDefaultTemplateLabel` was open-coding the same homepage /
posts-page / template-hierarchy resolution as `getTemplateId`, slightly
differently — its default lookup used `post` as the slug for non-page
post types, which isn't part of WordPress's `single-{post-type}` template
hierarchy, so it would frequently return nothing. Replace the duplicated
body with a `getTemplateId` call and look up the resolved template's
title.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ellatrix
force-pushed
the
fix/skip-front-page-lookup-non-pages
branch
from
7f8df18 to
74a99d2
Compare
ntsekouras
reviewed
May 15, 2026
| return NAME_NOT_FOUND; | ||
| } | ||
|
|
||
| const postIdStr = String( postId ); |
Contributor
There was a problem hiding this comment.
The main difference between the hook and the selector is that the hook would always return the default fallback template and not the assigned one. In this PR you can see that this leads to the below:
Screen.Recording.2026-05-15.at.5.19.42.PM.mov
Contributor
What do you mean here? I don't think that was ever the case with
In general a theme could only have an |
ntsekouras
reviewed
May 15, 2026
| // branches below are guarded by `postType === 'page'`, so resolve | ||
| // them only when the post is actually a page — otherwise the | ||
| // lookup is wasted work for every non-page post type. | ||
| if ( postType === 'page' ) { |
Contributor
There was a problem hiding this comment.
Changes in this file could be split in a separate PR.
ellatrix
added a commit
that referenced
this pull request
May 15, 2026
The post-editor's templates/lookup currently fires with `slug=front-page` on trunk (the unconditional `getHomePage()` call in `getTemplateId`). My local was running with #78338's fix applied which changes this to `slug=single-post`, but trunk's behaviour is still `front-page`. Match trunk for now; #78338 will flip this to `single-post`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
t-hamano
added
[Type] Bug
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
Mamaduka
removed
the
[Type] Bug
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Best reviewed without whitespace.
What & Why
This PR does three things:
Skips a wasted REST request on non-page posts.
getTemplateIdcalledgetHomePage()/getPostsPageId()before itspostType === 'page'guard.getHomePage()firesGET /wp/v2/templates/lookup?slug=front-pageviagetDefaultTemplateId. The result was then discarded for every non-page post. The post-editor preload e2e spec surfaced this.Removes duplicated logic.
useDefaultTemplateLabel(in@wordpress/fields) re-implemented the same homepage / posts-page / template-hierarchy resolution asgetTemplateId(in@wordpress/core-data). Two places to keep in sync as the resolution rules evolve.Fixes the wrong-template-label bug. The hook used a bare post-type name as the lookup slug for non-page post types (
post,product, …). WordPress's hierarchy issingle-{post-type}-{slug}→single-{post-type}→single→singular→index, with no bare{post-type}in it. Empirically,/wp/v2/templates/lookup?slug=postfalls all the way through totwentytwentyfive//index("Index") — wrong, that's the listing template.slug=single-postcorrectly resolves tosingle.html("Single Posts"). So the Template field's default label was misleading for any non-page post.How
postType === 'page'guard beforegetHomePage()andgetPostsPageId()ingetTemplateId.useDefaultTemplateLabel's body with agetTemplateIdcall, removing the localgetTemplateSlugToCheckhelper and the now-unusedslugparameter.History
useDefaultTemplateLabel. Already referencedgetTemplateIdin a comment, so the duplication was known from the start.template#76441 (Mar 2026, @ntsekouras) — added classic-themes branching to the same hook.Testing Instructions
templates/lookup, confirm noslug=front-pagerequest fires.Use of AI Tools
Authored by Claude (Opus 4.7) in collaboration with @ellatrix.