make redirect support work on all user account creations

i am unable to reproduce this problem -- registration redirects work fine regardless of whether one or two email fields appear on the registration form. i cannot fix if i cannot reproduce. :) there have been two minor bugfixes since the 5.x-1.0 release, but i highly doubt they introduced this problem.

note that you must have 'Set password & Immediate login' enabled in order for redirects to work.

please close this issue if you solve your problem. thanks.

this is dicey. the reason it doesn't work when only one email field is displayed _and_ immediate login is disabled is that none of the logintoboggan code gets run in that instance, since it's all disabled. however, with email confirmation enabled, and immediate login disabled, the code is activated on the registration page. my original intention was to only have redirects work when immediate login is enabled, but the current state has obviously led to an inconsistency.

fortunately for you, the easiest way to resolve the inconsistency was to have the LT code run for all user registrations that aren't initiated by an admin -- it actually wasn't too bad of a fix because the submit code for processing logins is pretty well written.

so i guess we have a new feature... :)

fixed in 4.7.x, 5.x, and HEAD. this won't go into an official release just yet, so if you want it right away, you'll have to brave the newest development version, which should be up in about 12 hours.

I am in this use case and tried this, and while the redirect upon registration worked, the redirect upon confirmation does not.

@JacobSingh: if you don't have 'immeditate login' enabled, there _is no_ confirmation step, at least as far as logintoboggan is concerned -- it's a standard login workflow. the fact that it doesn't work in this case is clearly stated in the help text on the logintoboggan settings page in the description for confirmation redirect.

Hmm... I think we should fix this. My use case is that users need to validate their email, but I also need a decent page flow. In my particular case, I'd like to set a cookie or something when the user goes to register telling drupal what page they came from. Then, upon finishing the registration process (changing their password after the reset link, they are redirected back there. I'd like to make a patch for this.

Here's what I'm proposing:
We pass in an arg to register like user/register?post_confirmation_url=myurl
I use the form_alter in LT to add the var to the form and the existing LT code to handle the submission, adding the post_registration_url to $user->data
I then create a form_alter / submit handler for the user/edit page where I check for the var in $user->data, and if exists, redirect the user to the page and remove the variable.

Alternately, this could be accomplished using a cookie, and would probably be less work.

What do you think?

i'm not really in favor of either idea.

_if_ we were to put this feature in, i would prefer using a custom link (like the custom validation link is already). the link can be dropped in the user email in the same place the current validation link is. i believe this could simply be accomplished by generating the standard one time login link from core, then putting a ?destination=[some_redirect_path] on the end of it. when the user submits the user edit form, they are then redirected to the appropriate page.

fixed in 5.x and HEAD -- http://drupal.org/cvs?commit=83028

pretty much implemented the way i suggested, except that i determined that we could just use the standard LT validation link even in the case where the user wasn't picking their own password.

the tweak is that in this case, the user gets sent to their user edit page, with a destination of the confirmation page -- they'll end up there after they change their user info and submit. pretty nifty. :)

also, i'd like to retract my statement that the help text clearly indicated that confirmations didn't work if immediate login was disabled -- that actually wasn't present in the help text even though i thought it was!

at any rate, i think we can finally put this issue to bed. goodnight... ;)