WordPress.org

Make WordPress Core

Opened 7 years ago

Last modified 18 months ago

#13554 reopened defect (bug)

Wordpress MU canonical link redirect failure

Reported by: rundi Owned by: markjaquith
Milestone: Future Release Priority: normal
Severity: normal Version: 2.9.2
Component: Bootstrap/Load Keywords: needs-patch needs-testing
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 (15)

#1 follow-up: @nacin
7 years ago

Are you able to reproduce this in 3.0? Try both single-site and multisite.

#2 in reply to: ↑ 1 ; follow-up: @rundi
7 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 @rundi
7 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.

#4 follow-up: @nacin
7 years ago

Is there anything that works in MU that does not work in MS?

#5 in reply to: ↑ 4 @rundi
7 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 @nacin
7 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 @rundi
7 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 @wpmuguru
7 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 @nacin
6 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Triage to Future Release

#10 @jeremyfelt
4 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.

#11 @wonderboymusic
3 years ago

Any updates?

#12 @nacin
3 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.

#13 @jeremyfelt
3 years ago

  • Component changed from Multisite to Bootstrap/Load
  • Focuses multisite added

#14 @chriscct7
18 months 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 @jeremyfelt
18 months 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.

Note: See TracTickets for help on using tickets.