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
Site Editor: Fix gray screen on refresh when editing pages and posts #28413
Conversation
@@ -135,7 +135,11 @@ export function setHomeTemplateId( homeTemplateId ) { | |||
*/ | |||
export function* setPage( page ) { | |||
if ( ! page.path && page.context?.postId ) { | |||
page.path = `?p=${ page.context.postId }`; | |||
if ( page.context?.postType === 'page' ) { |
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 problem lies to the fact that previous path didn't start with the /
.
page.path = `/?p=${ page.context.postId }`
should be fine.
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.
That will not always work, as WP can be installed in the subdirectory of a server, like example.com/wordpress-installed-here/
.
We would therefore need to qualify the URL against the home URL of the site, which it looks like can be had with select( 'core' ).getSite().url
.
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 appreciate the quick turnaround on this. With this comment addressed, I think this should be good to go.
And while I don't consider this a blocker, I do not really love how a request to ?page_id=n
will result in a 301
redirect on the majority of sites with pretty permalinks enabled. This is part of what I was trying to avoid in #28407, although I failed to mention it (added a comment there)
@mattwiebe Thanks for the review! I just pushed a commit which implements an alternative solution. Instead of constructing URL, we fetch the entity record and use the
I'll do some testing in a subdirectory and see what happens. EDIT: Just realized we are returning the whole path. So it works fine in a subdirectory. (Also tested and can confirm it's working) |
Size Change: -21.3 kB (-2%) Total Size: 1.37 MB
ℹ️ View Unchanged
|
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.
This is a nice change. We could maybe squeeze a bit more efficiency by preloading this entity on the server side in gutenberg_edit_site_init
here but I don't see that as a strong need for now.
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.
Worked well for me.
Fixes #28315
Description
setPage
action issued wrong requests when passingpostType
andpostId
only (no path specified). Let's use the right URL based on thepostType
.Note:
path
should be absolute here to avoid issuing requests toadmin.php
.How has this been tested?
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist: