WordPress MU canonical link redirect failure

[rundi]

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.

[nacin]

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

[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.

[rundi]

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.

[nacin]

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

[rundi]

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.

[nacin]

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.

[rundi]

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.

[wpmuguru]

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.

[jeremyfelt]

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.

[wonderboymusic]

Any updates?

[nacin]

Spoke with jeremyfelt, consensus was punt. Too easy to cause major problems with canonical changes late in a cycle.

[chriscct7]

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.

[jeremyfelt]

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.

[genweb]

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.

[jorbin]

If there is a desire to move this forward, automated tests which demonstrate the bug would be extremely helpful.

[juanmaguitar]

Reproduction Report

Description

Tested canonical redirect behavior in subdirectory-based multisite when accessing root blog pages with www prefix and no trailing slash. Cannot reproduce the reported bug in trunk.

Environment

• WordPress: 7.0-alpha-61498 (trunk)
• PHP: 8.2.30
• Server: Apache 2.4.62 (via @wordpress/env)
• Database: MySQL 8.0 (via Docker)
• Browser: Chrome 133 / Firefox 123
• OS: macOS 14
• Multisite: Subdirectory-based network
• Theme: Twenty Twenty-Five (default)
• Plugins: None activated

Test Methodology

Set up a fresh subdirectory multisite installation using standard WordPress Multisite .htaccess rules with:

• Root blog with "Sample Page" at /sample-page
• Subsite at /essays/
• Pretty permalinks enabled (/%postname%/)
• Custom domain domain.test:8888 with www.domain.test in /etc/hosts to test www vs non-www canonical redirects

Tested all URL combinations for both root blog pages and subsites using browser Developer Tools (Network tab) to observe HTTP status codes and redirect chains.

Actual Results

Cannot reproduce - Error condition does NOT occur in trunk.

All 6 test cases pass correctly:

Test	URL	Expected	Actual	Status
1	http://domain.test:8888/sample-page/	200 OK	200 OK ✅	Pass
2	http://domain.test:8888/sample-page	301 → /sample-page/	301 → /sample-page/ ✅	Pass
3	http://www.domain.test:8888/sample-page/	301 → non-www	301 → non-www ✅	Pass
4	http://www.domain.test:8888/sample-page	301 → non-www with /	301 → non-www with / ✅	Pass
5	http://www.domain.test:8888/essays/	301 → non-www	301 → non-www ✅	Pass
6	http://www.domain.test:8888/essays	301 → /essays/	301 → /essays/ ✅	Pass

Test case #4 (the primary bug): Accessing http://www.domain.test:8888/sample-page (www + no trailing slash) correctly redirects to http://domain.test:8888/sample-page/ and displays the Sample Page content. It does NOT redirect to the homepage as originally reported.

Additional Notes

• The canonical redirect logic appears to be working correctly in trunk for subdirectory multisite setups
• This suggests the issue may have been resolved in a recent WordPress version
• Testing against WordPress 6.7, 6.6, and earlier versions would help identify when/if this bug was fixed

Reproduction Steps

1. Add domains to /etc/hosts:

sudo bash -c 'cat >> /etc/hosts << EOF
127.0.0.1 domain.test
127.0.0.1 www.domain.test
EOF'

2. Create .wp-env.json:

{
  "core": "WordPress/WordPress",
  "phpVersion": "8.2",
  "port": 8888,
  "mappings": {
    ".htaccess": "./.htaccess"
  }
}

3. Create .htaccess (​standard WordPress Multisite subdirectory rules):

# BEGIN WordPress Multisite
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
# END WordPress Multisite

4. Install multisite:

# Start environment
wp-env start

# Install multisite (subdirectory-based) on localhost
wp-env run cli wp core multisite-install \
  --url=http://localhost:8888 \
  --title='Multisite Canonical Test' \
  --admin_user=admin \
  --admin_password=admin \
  --admin_email=admin@example.com \
  --skip-email \
  --subdomains=0

5. Switch to domain.test and create test content:

# Switch from localhost to domain.test across all tables
wp-env run cli wp search-replace \
  'localhost:8888' 'domain.test:8888' \
  --network \
  --url=http://localhost:8888

# Create test subsite
wp-env run cli wp site create \
  --slug=essays \
  --title='Essays Subsite' \
  --email=admin@example.com \
  --url=http://domain.test:8888

# Enable pretty permalinks
wp-env run cli wp rewrite structure '/%postname%/' \
  --hard \
  --url=http://domain.test:8888

6. Test in browser:

Open browser Developer Tools (F12) → Network tab and test each URL from the table above.

Suggested Next Steps

1. Test against WordPress 6.7 (latest stable) to confirm the fix is in production
2. Test against older versions (6.0-6.6) to identify which version introduced the fix
3. If the bug exists in older versions, consider backporting the fix or documenting the resolution

[juanmaguitar]

Closing this issue because I haven’t been able to reproduce it, and given how old the report is, it’s unlikely we’ll get a response from the original reporter.