WordPress.org

Make WordPress Core

Opened 12 months ago

Closed 12 months ago

Last modified 12 months ago

#27927 closed defect (bug) (fixed)

Multisite www gets treated as a subdomain

Reported by: Ipstenu Owned by: jeremyfelt
Milestone: 3.9.1 Priority: normal
Severity: normal Version: 3.9
Component: Networks and Sites Keywords: has-patch commit
Focuses: multisite Cc:

Description

To reproduce:

1) Install WordPress on a site as http://example.com (NO WWW!)
2) Activate Multisite as subdomains
3) Visit www.example.com

Instead of being redirected to example.com, you will end up at the signup page: example.com/wp-signup.php?new=www (or if you have a NOBLOGREDIRECT you go there).

www is special and shouldn't be treated as it's own subdomain. While this can be handled with a simple .htaccess redirect (see below), this strikes me as something we should be catching.

	RewriteEngine On
	RewriteBase /
	RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
	RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

Attachments (5)

27927.diff (715 bytes) - added by jeremyfelt 12 months ago.
27927.2.diff (1.9 KB) - added by jeremyfelt 12 months ago.
27927.3.diff (5.0 KB) - added by jeremyfelt 12 months ago.
27927.4.diff (5.6 KB) - added by jeremyfelt 12 months ago.
27927.4.1.diff (5.6 KB) - added by mikemanger 12 months ago.
Change www. check to Yoda conditional

Download all attachments as: .zip

Change History (26)

comment:2 @SergeyBiryukov12 months ago

  • Component changed from General to Networks and Sites

comment:3 @jeremyfelt12 months ago

  • Milestone changed from Awaiting Review to 3.9.1

Confirmed.

A request for http://www.domain redirects via 302 to http://domain/wp-signup.php?new=www. In a default configuration, www is picked up as an illegal site name. This initiates another redirect to http://domain/.

This is broken, but less irritating for home page requests where the intended content is still displayed. This is very broken for other URL requests, where http://www.domain/2014/04/20/hello-world/ redirects to http://domain/.

The only time you would see the signup form is if www was removed from the list of illegal site names.

In 3.8.3, a request for http://www.domain redirects via 301 to http://domain.

@jeremyfelt12 months ago

comment:4 @jeremyfelt12 months ago

Until 3.9, we would search for both www and non-www domains, find the site, and then let a redirect happen via redirect_canonical(). In 3.9, we use non-www and www when doing the network search, but not when doing the site search. A site is not found and redirect_canonical() does not happen.

I attached 27927.diff, but as I'm writing this up I'm realizing it does not work if the multisite install was done for the full www domain. Of course, creating a subdomain install on a www.domain does seem seem out of the ordinary...

We'll likely need to search for both www and non-www variants in get_site_by_path() to match previous behavior.

@jeremyfelt12 months ago

comment:5 @jeremyfelt12 months ago

  • Keywords has-patch added

27927.2.diff checks for www and searches for both variants in the domain if it exists. This adds a bit more complexity to get_site_by_path() as we now deal with:

  • domain, 1 path
  • domain + www, 1 path
  • 1 domain, multiple possible paths
  • domain + www, multiple possible paths

comment:6 @nacin12 months ago

  • Keywords needs-unit-tests added

Let's get some unit tests, in part to demonstrate proper behavior.

@jeremyfelt12 months ago

comment:7 @jeremyfelt12 months ago

27927.3.diff adds assertions to the existing get_site_by_path() tests for scenarios where a www. request should match a non-www domain and where a www. request should match a www domain.

comment:8 @ircbot12 months ago

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.

@jeremyfelt12 months ago

comment:9 @jeremyfelt12 months ago

  • Keywords needs-unit-tests removed

27927.4.diff adds more assertions for site lookups that will not return results.

comment:10 @ircbot12 months ago

This ticket was mentioned in IRC in #wordpress-dev by johnbillion. View the logs.

comment:11 @nacin12 months ago

  • Owner set to jeremyfelt
  • Status changed from new to assigned

comment:12 @beccawitz12 months ago

I am experiencing something very similar but without going to the www version.
Upgraded a multisite that is non-www and using subdomains to 3.9.
Using subdomains of subdomains. Ex. subsite.subdomain.domain.com.
When I tried to access that url, I got redirected to this url:
http://subdomain.domain.com/wp-signup.php?new=subsite with the message"Registration has been disabled".

Last edited 12 months ago by beccawitz (previous) (diff)

comment:13 @Ipstenu12 months ago

How is subsite.subdomain made? I'm assuming it's a real site, but is it a WP multi-network plugin or did you manually create them? If it's a plugin, which one?

Also, same I asked in your other ticket :) Can you look in your database under wp_site and wp_blogs. Does your domain have the www in there? I know you said this isn't a www site, but if things are out of whack, it gets weird.

comment:14 @beccawitz12 months ago

@ipstenu, The subsite.subdomain is made with the wildcard subdomain, no plugin.
I looked in the database under wp_site and wp_blogs and there is no www.

comment:15 @swordspres12 months ago

  • Version changed from 3.9 to 3.8.3

I had some headache with this problem so i can provide more details.

I have multisite on subdomains, each site has its own domain.

The problem is not started with 3.9 but with 3.8.3: after having restored a previous full backup with 3.8.3 with everything working, and having also added define( 'WP_AUTO_UPDATE_CORE', false ); in wp-config to avoid the auto update, in the night multisite was broken again. So i suspect that minor/security updates broke my network? Now i have restored again the same image (3.8.3) but added define( 'AUTOMATIC_UPDATER_DISABLED', true ); instead.

Any feedback is very appreciated as i have all my sites in this network.
Do you think it will work tomorrow with the define( 'AUTOMATIC_UPDATER_DISABLED', true ); rule?

Thanks

EDIT: while obvious, i add that upgrading the broken install from 3.8.3 to 3.9 doesn't fix the problem.

Last edited 12 months ago by swordspres (previous) (diff)

comment:16 follow-up: @Ipstenu12 months ago

@swordpres, that's a separate issue and unrelated to this (which is a noted change in 3.9, please don't change the version like that in trac unless you're sure). You should open a post in the support forum for multisite: https://wordpress.org/support/forum/multisite

@beccawitz - so you literally named a site site.subdomain ? I'm trying to understand how you made a sub-sub domain :) it may be related but different.

comment:17 @jeremyfelt12 months ago

  • Version changed from 3.8.3 to 3.9

comment:18 in reply to: ↑ 16 @beccawitz12 months ago

@Ipstenu I know it sounds weird but it's for a site that's in development which has a main site like mainstie.devdomain.com and the subsites are subsite.mainsite.devdomain.com if that helps. The subdomains have been created with wildcard subdomains and had been working fine until 3.9. Thanks for all your help.

Replying to Ipstenu:

@swordpres, that's a separate issue and unrelated to this (which is a noted change in 3.9, please don't change the version like that in trac unless you're sure). You should open a post in the support forum for multisite: https://wordpress.org/support/forum/multisite

@beccawitz - so you literally named a site site.subdomain ? I'm trying to understand how you made a sub-sub domain :) it may be related but different.

@mikemanger12 months ago

Change www. check to Yoda conditional

comment:19 @nacin12 months ago

  • Keywords commit added

comment:20 @nacin12 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 28280:

Multisite: Treat 'www' as a special subdomain, reversing 3.9 regression.

props jeremyfelt.
fixes #27927.

comment:21 @nacin12 months ago

In 28281:

Multisite: Treat 'www' as a special subdomain, reversing 3.9 regression.

Merges [28280] to the 3.9 branch.

props jeremyfelt.
fixes #27927.

Note: See TracTickets for help on using tickets.