-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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 error message from api request. #15657
Add error message from api request. #15657
Conversation
__( 'Updating failed' ); | ||
__( 'Updating failed.' ); | ||
|
||
if ( ! ( /<\/?[^>]*>/.test( 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.
Is the idea with this to exclude messages with HTML? I think it may be agreeable as a first-pass improvement, but is there a fundamental reason we should want to exclude messages containing HTML?
Stripping the HTML tags seems reasonable to me, though the specifics of doing so are some combination of challenging and risky (example solution), depending if we consider the REST response to be "safe".
It might also help to provide some context to the future maintainer what's actually happening here, either with an inline code comment or extracting as a separate, helpfully-named function (e.g. stripTags
), in scope or proposed as part of a relevant package (closest might be escape-html
).
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 reason we don't want html tags here, as some responses may contain hyperlinks or bullet points. The content may not make sense anymore if it says for example "Click on this link" and it is no longer a link.
I didn't make the tag check into a function, as I didn't seem like it would be useful to do so. But I can, if you so wish.
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 reason we don't want html tags here, as some responses may contain hyperlinks or bullet points. The content may not make sense anymore if it says for example "Click on this link" and it is no longer a link.
I think it's okay to be conservative here as you propose, as long as there's the fallback messaging of "Publishing failed".
I didn't make the tag check into a function, as I didn't seem like it would be useful to do so. But I can, if you so wish.
My concern here is whether it will be obvious here to a future maintainer what this logic is intended to do. Whether that's an inline code comment or function, I have no strong preference. But as implemented currently, I foresee it being not immediately obvious to its purpose.
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.
My concern here is whether it will be obvious here to a future maintainer what this logic is intended to do. Whether that's an inline code comment or function, I have no strong preference. But as implemented currently, I foresee it being not immediately obvious to its purpose.
Can we add a code comment here?
__( 'Updating failed.' ); | ||
|
||
if ( ! ( /<\/?[^>]*>/.test( error.message ) ) ) { | ||
noticeMessage = noticeMessage + ' ' + 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.
The concatenation† here has me thinking about localization: Based on the examples you shared at #14644 (comment), it seems we can generally expect that the messages are run through __
on the server, but it's worth checking that the user's locale preferences are in-fact represented in the UI (that the user context is known for these requests, the locale data is loaded for the user, the messages themselves are localized).
† Concatenation can be discouraged, though typically more problematic in cases of fragments within a sentence, rather than as two separate sentences.
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.
It really depends when the requests dies, to if the users language is selected. If for example, there is a PHP fatal error or database error, it will load wp_load_translations_early, which will it's best to work users language but doesn't work 100% of the time.
Maybe it is better to just use a mixture of the error code and the error status and keep the translations in javascript. This may also make gutenberg a little more platform agnostic.
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.
Maybe it is better to just use a mixture of the error code and the error status and keep the translations in javascript. This may also make gutenberg a little more platform agnostic.
Combined with the above discussion about how not all messages can be used directly from the response, this sounds promising. I'm not as sure that it benefits platform agnosticism, if the error codes are quite specific to WordPress (moreso than a message
, which could be any text).
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 requested some advice on the translateability of these strings in #core-i18n yesterday, since I wasn't personally too confident about guidelines concerning the updated strings and https://wordpress.slack.com/archives/C04KRK0KA/p1560181188005600 I just asked some follow-up questions, but it may be fine as-is. I don't think the use of |
de0cf93
to
d7a1034
Compare
@aduth Update the PR with translations feedback and comment. I also fixed some unit tests. The e2e do not seem to be running, but this seems to be unrelated. |
I restarted the build. There was one which was an intermittent failure, but the other looks like a genuine issue. The test case tries to look for the text, which was updated in this pull request:
|
I updated tests to include a message. That test is test failing, but I am not sure why... |
Manually repeating the steps of the test case, I can see that per the changes here, the notice also includes the error message, so the updated text query isn't enough to match the element. I'm not very familiar with XPath, but we could update the query to query for a notice starting with the common "Updating failed." message (reference): '//*[contains(@class, "components-notice") and contains(@class, "is-error")]/*[starts-with(text(),"Updating failed.")]' Otherwise, just specifying the full text of the message: '//*[contains(@class, "components-notice") and contains(@class, "is-error")]/*[text()="Updating failed. Error message: The response is not a valid JSON response."]' |
Tests now pass 😄 |
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 👍 Thanks for the work here.
Change comment. Co-Authored-By: Andrew Duthie <[email protected]>
Thanks again 👍 |
// Check if message string contains HTML. Notice text is currently only | ||
// supported as plaintext, and stripping the tags may muddle the meaning. | ||
if ( error.message && ! ( /<\/?[^>]*>/.test( error.message ) ) ) { | ||
noticeMessage = sprintf( __( '%1$s Error message: %2$s' ), noticeMessage, 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.
This is missing a translator comment to explain the parameters.
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.
Should this be another PR?
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.
Yes
I'm really missing a translator comment here for the notice message. The placement of the placeholders is a bit unfortunate, one could easily think those are for opening and closing tags or something. Wasn't there originally a period after the first one? |
There was a full stop added to the end of each message, instead of in the concatting string, as that is confusing. |
Description
Improve error message when saving posts. More detail #14644
Fixes #14644.
How has this been tested?
Screenshots
Checklist: