Snipe.Net - Geeky Stuff
Twitter
Currently: @MegaRan I'm more of a BF3 gal, sorry :( in reply to MegaRan 1 hr ago

Upgrading to WordPress 3.0 and Adding Multi-Site

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

This entry was posted on Saturday, June 19th, 2010 at 1:09 am and is filed under Featured, PHP/mySQL. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
  • Pingback: Upgrading an AT&T Blackberry Curve to OS 4.5 | World's Mobile

  • Achoke

    I followed your guide, and the following guide (http://wptheming.com/2010/03/wordpress-3-0-enab…).

    I was able to modify wp-config.php and create .htaccess

    I also created the blogs.dir directory.

    I have created 4 other sites, but I cannot access the front or backend of any of these 4 additional sites. Any thoughts?

  • http://www.snipe.net snipe

    What happens when you try to access them?

  • Achoke

    404…

  • Achoke

    A little more history of my setup/install/etc….

    I originally followed the following two guides to install WordPress 2.something on my Windows Home Server:

    PHP ON WHS
    WordPress on WHS

    I tried to upgrade to 3.0 – automatically. I modified wp-config.php to allow multi sites, then followed wordpress's instructions. I created .htaccess with the recommended code, modified wp-config.php to remove the original allow multi sites and added code from wordpress instructions, and then finally created blogs.dir in wp-content.

    After the upgrade, I could not view the front-end or back-end of any of the secondary sites that I tried to create.

    I then figured it was a problem because of the upgrade. I created a new SQL database, and then deleted my entire WordPress directory. I downloaded 3.0 fresh and pushed that in the place of the previous wordpress directory. I opened up my blog in a Firefox and configured it to use my newly created database. I was again able to modify all settings to allow multiple sites, but I still cannot access the front-end or back-end of any secondary sites that I create.

  • Achoke
  • http://www.snipe.net snipe

    Ahhh – I'm nto sure, I've never worked with Windows Home Server. I have some things to do today, but will try to see if I can figure anything out.

  • Achoke

    thanks for any help…

    I realized a greater problem, which may fix my multiple site issue…

    When I try to access my External URL of wordpress from outside my webserver's network “Http://blahblahblah.homeserver.com/blog” it redirects to my internal URL “http://servername”

    Is .htaccess messed up? Kidna stumped…sorry for flooding your comments.

  • Althalos

    Are you sure that your wildcard setting is correct? Because this is exactly what happened for me before I had wildcard subdomains… when I corrected the DNS-setting, however, the error changed into “Service unavailable” which isn't much better. And I'm stumped at that point.

  • http://wpmututorials.com Andrea_R

    For changing between install types, you can actuallt edit this line:
    define( 'SUBDOMAIN_INSTALL', true );

    True is for subdomains, false is for folders. Don't do this if you've already set up other sites, it'll mess them up.

    For top-level domains, just get the domain mapping plugins and avoid the rewrites.
    http://wordpress.org/extend/plugins/wordpress-m…

    Running a network isn't for your average blogger, hence the hurdles to set it up. If you can handle that, you can handle running it. ;)

  • http://www.snipe.net snipe

    The plugin is nice, but it uses additional database calls. If you're on a slower server, or a hosted environment where you pay for CPU cycles (such as Rackspace Cloud Sites, as we are) it makes a lot more sense to set up the rewrites than to require additional, unnecessary database requests.

  • http://www.jesseluna.com jesseluna

    Great guide! I have several blogs installed under one domain name (http://www.mydomain.com, http://www.mydomain/blog2, mydomain.com/blog3). If I wanted to start a whole new set of blogs under http://www.mydomain.com, should I worry about blog2 and blog3 being affected by the update? The site is on a regular virtual Web hosting server and I'm trying to be frugal and keep everything under one hosting account.

  • http://www.snipe.net snipe

    That's an excellent question. I wouldn't think it should affect them, as long as you don't overwrite the existing ones. Just make sure you back everything up before you try, just in case ;)

  • theD

    After setting up different domains, I can only access the backend of these domains if they have add a different site_id in the wp_blogs table. Also, no uploading of media works. My subdomains work fine, but not the different domains.

  • Dan

    Nice one Snipes! Just got my network going on rackspace thanks to this.

    One other problem I has was could not login to backend on secondary sites.

    This fixed it http://wordpress.org/support/topic/404711?repli… (second post not first)

  • Devin

    Hi Snipes, this is a great post. I am using cloud sites and setting up the network feature as this post describes. I am a little confused on the domain mapping part. I understand how to do the alias set-up in my cloudsites admin, but I can't seem to figure out the mod_rewrite part.

    Are you saying in your post that you can set up multiple domains pointing to multiple network blogs?

    Thanks in advance for your feedback!

    -Devin

  • Devin

    A better question for me is what is the code to map all the domain aliases to the network subdirectories in the htaccess file?

    Thanks!

  • http://www.iva-is.me Iva

    Same goes to Servage, where the popular amongst my sites is.

    The only thing I'm concerned about here is how to ignore many directories that have absolutely nothing to do with WP.

  • http://twitter.com/JoshMiller Josh Miller

    I’ll have to look into this as this may be what I’ve been looking to do for a while with my site. Essentially what I’d like t do is have one core site (www.) then use subdomains to segment the same content off with different layouts and such generally based on tags or categories.

    I guess the question is, is this the sort of functionality we’re talking about here? My understanding of how it all works is decent but somewhat generic, I would think though that accessing the same content database so to speak in this way would be possible.

    • http://www.snipe.net snipe

      Can you give me a more specific example of what you’re trying to do? Normally if I’m trying to change layout based on tags or caregories, I’ll use a custom template in the page/post, or handle the logic in the single template.