How many ways are there to redirect after form submission?

you forgot hook_drupal_goto_alter. wth is $form['destination'] thats new to me and what are the rules for form_state[no_redirect]? Where this got added? Someone should dig around in cvs annotate and ask the original writer.

sub

OH JOY. $form gone from drupal_redirect_form and there was much much rejoicing. For those who do not remember that's an ancient remnant in FAPI.

Sorry. I just realized what is form['destination'] -- it sets REQUEST['destination'] for drupal_goto and that REQUEST really should be GET and wherever we used the form destination so that if an action is set (do we have ANY place in core where that is set??) then after the form submission Drupal finds its way back to the page but then we can put the destination in the query string.

REQUEST is broken however because it's contents is PHP.INI dependent. So. Change please REQUEST to GET in drupal_goto and let's see what breaks.

This is with patch from #8, but notice small adition inside drupal_access_denied

And here the patch that i forgot to attach.

This is very promising, there is a "user is redirect to" which comes from the original comments but since we are touching it anyways, let's fix it.

I truly love this. REQUEST bites the dust, that's exquisite.

+++ includes/ajax.inc	20 Sep 2009 06:08:53 -0000
@@ -184,7 +184,7 @@ function ajax_get_form() {
   // Since some of the submit handlers are run, redirects need to be disabled.
-  $form['#redirect'] = FALSE;
+  $form_state['no_redirect'] = TRUE;

Can't $form_state['no_redirect'] = TRUE; be replaced by $form_state['redirect'] = FALSE;? Would that allow us to get rid of $form_state['no_redirect'] too? The reason I'm asking is because the snippet below is somewhat counter-intuitive and confusing:

+++ includes/form.inc	20 Sep 2009 08:23:15 -0000
@@ -581,17 +581,17 @@ function drupal_process_form($form_id, &
+      // - $form_state['no_redirect'] is set to TRUE.
+      // - $form_state['redirect'] is set to FALSE.

Incorporating that information in the code comments would be great, then we can revisit it later. Thanks for the clarification, and thanks for rerolling!

Together with the phpDoc, I can actually understand the form APIs redirection handling now, instead of having to study the code for 2 hours straight. That is a good success metric. ;-)

Truly great code clean-up, sun and chx. Committed to CVS HEAD. Great job.

So, I have D6 code that changes the redirect destination after a comment. Thats done with by setting $form['#redirect'] in hook_form_alter(). It looks like in D7, one has to add a submit handler after comment modules handler since that is what sets $form_state['redirect']. IMO, thats not an improvement. Not worht re-opening this issue I guess, but #redirect was useful.

This was not quite completed.

a) There is no documentation on http://drupal.org/update/modules/6/7 about #redirect being gone that I can see. What should we tell D6 updaters to do?

b) There are still two places in modules/locale/locale.admin.inc that are trying to use $form['#redirect']. What should they be doing?

and

c) It needs to be updated in the Form API Reference.

I'll take these on.

@jhodgdon, for b) they use $form_state['redirect']. We'll probably want a separate issue for that.

also
c) #redirect needs to be removed from the FAPI reference guide for Drupal 7.

Followup on b) (locale.admin.inc) is at #766200: Obsolete locale usage of $form['#redirect'] needs to be changed to $form_state['redirect'].

RE #35 c - If you'd like to comment on how to move the FAPI into code, we have an issue on that:
#100680: [meta] Make API module generate Form API documentation
Constructive suggestions on how to manage it would be welcome there.

• Updated D6->d7 Module update page issue handles both $form['#redirect'] and $_REQUEST['destination']
• #766200: Obsolete locale usage of $form['#redirect'] needs to be changed to $form_state['redirect'] takes care of the locale.admin.inc issue. Already committed.
• Removed $form['#redirect'] from the FAPI Reference. It will show up on the next checkout.

Looks reasonable to me. Thanks rfay!

After reading #21 and #28, I'm hoping for some clarification. Is it intended that a redirect can no longer be set by a form builder function or a hook_form_alter()? With $form['#redirect'], people were able to do this. With $form_state['redirect'], it's not clear. If the intention is that it can only be set during drupal_process_form(), we should probably document that in the module upgrade guide. If the intention is that it ought to be settable from a form builder function or hook_form_alter(), then we have a bug, because that doesn't work when the form is cached, because 'redirect' is one of the keys in form_state_keys_no_cache(), and we can't simply remove it from there, because if two submit handlers run and one sets 'redirect' and one sets 'rebuild', then we need to remove the 'redirect'.

The question in #40 is specifically about $form_state['redirect'] and whether it should remain in form_state_keys_no_cache(), but regardless of that, please see #800460: WTF coupling between $form_state['cache'] and form processing.

Note: Documenting $form_state (including $form_state['redirect']) in #802746: Document $form_state and form builder function in form_api group. Comments and participation welcome.

what about #action? how does it work? it got me all confused up when trying to redirect after submitting comments...

barraponto, you probably know this, but #action is for *submitting* to a different location, which is a very uncommon situation. If you want to redirect after submission, use the standard technique of $form_state['redirect'] = 'some/path';