Hi Guys
I'm opening this issue to contrib some changes that we have for globalredirect that we currently use on every site we build.
The problem we have is that globalredirect makes a wrong use of prefixes, and it only works with the language prefix, but when you use a module that also uses prefixes, things wil break.
What we do, is change the what we compare things.
The way we see things:
- First we should get where the user is standing
- We then check where we want the user to be (alias)
- Then we compare if the user is where we want him/her to be
- if different, redirect.
So what does this patch changes?
- There is no need to run hook_url_outbound more than once. First invocation is enough to get the final modified path. We remove the second invocation, which by the way, passes an $alias as the path, which makes no sense since we only want to modify unaliased paths.
- We keep the original $request_path (globalredirect_request_path()) $current_path (current_path()) and we play around with $path which was initially the same as $current_path. This will be our reference and is from where we get the alias.
- This $path DOES NOT includes prefixes nor does the $alias which we compare to $request_path which DOES contain prefixes.
- We need to include prefixes in language check, as not having them is one of the faults of the module (line 171+), this causes infinite loops when other modules implement their own prefixes.
- Prefix needs a slash at the end EVEN if we have no alias, (line 187+) This causes again infinite loops when prefixes other than language are used.
- Prefixes need to be taken into account again in case insensitive check (line 207+), again infinite loop
- Redirects should not be made to aliases, but to drupal paths, as they get converted afterwards. (line 217+)
Also, included in the patch is a different version of globalredirect_request_path() which emulates request_path(). This is as I see it, a more accurate way fo doing it as it mimics drupal's way better, but feedback on that is appreciated.
If any explanation is required please let me know.
I would really appreciate if this gets reviewed and committed. We have't been able to use the original module at all, because of the infinite redirect with multiple prefixes.
Cheers
Comments
Comment #1
jm.federico commentedComment #2
jm.federico commentedComment #3
jm.federico commentedI'm splitting in 2 patches (just to have it clearer).
Attached patches agains 1.5
Cheers
Comment #4
jm.federico commentedOk, I'm attaching a new patch which fixes the domain language redirection.
Comment #5
dooug commentedThese patches in #3 and #4 applied cleanly (if applied in order) to the latest 7.x dev of global redirect. Seems to resolve any of the redirect loops that I was experiencing. I'm not familiar enough with the module code to comment on the validity of the patches' changes.
Comment #6
cyberschorschI failed applying all patches together so I manually applied the last patch in #4. I created a single patch for all of these changes.
This fixes the Issue for me.
Comment #7
mike stewart commentedAfter nearly a year, and multiple patches, it'd be nice see a maintainer of globalredirect at least respond to this issue. Does the direction make sense? Any reason it hasn't been committed to globalredirect?
Comment #8
raulmuroc commentedAgree with @mike_stewart that more continuity is needed! Anyway, I would apply more testing to the latest patch before commit it. It needs communiti rewiew&test!
Thanks!
Comment #9
stmh commentedpatch #6 seems to work in combination with a complicated purl-setup on my end.
Comment #10
raulmuroc commented@stmh, could you describe your "complicated purl-setup" through steps that other Drupal users can benefit of it?
Thank you in advance.
Comment #11
aaronbaumanhave been using patch #6 in production for about a year now, working good
Comment #12
mike stewart commentedRealized I just noticed this was never RTBC. I am assigning to me so I can re-test this in the next few days and hopefully get it some new attention now that there seems to be new maintainers wth commit access. I plan to accomplish it by Tuesday: 9-30-2014.
Comment #13
miro_dietikerSounds like a significan cleanup.
While there is some risk / concerns with Drupal 7, i would expect it to go in more easily in 8.x.
Also with 8.x we tried to push test coverage to a next level and we really have tests for every process that matters.
Sure, all the infinite loops you're referring to need to get a test so we can be sure things are clean now.
Hope you find time to work on some tests!
Comment #14
mike stewart commentedok, lots of life & client work came up ... hope to jump on this next week ... but unassigning in the meantime
Comment #15
bendev commentedHere is a new version of patch for the current code.
it seems to work for me as well Thanks; Will continue further testing
Comment #16
TelFiRE commentedI'm just wondering where things are at on this issue, since the issue linked in the home page as the reason globalredirect is incompatible with this module, links here as its solution.
Comment #17
Rameez commentedPatch at #6 works fine. Wonder when this will be committed.
Comment #18
gnassar commentedPatch still applies to 7.x-1.x-dev. Ready for RTBC.
Comment #19
gnucifer commented@TelFiRE I was wondering the same thing, it seems like the current patch in this thread does not fix the incompatibility issue with hook_url_inbound_alter() as discussed in https://www.drupal.org/node/774950. I created a revised patch that also takes care of this issue. Hopefully the change does not break anything else. The logic in globalredirect_init() is pretty complicated so hard to tell, I tried to be as nonintrusive as possible. It is possible that the whole logic can be refactored and simplified, but I choose to sneak in the change at the "right" spot in the current flow instead.
Comment #20
gnucifer commentedI think my previous patch could cause a redirect loop if the normalized request path also have an alias. I have refactored the patch using more a defensive approach that should not result in this problem.
Comment #21
BarisW commentedCan we please have a re-roll against the current dev version?
Comment #22
sgdev commentedThe patch in #20 applies cleanly to 7.x-1.x-dev. I see no need for a re-roll.
Yes, it does not apply cleanly to the current live version (7.x-1.6), nor should it.
Comment #23
sgdev commentedExamining more closely, there is an issue that needs to be resolved due to a bit of code already being moved in dev. Attached is a new patch for review.
Comment #25
artematem commentedPatch #23 fixed the issue for me.