brentrv

Right, but there is no need to have the options table locally, it will work just as well on the remote database (so long as the prefix is different), then we avoid any problems with managing different connections (connections to multiple databases might be easier than I’m assuming, I haven’t tried it) If blog2 can access the database on blog1 machine for the post and comment data, it can read the blog2_options table from there as well(assuming appropriate permissions).

If we really want connections to two databases. I believe we have to go to wp-db.php and add a new function wpdb2 that will make a connection to the new database, and make sure it gets initialized along with wpdb. We would then have to change references to wpdb to wpdb2 where applicable, test it, find out it doesn’t work, and go back through and see what we forgot!

Can you put both options tables in the same database? Just change the prefix on one (or both) As RustIndy said “In each site’s “wpconfig.php” file, set the table prefix to some unique value, other than the default “wp_” value.” If you hard code the other tables, this prefix will only be read when accessing the options table.

For example your database would have the following tables:

posts
users
categories
post2cat
comments
links
linkcategories
postmeta
blog1_options
blog1_options

then in blog1 wpconfig.php (line 9ish) you would have:
$table_prefix = ‘blog1_’;

and in blog 2 wpconfig.php you would have:
$table_prefix = ‘blog2_’;

and both wp-settings.php would have:
$wpdb->posts = ‘posts’;
$wpdb->users = ‘users’;
$wpdb->categories = ‘categories’;
$wpdb->post2cat = ‘post2cat’;
$wpdb->comments = ‘comments’;
$wpdb->links = ‘links’;
$wpdb->linkcategories = ‘linkcategories’;
$wpdb->options = $table_prefix . ‘options’;
$wpdb->postmeta = ‘postmeta’;

Note the only table using $table_prefix is the options table.

I’m currently running a similar setup on my site (http://www.plogress.com) with over 500 blogs. The only common tables are the user table and categories table. Unfortunately, the database has over 2,000 tables! I’m now hacking everything to share all of the same tables and use a blog id to separate each blogs data. Once it’s running properly and tested, I’ll make a seperate post here to describe it in more detail.

Hope this helps (exept that last paragraph, I don’t recommend trying that one at home)

I stumbled on one spot last night that concerned me, in /wp-admin/profile.php, around line 74:

$newuser_lastname = wp_specialchars($_POST[‘newuser_lastname’]);
$newuser_nickname = $_POST[‘newuser_nickname’];
$newuser_nicename = sanitize_title($newuser_nickname);

$newuser_nickname is the only variable not cleaned (as far as I can tell). I changed mine to:

$newuser_nickname = wp_specialchars($_POST[‘newuser_nickname’]);

I tried to exploit it myself before making the change, however, and was unsuccessfull.