Redirect to Page User Was On When Registration Started

It has the ability to redirect to an arbitrary page, what needs to be added is a special designation such as which will instruct the module to accept a hidden variable with the current page's path, which would have to be included in every form, and use that for the redirection instruction.

not clear exactly what you mean, here.

one easy way to do it, i think, is to provide a function in LT that other modules can call (or that can be put into PHP block code) that will basically add a register link to whatever place it's called from (think of it as a themable function, i guess), appending a destination query string (simple to do w/ drupal_get_destination). since the registration page is only a single step form, the drupal_goto() that sends the user to the login redirect or the user's home page would be overridden by the destination query, and you'd be right back at the page you started on. that's my first thought on a simple, clean way to implement it.

i would _not_ use a hidden form field. with LT registration is a one step process, so the destination string should do it. as a matter of fact, even if there are form errors, i *think* that destination string will be preserved in the URL.

if you want to add that destination string to the link in the login form, we need to check to see if that login link is created as a form item (i think it is). if so, then it can be manipulated via hook_form_alter by LT the way the rest of the login block is.

and you're saying you want the register link in the login form to be themable? why is that? i can see wanting theme control over a custom registration link, but not that link.

I'm afraid I'm not following exactly what's going on here. I just did a quick test, to make sure I'm not totally insane. LoginToboggan appears to get the redirection right when the destination is added to the URL. The example I used was just going to a story while not logged in, and clicking on the register link in the "login or register to post comments" line. The destination is added by the comment module when it generates the link.

So is the issue purely one of the Create new account link in the login block not getting the destination? LoginToboggan currently adds the destination to the login button when presenting an access denied page. Is there any reason not to add it to the Create New Account link? (Granted, this is messy.)

i think adding it to the create new account link would work. i don't think it's messy at all -- should be able to do that fairly cleanly in the code, and core adds destination query strings to links all the time.

My concern is that the user module takes the two links (create new account and request new passwords), themes them, and adds the resulting HTML to the form as the 'links' element. This means we'd have to duplicate what it does, and replace the element, so that any changes to that section of user.module wouldn't be inherited by LoginToboggan, but would have to be manually duplicated. It should work, but I'm not fond of it.

Or am I missing an alternative tactic for doing this?

well you should have the original links from user module in the form element during the form_alter, so why not work with what you have? parse it and tack on the destination query, perhaps? something along those lines would do a bit to future-proof it, although i don't see anything wrong with just a direct form alter of the links -- it's doubtful those links will change very often, and it wouldn't be that hard to keep up with if they did.

What I have are the links after they've been themed, in other words, an HTML fragment. While it's doable, it feels bass-ackwards to me. The original links are themed, the HTML needs to be parsed, then either the HTML updated or the links recreated as a list and rethemed.

Simply looking for href="...user/register" (with a proper regular expression) and editing it as a string is likely to work 99.9% of the time. I'd prefer 100%. I think I'll first file an issue and patch against user module, and see how that's received.

Gary

that's probably a solution for drupal 6, in which case we can either fix it there and then add the feature in LT then, or do something right now that will make it work on drupal 5. i see no problem with either, also approach 1 is certainly cleaner.

I'm not sure which one you mean as approach 1.

For what it's worth, I just came up against the same problem (premature rendering of links), doing a 4.6->4.7 upgrade, where the typical teaser can have 7 different links and the order of links changed to something unreasonable (alphabetical by module name). This one would be even harder, because the links are much less predictable, but I was glad to see that 5.0 fixes this problem by changing the semantics of hook_link.

With the announcement of 5.0, I'm inclined to do that one first.

I'm not sure which one you mean as approach 1.

i'm pretty sure i meant: fix it in user module (in drupal 6), then implement the new feature in the drupal 6 version of LT.

if this ever gets in, it will be in the most recent major version, so upping...

Couldn't this be done using some sort of cookie anyway? In any case, I'm waiting for the implementation of this feature into loginToboggan impatiently!!

please see http://drupal.org/project/logintoboggan#commitment for more information on how task/feature requests are handled in the module

Redirecting to where you were is requested here #203275: Add a <previous> option to the 'Redirect path on Registration' setting and although this isn't an exact duplicate, it's close enough.