"No redirect" setting : use False instead of Null [#945926]

I found out that setting "No redirect" set the $redirect to "NULL", whereas a "False" is needed in order to unset the redirection.

webform.module line 2209

Reference I used : http://api.drupal.org/api/drupal/developer--topics--forms_api_reference....

The value may also be set to FALSE to prevent redirection after form submission.

As a new feature of 6.3.3, I set this issue as major because it actually does not work now.

Comments

Comment #1

quicksketch

he/him

CreditAttribution: quicksketch commented 19 October 2010 at 15:21

Status:

Patch (to be ported)

» Postponed (maintainer needs more info)

Hm, so you're getting a redirect currently? Where does it go to? If no redirect is set (NULL) then Drupal isn't going to redirect either. I think a redirect == FALSE does something different than NULL, where redirect == FALSE won't even leave the page after it's been submitted. Drupal normally would submit the form, process it, then redirect to another location. A value of NULL will have Drupal reload the current page after submission. A value of FALSE would cause the page not reload at all, meaning the if you refreshed the page your browser would ask you to resubmit $_POST, since you didn't get Drupal's normal refresh.

In any case, could you describe what behavior you're seeing currently?

Comment #2

doubouil CreditAttribution: doubouil commented 20 October 2010 at 09:52

I had no time to properly explain my problem, sorry.

I use jQuery.form to submit my form with the AjaxSubmit() method.

When set to Null, when I submit my form, there's a POST call made, in Ajax. The POST response is the webform page itself, but the status code is 302 : Moved permanently. And I have a GET call made to the same page.

I printed-to-check the $_POST variable in all of my pages, and neither the POST response or the GET displayed it. But I absolutely needed it, in my POST response exactly.

So I started looking in the module, and found this False setting issue.

When set to False, my POST response is fine, with a 200 code, my $_POST printed it and no weird GET call in my javascript console.
Then all I did was to print this response, and my confirmation text (thank you for submitting...) appeared in my $messages, with my form in the $content.

Setting to false was the only way not to have this behavior with a GET call after submit (GET call to node/x/done?sid=y, or whatever I put in the Custom redirection box).

The perfect solution for me would be to have only the confirmation text alone, as the confirmation page does (node/x/done?sid=y). All I want to do is to print the $messages, the form in the $content is quite useless for me.

I think you should add an Ajax option (false) along with No redirection (NULL).
A checkbox "Always display confirmation text in messages" would be cool too.

Comment #3

quicksketch

he/him

CreditAttribution: quicksketch commented 20 October 2010 at 17:46

Category:	bug	» support
Priority:	Major	» Normal
Status:	Postponed (maintainer needs more info)	» Active

Setting to false was the only way not to have this behavior with a GET call after submit (GET call to node/x/done?sid=y, or whatever I put in the Custom redirection box).

This is true, it has the behavior I described in #1. Unfortunately this may cause double submissions to occur quite regularly (any time the user goes to another page and then use the Back button on their browser). Drupal intentionally always redirects with a GET request to some URL (even if it's the same page), to prevent users from accidentally double-submitting forms.

I use jQuery.form to submit my form with the AjaxSubmit() method.

I would suggest you make a new menu callback in your module and handle the processing of the form there, returning the information that is important to you.

A checkbox "Always display confirmation text in messages" would be cool too.

Text messages are already always shown as messages unless you display the confirmation page. If you don't want a message at all you just leave the confirmation message blank (which would be unusual but possible).

So all told, I don't think this behavior should change, since it's working as it's supposed to. I think making a separate menu callback OR form_altering the form to add your own #submit handler would be the best approach here. If you form_alter() the webform form, you could manually set $form_state['redirect'] to FALSE if the request was made by JavaScript, then the current behavior would be retained but you'd get what you need for your AJAX requests.