Upgrading to WordPress 3.0 and Adding Multi-Site
Posted on June 19, 2010 by snipe in Featured, PHP/mySQL
This post was published 1 year 7 months 7 days ago. There is a chance that some APIs or software versions discussed have changed since this article was written. WordPress 3.0, code name “Thelonious”, has been released, and it brings multi-site functionality as part of the core. As someone with far too many blogs of my own, I thought this would be a great time to start switching them all over, and let you know what you’re in for if you choose to do the same.
Previously, if you wanted to run multiple sites from one core installation of WordPress, you would install WPMU.
I had tossed that idea around a lot over the past year, since I run several websites that run on WordPress, but I had heard from enough people who ran into plugin/MU conflict issues that made things go ‘splody ‘splody that I opted not to. So instead, every time a new version of WordPress came out, I’d end up upgrading around 20 installs. Blech.
With version 3.0 of WordPress, the ability to create multiple sites using one install of WordPress is built right into the core, so no need to fool around with WPMU. The temptation was too great this time, so I decided to give it a whack. It was not what I would call a smooth process, but it wasn’t terrible either.
STOP: If you are already running WPMU and you just want to figure out how to upgrade your existing WPMU sites to WordPress 3.0, you’re reading the wrong article. Try this one instead.
Goals
What I wanted to get out of this was to have one main core install, but run multiple sites on their own domains that all pulled from that main core, so upgrading to later versions would mean upgrading one core instead of a dozen or two. These properties remaining at their current separate domain names (such as www.crankyhaiku.com, www.geekhaiku.com etc) was critical, both because of search engine optimization and for branding reasons.
Upgrading
The normal upgrade part was flawless, as WordPress upgrades tend to be these days. Automatic upgrade has never quite worked for me, so I always do a manual upgrade. It takes longer to upload the files, but it’s a pretty painless process. So to upgrade to 3.0, I did the usual:
- backup (which I didn’t actually have to do, since I automatically backup to the Amazon Cloud every night using Automatic WordPress Plugin) but I’m paranoid
- delete the wp-admin directory
- delete the wp-includes directory
- upload everything in the WordPress package – except for wp-content – to the web root
- hit the upgrade script to trigger the database updates
Flawless, as usual. Not so much as a hiccup. Now came the trickier part – adding the “Network” functionality previously available in WPMU to start to consolidate sites.
Creating a Multi-Site Network
I can’t speak for how easy or difficult this normally was with WPMU, so unfortunately I can’t tell you how this process compares to a normal WPMU setup. It wasn’t awful, but it was definitely buggy.
The WordPress documentation on Creating a Network walks through the basics well enough, so I suggest you start there so you know what to expect.
Note: You will not be able to go through the wizard in your WordPress admin until you deactivate ALL of your plugins. You can obviously re-enable them later, but I found that many of them did not keep their original settings.
I suspect this might be because I chose “network activate” instead of just plain “activate”. I had wanted to make those plugins available for all sites in the network, and didn’t realize that it would wipe out my existing snipe.net settings when I did so. Oh well. (Incidentally, that explains why you might see some weird stuff on the site until I have a chance to go through everything one by one. Double “related posts” bits at the end of the articles, Apture wasn’t working, etc.) All of the settings are fixable, but it may take you a little time to figure out what’s been lost, and what you have to do to set it back to the way it was before.
Editing Your wp-config.php
Beyond the setup in your WordPress admin, you’ll need to make a few changes to your wp-config.php file and your htaccess file. I hadn’t updated my wp-config for several versions, so I decided to use the wp-config-sample.php file and just pull my existing database variables over. Whether you use your old wp-config.php or start fresh with the stock WordPress sample, you’ll need to add the following to your wp-config.php, just above the comment that says “/* That’s all, stop editing! Happy blogging. */”
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'www.yoursite.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
If you followed my suggestion and read the WordPress documentation on creating a network (you did read that, right?), you’ll see that you have two choices for how your network will be set up: sub-domain (blah1.yourdomain.com, blah2.yourdomain.com) or directory-based (yourdomain.com/blah1, yourdomain.com/blah2). Make sure you think this one through before you get started, since there doesn’t seem to be an easy way to switch between the two.
As I mentioned, I didn’t want my sites to live at subdomain.snipe.net, or snipe.net/blogname – I wanted them to live at their own urls. I also didn’t want a bunch of crap littering up my document root. The easiest way to do this on Rackspace Cloud Sites is through a combination of setting up a site alias, and using mod_rewrite to handle domains:
- Set up a domain alias, like secondblog.com, and point it to originalblog.com
- Modify the mod_rewrite rules in your htaccess access file
- In your site preferences, point the blog url to the aliased domain name
If you’re not on Rackspace Cloud Sites, you can just follow the directions in the WordPress documentation.
Tweaking Your .htaccess
You’ll need to make sure the bit below is in your htaccess file – but your WordPress Network Setup wizard will point that out to you anyway
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule . index.php [L]
One thing to look out for besides having to reset your plugin preferences: when I created my Network, setting this site as the default, it automatically tried to set the url as snipe.net/blog. I’m not sure why it did this, and I’m certain I didn’t add it anywhere, but when I committed the changeover to Network, all of my urls were broken (since snipe.net/blog/ doesn’t exist). It was a quick change that you can handle via the Settings menu, but watch out for it and be sure to test your links once you’ve made the switch.
Importing Blogs
Now that you’ve got a Network set up, you have actually add them to the Network so that they’re using the same core. I expected this to be a much bigger pain in the ass than it ended up being. All I had to do was go to the original admin, go to TOOLS > EXPORT and download the XML file. Then go into my WordPress 3.0 admin, select the site I wanted to admin, and go to TOOLS > IMPORT > WORDPRESS, and upload the XML file. Worked perfectly, so far as I can tell.
Security Notes
Consolidating all of your WordPress sites into one multi-site install has many benefits, the most obvious one being that it’s easier to maintain one core install than updating every single instance of WordPress you run. That said, you may want to consider a few things:
While one install is probably more “secure” than multi-installs in the real world simply because you’re more likely to keep one site updated than dozens, there are a few things to consider.
If you run multiple WordPress blogs under the same user (the same account, in Rackspace Cloud Sites), all of the files are owned by the same linux user and group. This means that if one of your WordPress installs ends up compromised, either because you forgot to upgrade one of them, or because of a vulnerability in your hosting company, once an attacker has access to one of your blog installs, they have access to any other files owned by that user. Which means all of your other blogs, even the ones that are running current WordPress versions.
Along this same line of thought, if you’re running multiple WordPress installs under different users and you end up consolidating them to take advantage of the multi-site functionality, do so understanding that in this scenario, all of your blogs will be owned by the same user/group in the same webspace, so one vulnerability could easily turn into a much bigger problem.
Conversely, tracking down backdoors and maliciously modified files could potentially be easier, since you have fewer installs to search through.
WordPress has been much better about quickly patching holes, and being proactive about finding vulnerabilities. If your site ends up getting hacked, these days it’s more likely to be a vulnerable plugin, an outdated install you forgot all about, or a PC virus that added your FTP login to a botnet – not the core WordPress install itself. I say this with a certain amount of confidence, since I have restored at least two-dozen hacked WordPress sites (not mine) since the beginning of the year, and have therefore spent countless hours investigating the attack, identifying the vector, and writing up summaries to post to badwarebusters.org in an effort to help other people facing the same hack.
To be clear, running a multi-site install isn’t any riskier than running multiple blogs under the same user. But if you’re currently running your blogs under different users, you should at least be aware of how that could potentially impact you.
Final Thoughts
My thought is that it might have been smarter to install WPMU, and then upgrade to 3.0, since the upgrade process for a WPMU setup to 3.0 seems like it was a little less wonky, but I don’t really know.
I’ve really only just started playing with this during the fragment of free time I had today (work has been brutal for the past month or so). So far, pulling the theme in has been as simple as downloading them from their respective old WordPress installs and uploading them to the new 3.0 themes directory and activating them so that they’re available to the rest of the sites in the network.
And certainly, if you’ve found an easier way to get this done, please let me know in the comments.
Also check out:
If you think this article kicked ass, subscribe to the RSS feed or follow me on Twitter! Share with your friends, or leave a comment below (or better still, do both!) My entire concept of self-worth is in your hands, so that makes you kind of a big deal. Srsly.






Pingback: Upgrading an AT&T Blackberry Curve to OS 4.5 | World's Mobile