Opened 15 years ago
Last modified 3 months ago
#13554 reopened defect (bug)
WordPress MU canonical link redirect failure
Reported by: | rundi | Owned by: | markjaquith |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 2.9.2 |
Component: | Bootstrap/Load | Keywords: | needs-patch needs-testing needs-unit-tests |
Focuses: | multisite | Cc: |
Description
This problem manifests itself in Wordpress MU 2.9.2, but not in Wordpress 2.9.2.
In the MU install where blogs are subdirectories, canonical redirects work correctly for the subdirectory blogs, but not for pages on the root blog.
For example, http://silverwarethief.com/essays/ is a sub-blog in the wordpress MU install. If you alter that link to http://www.silverwarethief.com/essays/ wordpress MU will correctly redirect the browser to the canonical url.
However, this does not work with pages on the root blog. http://silverwarethief.com/about/ is a page on the root blog. If you go to that link, you will correctly find yourself at the "About" page. If you then alter the link to http://www.silverwarethief.com/about/ you will be redirected to the main page of the root blog, not the "About" page.
I have seen this behavior manifested on more than one MU install.
Change History (17)
#2
in reply to:
↑ 1
;
follow-up:
↓ 3
@
15 years ago
Replying to nacin:
Are you able to reproduce this in 3.0? Try both single-site and multisite.
I have not yet tried installing 3.0. I will try to make some time to test this issue with 3.0 on a local server. If anyone else has already tested this on 3.0 I would be interested to hear about it.
#3
in reply to:
↑ 2
@
15 years ago
Replying to rundi:
Replying to nacin:
Are you able to reproduce this in 3.0? Try both single-site and multisite.
I have not yet tried installing 3.0. I will try to make some time to test this issue with 3.0 on a local server. If anyone else has already tested this on 3.0 I would be interested to hear about it.
Okay, to answer Nacin:
I just installed 3.0 on my local server. Canonical links are improved, but there is still a problem.
What now works on 3.0 Multisite:
http://www.domain.com/blogpage/ now correctly redirects to http://domain.com/blogpage/
What still does not work on Multisite:
http://www.domain.com/blogpage does not correctly redirect to http://domain.com/blogpage/ Instead, the browser is redirect to the main page of http://domain.com. The inclusion of www and the failure to include the trailing slash in the url is what still causes this.
I did check the url redirection in single-site, but now can't remember if I specifically tested out the absence of the trailing slash when using www. In any case, it appears there is a problem in the multisite canonical url redirect.
#5
in reply to:
↑ 4
@
15 years ago
Replying to nacin:
Is there anything that works in MU that does not work in MS?
"Anything" is pretty broad...having just installed MS within the last hour, I couldn't honestly answer that. I certainly expect that when MS is out of beta it will do all that MU currently does, but I don't know where the current beta is at.
If you were simply talking about canonical url redirection--as I said above, MS appears to be better than MU, but still with a minor bug in redirecting one url instance.
#6
@
15 years ago
- Component changed from Canonical to Multisite
- Milestone changed from MU 2.9.x to 3.1
In terms of multisite, the current beta is considered complete. The merge was done months ago and there are no outstanding multisite bugs.
I can't think of any regressions -- and yeah, I was specifically referring to canonical URL redirection, so thank you for clarifying.
At this point, I'm going to move this to 3.1, so we can look at the remaining redirection bug there. Sounds like it would be solved if we ever improve www handling.
Thanks for your help.
#7
@
15 years ago
Thanks for moving this along.
On a domain I was trying to implement WP MU there was printed material related to the domain (printed books) that referenced pages with the www.domain.com/page link structure, (without the final trailing slash,) so it was important that those links (if typed into the browser) actually brought the reader to the correct page. So, I'll look forward to that final multisite bug being resolved.
I'll keep an eye on this and see how things go.
#8
@
14 years ago
The request is probably being picked up by the no blog redirect & handled as a 404 without the slash on the end of the URL.
#9
@
14 years ago
- Keywords needs-patch added
- Milestone changed from Awaiting Triage to Future Release
#10
@
11 years ago
- Milestone changed from Future Release to 3.7
Have not yet tried to reproduce, though it seems like something that may have a decent chance of working 3 years later.
Moving to 3.7, we should be able to clear this up or at least figure out what's going on.
#12
@
11 years ago
- Milestone changed from 3.7 to Future Release
Spoke with jeremyfelt, consensus was punt. Too easy to cause major problems with canonical changes late in a cycle.
#14
@
9 years ago
- Milestone Future Release deleted
- Resolution set to worksforme
- Status changed from new to closed
No movement in 2 years, and no one has replicated it in at least 5 years. Closing as worksforme. Feel free to reopen if steps to reproduce can be provided.
#15
@
9 years ago
- Keywords needs-testing added
- Milestone set to Future Release
- Resolution worksforme deleted
- Status changed from closed to reopened
There may likely be a valid bug here, just one that is very unlikely for anyone to run across.
We started to dig into this during the 3.7 cycle, but have not looped back around since. It would be great if someone could dig in and explain why this is or isn't an issue.
#16
@
5 years ago
- Summary changed from Wordpress MU canonical link redirect failure to WordPress MU canonical link redirect failure
Unfortunately, this old bug seems to be happening to me with latest WordPress.
Setting WordPress MU in a subfolder https://themesgenerator.com/tg/forums/ seems to work, but if I try the MU in the root folder https://themesgenerator.com/, the redirects will stop working.
I have tried in two different hosting provider and the problem happens in both of them.
Are you able to reproduce this in 3.0? Try both single-site and multisite.