Have I missed anything on this topic? -Kaf 23:26, 2 Jan 2005 (GMT)
as a quick & dirty hack: would it work to replicate the top level WordPress install directory for each blog, but have symbolic links to the subdirectories? this would avoid the bulk of the duplicate code. tia! -Bang 17:24, 20 Apr 2005 (UTC)
did a few tests. there are a dozen or so places in the wp-admin php code that refer to '../wp-config.php'. this always refers to the actual parent directory of wp-admin, even if wp-admin was loaded by way of a symbolic link.
it would be fairly simple to change all occurrances of '../wp-config.php' with something like:
$configPhp = str_replace("wp-admin/install.php","wp-config.php",$_ENV["SCRIPT_FILENAME"]);
require_once($configPhp);
would this be sufficient? or is this a can of worms? :-)
tia! -Bang 20:08, 20 Apr 2005 (UTC)
After thinking about this for a while, I have managed to get multiple blogs running with a small change to wp-config.php and no duplication of wordpress files. It's the most efficient and very easy way of setting up multiple blogs. Check out: http://chetan.gotdns.com/blog/?p=18
-- Thanks, Chetan
I have had problems either having multiple blogs in the same database or with different databases for each blog after upgrading to version 2.0. Settings for my blogs seemed to be merged depending on what blog I accessed first. I tracked it down to be an issue with caching, which then took e.g. the siteurl parameter from the cache ignoring the different subdomain (same IP by the way). I solved it for now by disabling caching completely in the wp-config.php file using define('DISABLE_CACHE', true);.
--A1X 20:57, 16 Jan 2006 (GMT)
File under Breaking News? WP/WPMU "merge" ... this is significant. see " @echnosailor's "WordPress and WordPress MU to Merge" and "WordPress and WordPressMU to merge" at GeekWord.net. -- bentrem 19:42, 3 June 2009 (UTC) ---
Should we direct users to a new page on creating or enabling the network features coming in 3.0? Andrea 4:53, 12 march 2010
I think it would make sense to have a new page, or at least a very prominant new section, at the top of other stuff (marked for 3.0). This stuff will all soon become legacy, it would be good to be able to easily repoint things. mrmist 23:17, 12 March 2010 (UTC)
Okay, everyone else may have moved on, but after installing dozens of WordPress sites, I'm trying to simplify life and move a few installations into a single database. On first reading it would appear that this is possible using the table_prefix. However, once WordPress is installed (several installations on different databases with, say, the default "wp_" as the prefix) if you want to change the table prefix, you also need to change the names of certain options.
This seems to make the table_prefix scheme less useful and prone to error -- as soon as someone comes up with an option that starts "wp_" that's unrelated to the table prefix there's no easy way to ensure that all the options that depend on the table prefix are renamed correctly.
I'm having a hard time explaining why this is a problem. As an example of a situation that couldn't be handled with multisite, I'd like to put Dev_ and Prod_ tables into the same database. And I really don't understand why that's such a terrible idea if using the Table_prefix allows multiple installations to run off one database. But maybe it doesn't really.