Removing need for patching core

See also http://drupal.org/project/login_destination

The way the patch to core works is to set the $_SESSION['destination'] to $_GET['q'], which is the intended path the user wanted to go it.

The patch you provided sets it to $_REQUEST['destination'], which may not be set at all.

So, what I did was to set the SESSION destination to $_GET['q'] instead of $_REQUEST['destination'].

It seems to work for me.

If someone verifies it, then I can update the documentation and remove the patching instructions, and patches.

Setting to fixed.

I could be wrong on this, but the reason to why I constructed the patch the way I did was because

I suppose we could do

(not tested, just braindump, sorry for not providing in diff format)

http://api.drupal.org/api/5/function/drupal_access_denied
http://api.drupal.org/api/5/function/menu_set_active_item

I tried it with your suggestion, and it seems to work fine for me.

I ported it to 4.7 as well, and updated the documentation. The patch files are gone too.

Hello,

Sorry to bring up an old issue back to life, but I really feel it is exactly matching with the bug I encountered. Please note that I am talking about the 6.x branch, previous branches might not be able to work like this, thus I updated the "Version" for this issue.

I've been scratching my head few hours now and I suddenly realized my problem came from Customerror. Using this method of storing the destination in a session variable as an unpleasant effect, whenever an user encounters an error generated through Customerror, this session variable is set (in the customerror_page(), using hook_page()) and no matter where he goes after this, as long as his session is alive (I am not talking about a Drupal session of the logged user... we are in the case of an anonymous user, so I am talking about the current PHP session, usually maintained with simple cookies or through session ID) and then when the users decides to login, he's brought back to this destination (stored in the session variable previously), because of customerror_user() using hook_user(), which is hooked right after login. This does not make sense to me at all for 404 errors (what's the point of storing destination at this moment ?) and for 403 errors it sounds logical to login right after an error happened, but it is not logical to keep this session variable if the user goes "away" from this error.

I attached a patch solving the issue for 404 pages. And I think we should explore a better solution to store and/or destroy this session variable for 403 pages. I do not see how you could empty this variable if the user does not login straight away (unless maybe store another session variable with a timestamp and not use the destination in the session variable if it is too old, but I don't like this idea). So my real proposition is to remove completely this session variable, and let users handle this in the code of their custom 403 error... they can easily insert the login form in it or as you advise on your module homepage use drupal_get_destination() to provide a link to the login form. So this is the second patch attached, which removes completely the session variable. Of course, I may have overlooked a crucial point and the real reason of using this session variable, if so I would really like to know what is its purpose and if removing it has other side effects I didn't experience yet.

this is a problem in the 6.x release because it is overriding any explicit "destination=bla/bla" set in a login link. as you say, it particularly doesn't seem to make sense for 404 errors, as logging in is not going to make the missing page appear.