Add error message from api request. #15657

spacedmonkey · 2019-05-15T13:38:14Z

Description

Improve error message when saving posts. More detail #14644

Fixes #14644.

How has this been tested?

Create a post.
Delete cookies.
Save post.

Screenshots

Checklist:

My code is tested.
My code follows the WordPress code style.
My code follows the accessibility standards.
My code has proper inline documentation.
I've included developer documentation if appropriate.

aduth · 2019-05-15T15:45:29Z

packages/editor/src/store/utils/notice-builder.js

-		__( 'Updating failed' );
+		__( 'Updating failed.' );
+
+	if ( ! ( /<\/?[^>]*>/.test( error.message ) ) ) {


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 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 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.

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?

aduth · 2019-05-15T15:48:23Z

packages/editor/src/store/utils/notice-builder.js

+		__( 'Updating failed.' );
+
+	if ( ! ( /<\/?[^>]*>/.test( error.message ) ) ) {
+		noticeMessage = noticeMessage + ' ' + error.message;


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.

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.

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).

@aduth Updated PR to use sprintf 28579ed

aduth · 2019-06-12T19:42:26Z

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 sprintf usage (link requires registration):

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 sprintf in concatenating the two strings provides any benefit, but also not exactly harmful (aside from an additional performance cost in interpolating the string, maybe not as readable for other developers).

spacedmonkey · 2019-06-25T15:02:51Z

@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.

aduth · 2019-06-25T17:50:04Z

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:

gutenberg/packages/e2e-tests/specs/change-detection.test.js

Line 202 in 56de120

    
           '//*[contains(@class, "components-notice") and contains(@class, "is-error")]/*[text()="Updating failed"]'

spacedmonkey · 2019-06-25T21:23:56Z

I updated tests to include a message.

That test is test failing, but I am not sure why...

aduth · 2019-06-26T15:19:34Z

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."]'

spacedmonkey · 2019-06-26T15:41:47Z

Tests now pass 😄

aduth

Looks good 👍 Thanks for the work here.

packages/editor/src/store/utils/notice-builder.js

Change comment. Co-Authored-By: Andrew Duthie <andrew@andrewduthie.com>

aduth · 2019-06-28T14:44:51Z

Thanks again 👍

swissspidy · 2019-07-01T11:05:57Z

packages/editor/src/store/utils/notice-builder.js

+	// 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 );


This is missing a translator comment to explain the parameters.

Should this be another PR?

swissspidy · 2019-07-01T11:08:55Z

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?

spacedmonkey · 2019-07-01T11:21:00Z

There was a full stop added to the end of each message, instead of in the concatting string, as that is confusing.

Add error message from api request.

5558cb5

spacedmonkey requested review from noisysocks, talldan and youknowriad as code owners May 15, 2019 13:38

spacedmonkey mentioned this pull request May 15, 2019

Improve error message on post save fail #14644

Closed

aduth reviewed May 15, 2019

View reviewed changes

swissspidy added the REST API Interaction Related to REST API label May 28, 2019

Use sprintf for error message.

28579ed

spacedmonkey added 2 commits June 25, 2019 14:46

Add comment

b4e7268

Fix tests for new error message

d7a1034

spacedmonkey force-pushed the feature/improve-error-message branch from de0cf93 to d7a1034 Compare June 25, 2019 13:53

spacedmonkey and others added 3 commits June 25, 2019 15:54

Merge branch 'master' into feature/improve-error-message

2f8f95f

More linting fixes

074c25a

Fix phpunit tests

7c36f2c

Improve the tests, to reflect message in error.

86fbc92

spacedmonkey requested review from ajitbohra, gziolo, nerrad and ntwb as code owners June 25, 2019 20:57

Fix text of message in e2e.

88fbc34

aduth approved these changes Jun 26, 2019

View reviewed changes

packages/editor/src/store/utils/notice-builder.js Outdated Show resolved Hide resolved

Update packages/editor/src/store/utils/notice-builder.js

3e7ae2d

Change comment. Co-Authored-By: Andrew Duthie <andrew@andrewduthie.com>

aduth merged commit ffa4a27 into WordPress:master Jun 28, 2019

github-actions bot added this to the Gutenberg 6.1 milestone Jun 28, 2019

swissspidy reviewed Jul 1, 2019

View reviewed changes

spacedmonkey mentioned this pull request Mar 31, 2020

Add save story error message GoogleForCreators/web-stories-wp#888

Merged

spacedmonkey mentioned this pull request Oct 2, 2020

Status Check: Add REST API endpoint GoogleForCreators/web-stories-wp#4790

Closed

This was referenced Jul 16, 2024

[Snyk] Upgrade @wordpress/dependency-extraction-webpack-plugin from 3.7.0 to 6.1.0 WontonSam/woocommerce-admin#129

Open

[Snyk] Upgrade @wordpress/element from 4.4.1 to 6.1.0 WontonSam/woocommerce#284

Open

OKEAMAH mentioned this pull request Jul 16, 2024

[Snyk] Upgrade @wordpress/element from 5.32.0 to 6.1.0 OKEAMAH/jetpack#23

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add error message from api request. #15657

Add error message from api request. #15657

spacedmonkey commented May 15, 2019 •

edited by swissspidy

Loading

aduth May 15, 2019

spacedmonkey May 17, 2019

aduth May 21, 2019

aduth Jun 12, 2019

aduth May 15, 2019

spacedmonkey May 17, 2019

aduth May 21, 2019

spacedmonkey Jun 4, 2019

aduth commented Jun 12, 2019

spacedmonkey commented Jun 25, 2019

aduth commented Jun 25, 2019

spacedmonkey commented Jun 25, 2019

aduth commented Jun 26, 2019

spacedmonkey commented Jun 26, 2019

aduth left a comment

aduth commented Jun 28, 2019

swissspidy Jul 1, 2019

spacedmonkey Jul 1, 2019

swissspidy Jul 1, 2019

swissspidy commented Jul 1, 2019

spacedmonkey commented Jul 1, 2019

Add error message from api request. #15657

Add error message from api request. #15657

Conversation

spacedmonkey commented May 15, 2019 • edited by swissspidy Loading

Description

How has this been tested?

Screenshots

Checklist:

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aduth commented Jun 12, 2019

spacedmonkey commented Jun 25, 2019

aduth commented Jun 25, 2019

spacedmonkey commented Jun 25, 2019

aduth commented Jun 26, 2019

spacedmonkey commented Jun 26, 2019

aduth left a comment

Choose a reason for hiding this comment

aduth commented Jun 28, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

swissspidy commented Jul 1, 2019

spacedmonkey commented Jul 1, 2019

spacedmonkey commented May 15, 2019 •

edited by swissspidy

Loading