Detour Pro
ExpressionEngine 2, ExpressionEngine 3, ExpressionEngine 4, ExpressionEngine 5, ExpressionEngine 6
Back to this add-on's main page
View Other Add-ons From Tom Jaeger
page not found, but reload and it works
Support Request
|
cityzen
|
| Posted: 06 January 2016 02:20 PM |
# 16
|
|
|
|
Hey Kevin -
The $_SESSION [‘detour’] is used to notify Detour that a redirect just happened to avoid a redirect loop. If you’re using wildcards it can easily turn into a redirect loop. It seems to be that the problem has to do with setting session variables before a redirect which is why you see a lot of code in there to close out the session data before redirecting.
I’m actually about 95% done with Detour Pro 2 (for EE2 and EE3) and looking/testing this issue currently. The problem with it also has to do the with fact that it’s completely inconsistent. Some pages I never see a 404 on redirect, some I do everything 10th refresh. I am trying to isolate it down to a single issue I can reproduce.
Let me know what I can do to help. If you’d like to reach out to me directly, you can do that at mike [at] cityzen.com or here is fine as well.
|
|
|
|
|
Steve Hurst
|
| Posted: 07 January 2016 12:40 PM |
# 17
|
|
|
|
The inconsistency on my end with the 404 seems to be caching and stash related. It seems to be worse when the page is mostly stashed or cached.
|
|
|
|
|
cityzen
|
| Posted: 07 January 2016 01:02 PM |
# 18
|
|
|
|
Yea, i’ve seen some issues in the past with caching (and stash from what I can tell) but can’t tell if that is something that could be remedied by upping the priority on the hook.
Ideally i’d love to piggyback on the EE flashdata but i’ve had pretty mixed results with that and reaching out to EL didn’t really solve much. Granted I got caught up with something when I was talking to them but the response was basically that it *should* work.
What kind of caching are you using (CE Cache?) how does stash play into it?
|
|
|
|
|
Steve Hurst
|
| Posted: 07 January 2016 01:09 PM |
# 19
|
|
|
|
We’re caching using stash templates. Not static, just to the database, using a model-view-viewmodel approach. We’re not doing any kind of serious caching on top of that.
|
|
|
|
|
cityzen
|
| Posted: 07 January 2016 01:23 PM |
# 20
|
|
|
|
The issue for me is that I just can’t replicate the problem at all. I have seen it happen on other sites but there’s no telling what they have set up. Detour Pro doesn’t claim to be compatible with CE Cache, Stash, etc. It’s not that I don’t want to say it is or that it isn’t, I just can’t say it is without in depth testing.
If you can give me some further details on what your setup is I can try to replicate it locally. Since I’m close to wrapping up 2.0 I’d love to ensure compatibility with other add-ons.
|
|
|
|
|
Steve Hurst
|
| Posted: 07 January 2016 01:26 PM |
# 21
|
|
|
|
Would it be helpful to see it first-hand? You might know more what to look for specifically. I can email you access information.
|
|
|
|
|
cityzen
|
| Posted: 07 January 2016 01:28 PM |
# 22
|
|
|
|
yea, for sure.. as long as it’s a dev box!
The BEST support request I ever had was someone sent me a whole vagrant box and we were able to go through the exact setup (server specs, database, php version, etc) and was able to finally see a problem i had never been able to replicate. That’s pie in the sky stuff, though. Shout out to that guy!
|
|
|
|
|
Steve Hurst
|
| Posted: 07 January 2016 01:44 PM |
# 23
|
|
|
|
Almost as good, we have a new test production environment we’ll be moving to, and I can reproduce the 404 there. Sent you an email!
|
|
|
|
|
Mark Croxton
|
| Posted: 22 January 2016 12:01 PM |
# 24
|
|
|
|
Ran into this too. The problem is in sessions_start() function in ext.detour_pro.php. The logic in pseudo-code seems to be:
If $_SESSION[‘detour’] does not exist
then set $_SESSION[‘detour’]
and redirect to new url
else
unset $_SESSION[‘detour’]
So logically the redirect will fail on every second page load (for a person reloading the original link in the same browser)
I commented out the session stuff and added a comparison for the old and new urls to prevent recursion:
if ($url != $newUrl)
{
if(substr($detour['new_url'],0,4) == 'http')
{
header('Location: ' . $newUrl, TRUE, $detour['detour_method']);
}
else
{
header('Location: ' . $site_index . ltrim($newUrl,'/'), TRUE, $detour['detour_method']);
}
}
Now this is just a quick fix so I’m not sure if it would prevent recursion with wildcards, but it works for me.
|
|
|
|
|
cityzen
|
| Posted: 22 January 2016 12:48 PM |
# 25
|
|
|
|
thanks for the info, Mark. i am sitting down on Sunday to get this sorted out and have a site that i can test on. Odd thing is that sometimes i’m not able to reproduce the problem but will try your patch on Steve’s site to make sure it works there as well.
Mike
|
|
|
|
|
Mark Croxton
|
| Posted: 22 January 2016 12:53 PM |
# 26
|
|
|
|
Hi Mike, I’d guess that’s because browsers cache redirects, so a soft reload will sometimes (in some browsers) replay the original response.
I think you could send no cache headers with your redirect to stop this, all of these are required to stop caching in modern browsers:
Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Pragma "no-cache"
Expires "Wed, 11 Jan 1984 05:00:00 GMT"
|
|
|
|
|
cityzen
|
| Posted: 22 January 2016 03:54 PM |
# 27
|
|
|
|
i was going to go through all of this now that i can reproduce the problem on a live server. i appreciate your help!
|
|
|
|
|
cityzen
|
| Posted: 24 January 2016 09:21 PM |
# 28
|
|
|
|
Hey Mark -
After poking around this evening I realized your solution actually works even with the wildcards. clearly a case of me overthinking things. The only real danger in removing the session logic (which I’m more than happy to do as it’s a huge PITA) is that it could allow a user to chain redirects but as long as they don’t match the previous url, it is what it is.
Thanks for the insight. Will be pushing up new version tomorrow.
Mike
|
|
|
|
|
cityzen
|
| Posted: 24 January 2016 09:29 PM |
# 29
|
|
|
|
Anyone still following this thread and having this issue, please shoot me an email and I will send over an updated version of Detour Pro for testing. You can get me at mike [at] cityzen.com
Thanks!
Mike
|
|
|
|
|
Sy
|
| Posted: 09 February 2016 12:25 PM |
# 30
|
|
|
|
I had the same problem and managed to fix it for my situation in another way. My solution was to change the PHP session to EE’s session cache by replacing $_SESSION[‘detour’] with $this->EE->session->cache[‘detour’].
This appear to also relate to this post: https://devot-ee.com/add-ons/support/detour-pro/viewthread/14670
In this instance I changed these lines in sessions_start() function which avoids the session issues:
if(!array_key_exists('detour', $_SESSION))
TO
if (! isset($this->EE->session->cache['detour']))
and
$_SESSION['detour'] = TRUE;
TO
$this->EE->session->cache['detour'] = TRUE;
AND lower down commented out :
unset($_SESSION['detour']);
I have been using this fix on Detour Pro v1.5.1 for some time and seems to work for this version.
I thought I’d post this in case it helps in any way :)
|
|
|
|
