First I must say that I love this module and I think that this sort of functionality should be in core.

I have one feature request. When a path already has the destination set, the redirect fails.
Example:

- I browse to node/add/description?productid=20&destination=product/music/product_to_describe
- Instead of an access denied, your module sends me to user/login?destination=node/add/description
- I login and then it brings me to node/add/description (productid is unknown)

Or, another use case:
- I browse to node/add/hotel?destination=hotels
- Instead of an access denied, your module sends me to user/login?destination=node/add/hotel
- I login and then it brings me to node/add/hotel
- After submitting, I am send back to the homepage instead of 'hotels'

Would it be possible to detect if there already is a destination variable and if so, rename it to destination2 in between?

Comments

deekayen’s picture

deekayen commented

I'm not so sure that's a problem with this module as much as it is a deficit in the Drupal destination redirect APIs to nest destinations. I take it that you feel like this module should make a workaround for that?

BarisW’s picture

BarisW commented

Well, this is the only use case I can think of that uses nested destinations. It can happen that you already have a destination but need to login first. If it is possible to get this in the module, that would be awesome of course :)

ezra-g’s picture

ezra-g commented

It seems ideal to me to at least populate the destination value onto the user registration link, if it is present, so that the user can recover and maintain the intended workflow either by logging in or by registering for a new account.

pwolanin’s picture

pwolanin commented
Version: 6.x-1.2 » 6.x-1.x-dev

This is pretty hard to fix.

in D6 in drupal_access_denied, we have:

  // Keep old path for reference, and to allow forms to redirect to it.
  if (!isset($_REQUEST['destination'])) {
    $_REQUEST['destination'] = $_GET['q'];
  }

So if destination is already in the query string, we don't get the original path.

The only 2 ways I see around this are #1 using hook_boot() to capture the original q parameter (or the destination param and then saving that elsewhere), or some ugly parsing of the request URI.

dieterholvoet’s picture

dieterholvoet commented
Issue summary: View changes
Status: Active » Closed (won't fix)

Drupal 6 has long been unsupported.