-
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
Add site editor initial redirect error handling #38655
Add site editor initial redirect error handling #38655
Conversation
@@ -48,7 +55,7 @@ async function getHomepageParams( siteUrl ) { | |||
.then( ( { data } ) => data ); |
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 can probably add some better error handling to these lines to improve the user's error message.
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.
apiFetch
will throw if there's a 4xx or 5xx error, right? Would be good to access any error message that comes back from that, in case it's useful for debugging.
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 window.fetch
won't throw an error on 4xx, and we can't use apiFetch
since it adds a REST API prefix.
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 added some handling for status codes, and rest error messages.
Size Change: +363 B (0%) Total Size: 1.14 MB
ℹ️ View Unchanged
|
I think this option is fine 👍 Divergences between the branches will confuse us in the medium term. |
@@ -48,7 +55,7 @@ async function getHomepageParams( siteUrl ) { | |||
.then( ( { data } ) => data ); | |||
|
|||
if ( ! template?.id ) { | |||
return; | |||
throw new Error( '`getHomepageParams`: unable to find home template.' ); |
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.
suggestion: Maybe we should make this message more user-friendly and display it instead of a generic error message?
The editor is unable to find a block template for the home page.
What do you think?
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.
Yep, sounds 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.
So I've kept these error messages the same so that we can locate them in the code when the user uses 'Copy Error', but the visible message is now what you suggested.
I think this is a good start, but a few issues remain.
What if we use a different route for similar errors and then display the error component inside gutenberg/packages/edit-site/src/components/app/index.js Lines 27 to 31 in 0b35edf
|
Is the goal to render the navigation sidebar? If so, this unfortunately won't do it. We'd need to render an interface skeleton layout with the NavigationSidebar slot for that. I also feel like this will be making it a little complicated. The more we do after an error is encountered, the more other errors may be triggered. I think it's best to short circuit as quickly as possible in this kind of situation.
This is a good point. There would probably be the same issue with the normal Error Boundary. Seems like a side-effect of being fullscreen. I can add a link button to the error panel.
Again, we could add links for this, but we're probably getting to the point where this needs some design input. |
Good point regarding NavigationSidebar. Let's keep things simple for now.
We could probably replace the reboot button; not sure how helpful it will be in this case.
We don't have to introduce this right away. Just wishful thinking :) |
That's true, the user can always click the dashboard link and then the editor link again to reboot. I'll do that 👍
It's a good point, other templates probably work ok. Maybe it'd be best to try to find a fallback template before bailing. |
Thanks again for working on this, @talldan. I think this is something we could ship with the minor release. We could iterate on better fallbacks and error design for 6.0. P.S. I think we need a better template resolution for WP. I like what was suggested here - #31652 (comment). |
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 great! Thank you!
|
||
if ( error ) { | ||
actions.push( | ||
<CopyButton key="copy-error" text={ error.stack }> |
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 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.
So somewhere in the code isn't passing a proper error object? I can do some debugging, but if you have any clues let me know.
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.
No clues, sorry. It was pretty easy to reproduce, though. Add an empty front-page.php
file to the top level of twentytwentytwo
.
* Try adding error handling to `redirectToHomepage` * Return early to avoid unmounting the error warning on the next line * Handle http status errors * Handle REST errors * Add dashboard link and better labelling * Remove reboot button
Description
Partly addresses #37236.
Adds some error handling to the site editors loading process. If an error happens when trying to fetch the home template, the editor will now show the usual error boundary warning
The caveat here is that the code in
trunk
is different to that inwp/5.9
. The loading process was refactored in #37248.If this improvement needs to land in 5.9.x the options are:
a) backport both #37248 and this
b) develop a separate fix for the code on
wp/5.9
.Testing Instructions
This is tricky to test. As suggested by @Mamaduka I modified the API response - #37236 (comment).
But I had to use a development environment for both wordpress-develop and gutenberg and comment out the corresponding line in wordpress-develop.
Expected - an error should be shown
Screenshots
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist:
*.native.js
files for terms that need renaming or removal).