-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Router: load proper sidebar for /wp_template
#60850
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed the issue on the tests I did 👍
Size Change: -7 B (0%) Total Size: 1.75 MB
ℹ️ View Unchanged
|
@@ -108,9 +108,7 @@ export default function useLayoutAreas() { | |||
return { | |||
key: 'templates-list', | |||
areas: { | |||
sidebar: postId ? ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's only one screen that uses the /wp_template
path, as far as I'm aware: in that screen, whether we have a postId or not, we want to show the SidebarNavigationScreenTemplatesBrowse
. Unless I'm missing something else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've looked at the Sidebar before the router refactoring: https://github.com/WordPress/gutenberg/pull/60466/files#diff-0cf5246119f61f0f26cb94918697d2cb3a0f40051045d24dd01c98241e79bde7L79 and I see how that logic could have been confusing when we ported the logic to the router.
There was two places that used the /wp_template
:
<SidebarScreenWrapper path="/:postType(wp_template)">
<SidebarNavigationScreenTemplatesBrowse />
</SidebarScreenWrapper>
<SidebarScreenWrapper path="/:postType(wp_template)/:postId">
<SidebarNavigationScreenTemplate />
</SidebarScreenWrapper>
I haven't checked how the navigator worked and how it matched URL parameters, but it sounds like the second path would be never reached? I don't think we had a /wp_template/postId
path.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The second path would be reached when you were on a site-editor.php?postType=wp_template&postId=x
page. Then, in the useSyncPathWithURL
hook, there was a getPathFromURL
that transformed these URL params into a Navigator path /wp_template/x
. And that matched the SidebarScreenWrapper
that shows SidebarNavigationScreenTemplate
.
To get the /:postType(wp_template)
path, you URL had to be site-editor.php?path=/wp_template
. Then the Navigator displays SidebarNavigationScreenTemplatesBrowse
, which is the "index".
So, yes, your fix is correct. When the URL is site-editor.php?path=/wp_template&postId=x
, we're not on the editor page for template x
, but we're on the template index page with x
selected/highlighted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The second path would be reached when you were on a site-editor.php?postType=wp_template&postId=x page
Nice, thanks for the confirmation. This is the "details page" and we have that already covered in the router, so we're good. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good 👍
I accidentally introduced the same bug on the /page
list when working on #60466, but there I noticed it soon enough and fixed it in this commit (note how it also removes the postId
condition):
d004005cd8#diff-c924d1b796a6245ad6188bcd902a7aa5894fea2275bc3818b729c1ab57f08657L49-L51
But I missed the same bug in /wp_template
. Thanks!
Fixes #60466 (comment)
What
Loads the proper sidebar for the
/wp_template
path when coming back from the editor.How
637b898 Removes the
postId
conditional.Test