November 22, 2012 at 11:35 am #1285
Is it okay to modify a setting on my Multisite for the Site URL of http://domainname.com to http://www.domainname.com? I honestly can’t find where this setting is now. I restored this site to a test area that was a NON multisite. I converted it to Multisite. Before converting it to Multisite I had changed this from a “www” to just an http://domainname.com.
The text widgets have a path for links that go to a “www…..” version of the link and it won’t resolve it without this being removed. Of course I don’t want to modify the paths. So where can I change this back to “www” or will I really break the whole Multisite doing this?
Please let me know, thanks!
CKNovember 22, 2012 at 10:54 pm #1322
It would be a big mistake to run WP MS with ‘www’ so you shouldn’t try to undo that. Wouldn’t it be easier to edit the links in text widgets? If you were really against doing that, you could create re-write rules that would redirect from the ‘www’ version of the link to the non-www. That would be more work and has slight negative SEO consequences, so you’d be better off to bite the bullet and fix the text widgets to match your current setup.
November 24, 2012 at 1:37 pm #1502
Can you please explain why this is the case that it shouldn’t be ran with ‘www’… yes I can just edit the links in the text widgets but I just would like to know why it can’t retain ‘www’ in the URL. Did I setup something wrong?
CKNovember 24, 2012 at 6:46 pm #1525
I’ll try. My explanation for the “why” things evolved the way they did is just my educated guess.
Note that wordpress.com, the biggest WP network out there, doesn’t run with ‘www’. The early history of WP MU (the predecessor name for what is now called WP multisite or a WP network) was developed with with more attention paid to non-www domains, in part because of wordpress.com. As far back as 2006, Matt Mullenweg wrote a plugin to further support non-www domains, so maybe that’s his personal preference and that preference impacted WP development.
Around WP 3.0 or so, discussion in the WP community changed to hold that you could setup a network with either www or non-www as the primary site in the network. But from my experience all of the code that could be impacted by that, especially on subdomain installs, wasn’t fixed and still isn’t fixed.
Here is one example. If you have your network of subdomains set up with ‘www’, visit Sites->All Sites when signed in as a network admin and search for a site on your network. You can use * as a wildcard. Even try searching for the exact subdomain. WP won’t find it, even though it exists. Try the test searching for a site ID, and it will find it. The reason for that search failing to work is because it is searching for yoursubdomain.www.yourdomain.com (which will never be found) instead of yoursubdomain.domain.com (which is how the data is stored). In other words, the ‘www’ that is there should have been stripped out for the search, but it wasn’t. It likely wasn’t stripped out (or better yet, checked to see if it had to be stripped out) because of the legacy of WP MS recommending non-www primary domains.
Site search works fine on a network of subdomains with no ‘www’. On a big network, being able to search for a site and find it is important. That’s just the first thing that comes to mind of something that breaks when you run a WP network with ‘www’ in the primary domain. You may run a network and never stumble on another one, but changing it down the road is more work than when your network is a relative infant. I’ve always just stuck with WP installation recommendations (which highly recommended not using ‘www’) from years past and avoided ‘www’ so I don’t have to change things later.
You must be logged in to reply to this topic.