[wp-trac] [WordPress Trac] #13554: WordPress MU canonical link redirect failure

WordPress Trac noreply at wordpress.org
Mon Jan 19 14:58:25 UTC 2026


#13554: WordPress MU canonical link redirect failure
------------------------------------------+--------------------------
 Reporter:  rundi                         |       Owner:  markjaquith
     Type:  defect (bug)                  |      Status:  reopened
 Priority:  normal                        |   Milestone:
Component:  Bootstrap/Load                |     Version:  2.9.2
 Severity:  normal                        |  Resolution:
 Keywords:  needs-patch needs-unit-tests  |     Focuses:  multisite
------------------------------------------+--------------------------
Changes (by juanmaguitar):

 * keywords:  needs-patch needs-testing needs-unit-tests => needs-patch
     needs-unit-tests


Comment:

 == 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` ([https://developer.wordpress.org/advanced-
 administration/server/web-server/httpd/#multisite 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 at 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 at 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

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/13554#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list