Closed (fixed)
Project:
Boost
Version:
6.x-1.0-beta2
Component:
Internationalization
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
8 Jul 2009 at 17:22 UTC
Updated:
5 Aug 2009 at 03:10 UTC
Jump to comment: Most recent file
Comments
Comment #1
greenskin commentedsubscribe
Comment #2
mikeytown2 commenteddo you get a 404 because of the extra
en/? My guess is something needs to change in boost_exit().Comment #3
mikeytown2 commentedIs it the default user registration form
user/register? How are you doing the redirect; rules, module, custom code?Comment #4
greenskin commentedIt is the default user/register form using a ?destination=node%2F23. The '%2F' obviously being the urlencoded '/'.
Comment #5
mikeytown2 commentedhow are you setting destination= what php code do you use to make that happen?
http://drupal.org/project/login_destination
Something else?
Comment #6
greenskin commentedOur 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.
Comment #7
mikeytown2 commentedWould you mind testing to see if this patch fixes this issue?
http://drupal.org/node/513924#comment-1804928
Comment #8
mikeytown2 commentedComment #9
zroger commentedI'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:
which results in urls that look like:
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.
Comment #10
mikeytown2 commentedThanks 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
Comment #11
zroger commentedLOL. 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.
Comment #12
mikeytown2 commentedcommitted