Multisite www gets treated as a subdomain

[Ipstenu]

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]

[SergeyBiryukov]

Related: ​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2014-04-17&sort=asc#m835815

[jeremyfelt]

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.

[jeremyfelt]

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.

[jeremyfelt]

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

[nacin]

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

[jeremyfelt]

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.

[jeremyfelt]

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

[beccawitz]

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

[Ipstenu]

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.

[beccawitz]

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

[swordspres]

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.

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

[beccawitz]

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

[mikemanger]

Change www. check to Yoda conditional

[nacin]

In 28280:

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

props jeremyfelt.
fixes #27927.

[nacin]

In 28281:

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

Merges [28280] to the 3.9 branch.

props jeremyfelt.
fixes #27927.