Opened 5 years ago
Closed 4 years ago
#5760 closed defect (bug) (worksforme)
Infinite redirect loop on archive pages for days/months/years
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Canonical | Version: | 2.3.2 |
| Severity: | normal | Keywords: | canonical, url, date, archive, redirect |
| Cc: |
Description
I have canonical redirects disabled due to infinite redirect, but the last major release (2.3) fixed it.
But I have noticed that it is still happening in certain parts of my blog, namely the date archive pages.
For example:
/blog/2007/12/
/blog/2008/
(I have re-enabled the canonical function while this bug is open)
All other pages work fine, except those that show a date archive page
This bug seems similar to #5705
Change History (11)
- Summary changed from Infinite loop on archive pages for days/months/years to Infinite redirect loop on archive pages for days/months/years
I have been doing a little bit of digging around in canonical.php and have found that $requested_url is never the same as $redirect_url
The following bit of code shows some print statements and die() functions that I have added to canonical.php
function redirect_canonical($requested_url=NULL, $do_redirect=true) {
global $wp_rewrite, $posts, $is_IIS;
print "\r\n<br />".$requested_url." ";
[...cut...]
if ( $redirect_url && $redirect_url != $requested_url ) {
// var_dump($redirect_url); die();
print "1:".$redirect_url."|".$requested_url." ";
$redirect_url = apply_filters('redirect_canonical', $redirect_url, $requested_url);
if ( $do_redirect) {
print "2:".$redirect_url."|".$requested_url." ";
// protect against chained redirects
if ( !redirect_canonical($redirect_url, false) ) {
print "3:".$redirect_url."|".$requested_url." ";
die("Die:1");
wp_redirect($redirect_url, 301);
exit();
} else {
die("Die:2");
return false;
}
} else {
die("Die:3");
return $redirect_url;
}
} else {
#die("Die:4");
print "FALSE ";
return false;
}
If I go to /blog/2007/12/ I get the following output:
<br /> 1:http://www.roganty.co.uk/blog/2007/12/|http://www.roganty.co.uk/blog/index.php?year=2007&monthnum=12 2:http://www.roganty.co.uk/blog/2007/12/|http://www.roganty.co.uk/blog/index.php?year=2007&monthnum=12 <br />http://www.roganty.co.uk/blog/2007/12/ FALSE3:http://www.roganty.co.uk/blog/2007/12/|http://www.roganty.co.uk/blog/index.php?year=2007&monthnum=12 Die:1
On any other page I get the following output (followed by the rest of the page):
<br /> FALSE
comment:5
follow-up:
↓ 8
markjaquith — 5 years ago
What's your server setup? Can you set up a phpinfo() page for me to look at?
Also, could you add $_SERVER['REQUEST_URI'] to the list of things echoed in your debug code? Something seems off there.
Here is the phpinfo() page for you
And here's the output for $_SERVER['REQUEST_URI'] (on /blog/2007/12/)
/blog/index.php?year=2007&monthnum=12
On a paged page (/blog/page/2/) the output is:
/blog/index.php?&paged=2
And on the first page of the blog the output is:
/blog/index.php
If you need any more details just ask
I should explain that my blog is using the verbose rewrite rules as the usual rewrite rules supplied with WordPress don't work
And my permalink structure is /%year%/%monthnum%/%postname%/
A list of PHP variables can be found here
markjaquith,
Have you been able to do any work on this?
As it has been nearly a week since the last reply.
I have now disabled canonical redirects, as it may soon start to effect my page rank
comment:9
follow-up:
↓ 10
Denis-de-Bernardy — 4 years ago
- Component changed from General to Canonical
still current?
comment:10
in reply to:
↑ 9
roganty — 4 years ago
Replying to Denis-de-Bernardy:
still current?
Short answer: I don't know!
Long answer: Since I first reported this I have changed webhosts, and I don't get the problem.
It was something to do with the way that the webserver was setup.
I did discover what was causing the problem, it was something to do with the request_uri variable being the same as a another variable.
It's been a long time and I have since forgotten it!
I assume it's safe to close.
- Milestone 2.9 deleted
- Resolution set to worksforme
- Status changed from new to closed
let's close, then

Ok, I've just noticed this, but its also doing it for pages
For example:
/blog/page/2/