Hello there,

We have a multilingual site, and after user registration, we get an extra '/lang' in the path. IE: mysite.com/en/en?nocache=1 , when should be mysite.com/en?nocache=1

If I turn off boost the problem goes away.

Any suggestions?

Thanks.

CommentFileSizeAuthor
#10 boost-513860.patch2.83 KBmikeytown2
#9 boost.redirect.patch1.45 KBzroger
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

greenSkin’s picture

subscribe

mikeytown2’s picture

do you get a 404 because of the extra en/? My guess is something needs to change in boost_exit().

/**
 * Implementation of hook_exit(). Performs cleanup tasks.
 *
 * For POST requests by anonymous visitors, this adds a dummy query string
 * to any URL being redirected to using drupal_goto().
 *
 * This is pretty much a hack that assumes a bit too much familiarity with
 * what happens under the hood of the Drupal core function drupal_goto().
 *
 * It's necessary, though, in order for any session messages set on form
 * submission to actually show up on the next page if that page has been
 * cached by Boost.
 */
function boost_exit($destination = NULL) {
  // Check that hook_exit() was invoked by drupal_goto() for a POST request:
  if (!empty($destination) && $_SERVER['REQUEST_METHOD'] == 'POST') {

    // Check that we're dealing with an anonymous visitor. and that some
    // session messages have actually been set during this page request:
    global $user;
    if (empty($user->uid) && ($messages = drupal_set_message())) {
      // FIXME: call any remaining exit hooks since we're about to terminate?

      $query_parts = parse_url($destination);
      $query_parts['path'] = ($query_parts['path'] == base_path() ? '' : substr($query_parts['path'], strlen(base_path())));
      // Add a nocache parameter to query. Such pages will never be cached
      $query_parts['query'] .= (empty($query_parts['query']) ? '' : '&') . 'nocache=1';
      $destination = url($query_parts['path'], $query_parts);
      // Do what drupal_goto() would do if we were to return to it:
      exit(header('Location: ' . $destination));
    }
  }
}
mikeytown2’s picture

Is it the default user registration form user/register? How are you doing the redirect; rules, module, custom code?

greenSkin’s picture

It is the default user/register form using a ?destination=node%2F23. The '%2F' obviously being the urlencoded '/'.

mikeytown2’s picture

how are you setting destination= what php code do you use to make that happen?
http://drupal.org/project/login_destination
Something else?

greenSkin’s picture

Our node is a webform and we are simply using the webform's 'Webform access control' setting that authenticated users only are able to access the form. Webform will then put up a status warning stating that the user, if anonymous, needs to either login or register. Both 'login' and 'register' are links to their pages with a destination pointing back to the current node. The login form works correctly unlike registering.

mikeytown2’s picture

Status: Active » Needs review

Would you mind testing to see if this patch fixes this issue?
http://drupal.org/node/513924#comment-1804928

mikeytown2’s picture

Status: Needs review » Postponed (maintainer needs more info)
zroger’s picture

Status: Postponed (maintainer needs more info) » Needs review
FileSize
1.45 KB

I've definitely been able to reproduce this. Here's how.

I have a multilingual setup using en as the path prefix for english. I have user registration and user login links in the header of all pages that are built like this:

  print l('Login', 'user/login', array('query' => drupal_get_destination());

which results in urls that look like:

<a href="/en/user?destination=news">login</a>

After submitting the form, I end up on /en/en/news?nocache=1. I've tracked this down to boost_exit(). It uses url() to build a new destination after having deconstructed the $destination variable. Since $destination was presumably built by being passed through url() already, we end up with double prefixes.

In the attached patch, I essentially do the inverse of parse_url to rebuild the $destination variable with the new query string.

mikeytown2’s picture

FileSize
2.83 KB

Thanks for identifying that the problem is with url(). I think the best way to do this is to create a glue_url() function, the exact opposite of parse_url().
http://php.net/parse-url#85963

Try this patch to see if it works

zroger’s picture

LOL. thats exactly what i was looking for. i was asking everyone at work what the inverse of parse_url() was. I thought about creating a function but wanted to build the simplest patch i could.

I cant test til i get to work tomorrow. I will let you know the outcome then.

mikeytown2’s picture

Status: Needs review » Fixed

committed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.