WP 3.0 recognizes $table_prefix, confirmed by Ron Rennick.
So WordPress has two ways to do multi-site in WP 3?
1. The original way, before WordPress MU. Requires no plugin. Works out-of-the-box, just change $table_prefix for each new blog in wp-config.php. I believe the instructions in wp-config.php are self-explanatory, but there’s more information in the codex if you need it. This is what I use here with 9 blogs. This is what I recommend if you want a small blog network without too much complexity.
People will tell you this way requires multiple WordPress installations but that’s not true. You can configure your web server to use the same directory for all of your domains. One install. So if you change your theme, as you normally would with one blog, your changes are automatically visible on all of your blogs! If you want to see my Nginx config, ask me–I will show you how to do this with Nginx.
By the way, Nginx is faster than Apache. It takes less than 1/100th of a second for Nginx to serve this blog. Do the math. I’m sure it’s possible to do one-install multi-site with Apache too, but if you look at the growth of Nginx it’s clear to me the future is Nginx. So why bother with (slower) Apache?
Nginx, the little Russian web server taking on the giants | Royal Pingdom
If you look at growth in terms of percent, nginx has been crushing every other web server out there. In terms of absolute number of websites, nginx added 12.9 million websites in 2009. It even kept pace with Apache’s overall growth for most of the year, some months even surpassing it. As a comparison, Apache grew by 13.3 million websites in 2009.
Also, I have seen tutorials to do Multisite with symlinks. This is possibly an option if you don’t have access to your webserver config, for whatever reason.
But think about it, VPS hosting is affordable now. VPS hosting not only gives you access to your webserver config (to make your blogs faster than ever) but you also get access to your PHP config and MySQL config!
2. The “MU” way. The official name is “Multisite” now and an entire forum is devoted to it.
What was MU? I believe it was created to build big blog networks of user-generated content–similar to Tripod, Geocities, Myspace, etc.
A terminology nightmare: blogs, sites, networks, and the super admin | Andrew Nacin
MU, or multi-user, was a fork of the codebase designed for many blogs and many users, all on one install.
Here’s a list (Thanks to Mike Schinkel) of schools using Multisite:
http://blogs.law.harvard.edu/
http://umaine.edu/
http://blog.usf.edu/
http://blogs.mcgill.ca/
https://blogs.bgsu.edu/
http://ucalgaryblogs.ca/
http://umwblogs.org/
http://blogs.ubc.ca/
http://www.apu.edu/blog/
http://blogs.fu-berlin.de/
http://blogs.unimelb.edu.au/
I only had time to look at the Harvard link. They keep the riffraff out by requiring a Harvard email address. Hey Harvard, hook me up with a blog ;-)
I admit there are some good arguments for building big user-generated blog networks. Brad Feld even suggests people are more motivated to produce when there’s no payment for the work involved. It’s a complex subject and I don’t want to get too sidetracked.
I mostly passed on WordPress MU because it’s extra code I don’t need. Generally speaking, I believe less code is better.
So MU is now merged into the core of WordPress. However, as far as I can tell, Multisite is entirely optional and not turned on by default. Looking forward, I don’t think we know yet how Multisite incorporates networks of blogs created using $table_prefix, without MU.
I intend to keep the “$table_prefix method” alive as long as possible, as long as it makes sense to.
The $table_prefix method does have weak points. Using $table_prefix for multiple blogs you have two options tables! In a way, this is a good thing. On newer blogs I’m a little more attentive–I want email notifications when I get a comment. But on my most popular blog I don’t want email notifications, because there is no way I could keep up with the crazy questions. On the other hand, you probably don’t want to maintain multiple moderation/spam keyword lists.
Update: I discovered Multisite has similar options-related weaknesses. So there’s no escaping it.
A terminology nightmare: blogs, sites, networks, and the super admin | Andrew Nacin
A lot of discussion centered around the options API. There are no options across an entire MU multi-domain install, but we still thought about that and it caused plenty of confusion. We also considered get_sitewide_option(), get_domain_option(), get_multisite_option(), and yes, even get_thingieswide_option(). In despair, one suggestion was thing, thingy, and thingies, to replace blog, site, and network.
As far as options management for my $table_prefix network, I wrote a plugin to help maintain multiple options tables. It’s really straightforward and there’s no “super” admin, subdomain admins, etc. I call it oSync. It essentially duplicates options from a “master” blog you choose–probably the one you use most often. Let’s say Domain1.com is the master and you’re in Domain2.com’s admin panel–oSync compares Domain2’s options with the master and shows you the difference. One click changes each option. It actually says something like, “This option is now X, but could be Y.” It needs a little more work before I can release it. If you want this plugin, let me know.