Don't resolve templates for non-queried editor entities - #81868
Don't resolve templates for non-queried editor entities#81868scruffian wants to merge 6 commits 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. |
|
Size Change: +60 B (0%) Total Size: 7.75 MB 📦 View Changed
|
e60f235 to
2da7b5a
Compare
2da7b5a to
cbbe9d2
Compare
Gate the option on the edited post type alone instead of the focused back callback, which missed template parts opened directly from the list and reloads of a focused template part URL. Extend the exclusion to patterns and navigation menus, which resolve a fallback template the same way. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The v2 site editor resolved a template ID for any edited entity, so template parts, patterns, navigation menus, and attachments fell through core-data's template hierarchy lookup to an unrelated fallback template. That surfaced as a bogus Show template menu item, an Edit template command, and the fallback template's styles applying to the canvas. The v1 site editor guards against this in use-resolve-edited-entity; putting the guard in getTemplateId itself covers every caller, including edit-post's unguarded ones. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
With getTemplateId no longer resolving a template for design post types, the menu item's original condition already hides it in every path that mounts the editor, so the second gate guards a state that cannot occur. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The v2 editor resolved a template for whatever entity it opened, so template parts, patterns, and navigation menus fell through the template hierarchy to an unrelated fallback. Guard it where the v1 site editor guards it, next to the resolution itself, rather than changing what getTemplateId returns for every caller. Attachments keep resolving, since they do have a place in the template hierarchy. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
| * @param props.postId The ID of the edited entity. | ||
| * @return The template ID, or `undefined` when there is no template to resolve. | ||
| */ | ||
| export function useTemplateId( { |
There was a problem hiding this comment.
Does this actually belong in core data?
There was a problem hiding this comment.
I'm pretty sure we have versions of this hook in a lot of places. And yes, maybe core-data is the right place for it.
| * The site editor guards the same resolution in `use-resolve-edited-entity`, | ||
| * over a longer list that also reflects which entities that editor opens. | ||
| */ | ||
| const NEVER_QUERIED_POST_TYPES = [ |
There was a problem hiding this comment.
That name is a bit weird to me. this is more about the post type not having dedicated frontend pages? what is "queried" about?
Also isn't there already support flags for this, or is the static list mandatory.
There was a problem hiding this comment.
yeah i don't really like the name. the original name was "post types that don't have parent templates" which I also found confusing as they do appear in templates. What about "post types not in template heirarchy"?
|
Hey 👋 I wanted to give you a heads-up since this pull request adds new files containing JSX. #80123 enables an ESLint rule that requires that files containing JSX must use the What you'll need to do: You'll need to rename any new files containing JSX to use the This comment is automated, based on pull requests with recent activity that contain affected |
What?
Stops the lazy editor from resolving a parent template for editor entities that are not queried content: template parts, synced patterns, and navigation menus.
Why?
Those entities can be edited directly, but they do not have their own frontend template hierarchy. In the v2 site editor, this means we display the "Show template" option in the viewport dropdown.
How?
Adds a
useTemplateIdhook that centralizes template resolution for the lazy editor. The hook returns the edited template forwp_template, and skips entities like template parts, navigation overlays and synced patterns, which aren't part of the template heirarchy.Testing Instructions
npm run test:unit packages/lazy-editor/src/hooks/test/use-template-id.js.Use of AI Tools
Codex and Claude Code were used to investigate the issue, implement and revise the approach, run verification, and draft this PR description.