form does not respect #redirect parameter if added using hook_form_alter()

Taylzor,

Thanks for this feedback. You have a very good point here. I will add this fix shortly.

Fixed in 6.x-1.x-dev. Please allow up to 12 hours for dev package to update.

Fixed in 6.x-1.x-dev. Please allow up to 12 hours for dev package to update.

I looked and this patch is not in the latest dev version. What gives?

By the way, #redirect can accept the following and all need to be checked for:

<?php
$form['#redirect'] = 'node';
?>

<?php
$form['#redirect'] = array('user/login', 'destination=node');
?>

<?php
$form['#redirect'] = FALSE;
?>

http://api.drupal.org/api/file/developer/topics/forms_api_reference.html...

Also, this should override destinations as well.

I am also having an issue with this. It has prevented me from using the ajax module. The redirections from either logintoboggan or logintoboggan are not working. Instead users are directed to the home page.

Oops. I meant the redirections from either logintoboggan or *login_destination* are not working.

subscribing

subscribing

subscribing

subscribing

same here....

subscribing

assimilate this! :-)

Thanks a lot : patch from #15 works perfectly.

Not sure if this is related to (or complicated by) #360545: Error with Form Block module - I agree it would be useful to have programmatic control over any given form's #redirect property; the 'disable_redirect' plugin makes it all or nothing.

The patch in #15 throws away the query string part of the redirect, if set - on further investigation I noticed that the ajax_get_redirect() function already supports the array format for redirects, so I rolled a new patch against 6.x-1.14 that does pretty much the same thing, but passes the complete $form['#redirect'] value to $data['redirect'].

On further testing, I found the inverse problem with my own patch; in my case I wanted the default $form['#redirect'] to send the user someplace else... the patch worked in that case, but I also have a button that I want to submit via ajax and then *not* redirect. I discovered two issues:

1. The $form_state['redirect'] value, if set, was getting clobbered by the $form['#redirect']. This is fixed by doing in af/elseif test instead of two separate if() tests in the new & improved attached patch
2. Setting $form_state['redirect'] to boolean FALSE in my submit handling function did not work; I kept getting redirected to the base path of my site.

After looking at Drupal.Ajax.response with Firebug I noticed that the test for skipping redirection is whether data.redirect === null, so on a hunch I set my $form_state['redirect'] to NULL instead of FALSE, and that worked perfectly.

hmmm I'm afraid the patch still hasn't fixed this problem for me...

After applying it I now get the message that an email was sent but no redirection at all. it stays on front page.

I really appreciate your efforts, but is there any chance you could have another look? I can't seem to get it to work.
Thanks

This is my first attempt at uploading a patch, so hopefully it works. The issue with the original code seems to be the second redirect if/then statement. It mixes the indices of $form and $form_state and likewise puts both $form and $form_state into the statement.

None of these patches worked for me... redirect is still being trumped... when i turn ajax off, i get the proper redirect and messaging...

----EDIT
I take that back... i was fighting for 2 hours and then i reapplied #15, and things seem to be working now.

Apologies :)

Does anyone plan on implementing this into the module so us rookies who don't know and are afraid to patch modules can update? Thanks!

#15 worked for me

subscribe, glad someone fixed this. After 4 hours of debugging at least I figured out what was causing the problem. now I can try to patch it.

if somebody submits a working patch which can pass review, I will apply it.

#21 worked for me. It seems like bug in original code.