Skip to content

Improve form handling when submission handler does no redirection#2425

Merged
westonruter merged 14 commits intodevelopfrom
improve/form-handling
Jun 3, 2019
Merged

Improve form handling when submission handler does no redirection#2425
westonruter merged 14 commits intodevelopfrom
improve/form-handling

Conversation

@westonruter
Copy link
Copy Markdown
Member

@westonruter westonruter commented May 26, 2019

This follows up on #911/#923.

When a plugin adds a form to the page and the handling of the form submission does not redirect to a success page, the current behavior of the AMP plugin is to just not show any indication at all that a submission was made. The amp-form client-side fails because the POST response contains an HTML page as opposed to the expected JSON. This is bad because many forms in WordPress process submissions without redirections, leaving them to appear as broken. (In contrast, when wp_redirect() is done, then \AMP_HTTP::intercept_post_request_redirect() will automatically send the AMP-Redirect-To response header, taking the user to the intended success/failure page.)

To improve the experience, when processing a form submission (which didn't have action-xhr to begin with) we need to detect when the POST form handler is responding with an HTML body rather than a redirect, and in this case, try to serve some JSON that will populate the submit-success and submit-error message templates, based on whether the form handler returns a 200 or 400+ status code. When a 200 status is returned then a generic success message should be displayed, and when a 400+ status code is returned then a generic error message should be displayed. A challenge here is that form processors may detect an error but they still return with a 200 code, which we can't really do anything about.

The ideal is still that a theme/plugin developer adds direct support for forms by adding action-xhr to the form elements, sending JSON responses, and adding div[submitting], div[submit-success], and div[submit-error] message templates. But this improves compatibility with themes/plugins that have not yet done this.

To test this PR, use this test plugin that has a [test_form_post] shortcode: https://gist.github.com/westonruter/6c0eb253972ccdfc31f841629e2f4344

Before

No message is displayed at all when 200 response:

image

Nor in an error response:

image

After

A new submitting message is displayed:

image

And upon a 200 response, a generic success message is displayed:

Screen Shot 2019-06-01 at 22 41 00

And when a 200 response happens but the page is redirecting, a “Redirecting…” message is displayed without the success styling since it could be redirecting to an error page:

Screen Shot 2019-06-01 at 22 43 19

If there is a 400+ error response, then the submit-error message is displayed:

image

Comment Form

There is a new “Submitting” message here as well:

Screen Shot 2019-05-27 at 10 14 18

The submit-error is now styled in the same way as the generic form conversion:

image

Note the ERROR: prefix text is coming from WordPress itself.

Todo

  • Should status codes be indicated in the generic responses?
  • Is the default styling for the form messages OK?
  • Improve styling for comment form error message.
  • Ensure no regressions for comments.
  • Ensure that invalid comment submission responses return with error codes. See https://core.trac.wordpress.org/ticket/47393
  • Do not style redirection as green success.
  • Test with existing form plugins.

@westonruter westonruter requested review from amedina and swissspidy May 26, 2019 07:15
@googlebot googlebot added the cla: yes Signed the Google CLA label May 26, 2019
@westonruter westonruter added this to the v1.2 milestone May 26, 2019
@westonruter westonruter force-pushed the improve/form-handling branch from 7a59fd1 to 2fe8860 Compare May 27, 2019 17:05
@swissspidy
Copy link
Copy Markdown
Collaborator

Should status codes be indicated in the generic responses?

I don't think they're helpful for regular users if added to prominently. Maybe at the end in parentheses? e.g. Error: XY (Error Code: 404) or something like that

Is the default styling for the form messages OK?

Looks reasonable and easy to override. Contrast is good too, although it relies on the theme's text color to be dark. Maybe specify color too?

@westonruter
Copy link
Copy Markdown
Member Author

I don't think they're helpful for regular users if added to prominently. Maybe at the end in parentheses? e.g. Error: XY (Error Code: 404) or something like that

A concern I have is the XY isn't going to be super helpful either, as this is what get_status_header_desc() returns. Also, even though an 200 response is sent, a plugin or core could be sending it erroneously (IMHO) when a 400+ code is expected.

That being the case, in the case of a 200 response, what do you think of something like:

“It appears your submission was successful.”

(Still not very comforting!) But then include a details element that explains the underlying code, and a message for developers guiding them how to provide a better message, which would be sending a JSON object with a message property when wp_is_json_request(), or else to do a wp_redirect() to a success page.

This would be similar for a 400+ status code, except the user message could actually include the status code description (perhaps):

“Your submission failed: Bad Request.”

This could then include the same details element as outlined above.

Thoughts?

@swissspidy
Copy link
Copy Markdown
Collaborator

Yeah that could work 👍

Copy link
Copy Markdown
Member

@amedina amedina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Still a WIP. Should not have approved yet.

@westonruter
Copy link
Copy Markdown
Member Author

Here's what I have at the moment:

image

image

@westonruter westonruter force-pushed the improve/form-handling branch from 30cc9d9 to 13dab7f Compare June 2, 2019 02:52
@westonruter westonruter marked this pull request as ready for review June 2, 2019 07:44
$small->appendChild( $this->dom->createTextNode( $reason ) );
$small->appendChild( $this->dom->createTextNode( ' ' ) );
$link = $this->dom->createElement( 'a' );
$link->setAttribute( 'href', 'https://amp-wp.org/?p=5463' );
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noting that this page hasn't been published yet.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct. Shortlink to redirect to published page once released.

@swissspidy swissspidy requested review from amedina and swissspidy June 3, 2019 08:10
Copy link
Copy Markdown
Member

@amedina amedina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent. Ship it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla: yes Signed the Google CLA

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants