Virtual Multiblog 2.5

I’ve just released Virtual Multiblog for WordPress version 2.5. This has some significant bug fixes and other improvements. If you’ve had trouble getting it to work in the past, I’ve reworked the code that determines which blog is active, and I think this will help a lot of people.

A major improvement in this version is the way it handles defaults. Now you can set up defaults in the autoconfig file, and put just the differences into blog-specific config files. For example, if all your blogs use the same database, you can set the database info one time in mb-autoconfig.php, and then make blog-specific config files that only contain the table-prefix and nothing else.

If you are upgrading, from a previous version, please note the following instructions:


1) Upload the new multiblog folder to your wp-content directory. Copy wp-config.php and wp-config-vmb.php to the root WordPress directory. [Update: New versions of VMB no longer use the wp-config-vmb.php file. If you have it you can get rid of it; if you *don’t* have it, don’t worry about it. 😉 ]

2) The system no longer uses define() in the config files. Instead we are setting constants via an array called $vmb_const[]. For backwards compatibility, defines in blog-specific config files will still work for now (though it is deprecated). Any constants set in the autoconfig must use $vmb_const[].

3) Note that both mb-autoconfig.php and mb-config-{blog}.php will now be loaded (previously it was either/or). Anything set in autoconfig will be overridden by a matching pref in a blog-specific file.

That’s about it. Check out the readme and the FAQ if you’re having issues. Here’s the page again: Virtual Multiblog for WordPress.

This entry was posted in Webcraft and tagged , , , . Bookmark the permalink.

17 Responses to Virtual Multiblog 2.5

  1. Darin says:

    I’ve been using the previous versions of Virtual Multiblog with success but after updating to 2.5 I simply get an “Error establishing a database connection” error. None of the database information has changed. I use a separate database and config file for each domain. Tks, Darin

    • Stephen says:

      Darin — Look at my reply to Karrut, just above. You may have the same problem.

      In VMB 2.5, the system reads both autoconfig and the specific configs, so if you set any CONSTANTS in autoconfig, it can cause problems.

  2. I haven’t had a chance to update, but from looking at the release notes, I think this version does a good job in cleaning up the architecture of the VMB system. Good show!

  3. Eddie says:

    is it possible to adjust virtual multiblog to have only the plugin settings come off the same database? i would like to install once/configure once for all plugins need. there is a multi plugin install but it doesnt configure them. since i have fantastico the main hassle is actually installing, maintaining the plugin set.


    • Stephen says:

      Interesting idea. I would be able to implement it if I had some way of automatically determining the names of any Options set by a given plugin. Then I could apply a filter any time the plugin set or fetched the Option value. Without a way to determine the option names, though, I don’t know how this could be done.

  4. Eddie says:

    what if wp_options for each blog carried only the basic/built-in wordpress options and one of the blogs (the master blog) carried a full wp_options table? if the record didnt exist in the current DB it would fetch from the master db, using the regular option name.

    • Stephen says:

      The problem is distinguishing “core” options from options put there by plugins. WordPress itself creates some options on-the-fly (certainly so during upgrades), and on the other end, blogs implementing VMB for the first time probably already have existing plugins (with options) active.

      About the only way to do this that I can see is to have a master list of “core” plugin options for a particular version of WordPress, and that would be a very fragile and manpower-intensive system (which is to say, someone — me — would have to be *very* alert and active maintaining it… basically forever!)

      Beyond that, how would we handle plugins that affect core WP options, or store things in other tables? How do we programmatically distinguish between a setting and data? The problem is that plugins are so incredibly flexible that it’s basically impossible to predict what Arbitrary Plugin X is doing to the database.

      I suppose what I might be able to do is create an API of sorts — a standard by which plugin authors could make their plugins “Virtual Multiblog Compatible” — but I can’t imagine that more than a tiny handful of plugin authors might actually use it. It would be a heck of a lot of work for very little gain.

  5. Eddie says:

    yes, it seems that the task is way more complicated than it seems, but let me entertain the idea one more time.

    i guess it would be easier to have WP itself prefix all its wp_options records than to do it the other way around: the cumbersome tagging/identification of all the plugin generated records.

    as far as “how would we handle plugins that affect core WP options, or store things in other tables?”, maybe plugins that store things in other tables would just be incompatible with VMB. as for the ones that affect core WP options, well we would just use the modified core WP option, as we want the plugin to work the same way across all blogs in the system.

    one last idea: how about a mod to keep wp_options synchronized across all DBs on every entry except the designated core WP options, which are a few and don’t change often?

  6. Flavien says:

    Bug in vmb-core.php, line 227: the code doesn’t work on Windows.

    function str_deslash( $string, $end = ‘both’ ) {
    if ( ( $end == ‘start’ || $end == ‘both’ ) && (substr( $string, 0, 1 ) == ‘/’ || substr( $string, 0, 1 ) == ‘\\’) ) {
    $string = substr( $string, 1 );
    if ( ( $end == ‘end’ || $end == ‘both’ ) && (substr( $string, -1 ) == ‘/’ || substr( $string, -1 ) == ‘\\’) ) {
    $string = substr( $string, 0, strlen( $string ) -1 );
    return $string;

    • Stephen says:

      Flavien, I’ve cleaned up that function a bit already, but don’t have a Windows machine on which to test. Would you please let me know if the following works?

      function str_deslash( $string, $end = 'both' ) {
      	switch( $end ) {
      		case 'both' :
      			$string = trim( $string, '/\\' );
      		case 'start' :
      			$string = ltrim( $string, '/\\' );
      		case 'end' :
      			$string = rtrim( $string, '/\\' );
      	return $string;

  7. elvis says:

    Hi, i used the old version successfully on a server.

    I have just tried the new version on a fresh install with sp 2.7, and can only get a blank page when i try to install the blogs.
    when i put a normal config file in (ie don’t use the multiuser plugin) I can install fine.
    I tried with just autoconfig, and with putting the domains into mb-users file. both with no success.
    any ideas about what to check?

  8. elvis says:

    i didn’t change either of those files, just put the db info into the mb-autoconfig.php file.

    oh wait, i just noticed, i put the multiblog folder into the plugins folder, if i move it up, it works!

    thanks for your time.

  9. Jose Luis says:

    Hi. Been using VM for a while and recently updated to WP 2.7 + VM 2.5. Everything seems fine but in one of the installations some plugins that use the apparently new shortcode for parsing (including a [plugin_tag] in content) do not parse.
    I am checking the whole install but was wondering if anyone else was maybe experiencing something like this.

    • Stephen says:

      I haven’t heard anything else. I’m not sure how VMB could alter how the post editor works, unless maybe the plugin author hard-coded something he shouldn’t have.

  10. David says:

    Hi Stephen,

    I successfully set up several blogs using VMB2.4 a year or two ago and then found myself going in other directions. Getting back to it now, I’ve upgraded WordPress to 2.8.4 and now I’m implementing VMB2.6.1.

    I’ll probably find the cause of this fairly quickly, but I’m currently getting the “Error establishing a database connection” message for all the blogs. In searching to see if there was a quick solution, I noticed that your v2.5 upgrade page indicates that the wp-config-vmb.php needs to be moved but that in the release history you indicate that the functionality is now included in the wp-config.php file and the other file doesn’t exist. I’m glad I saw that because I was trying to figure out where the file was! It certainly wasn’t in the zip file.

    Thought you might want to mention on the v2.5 page that that step isn’t necessary in future versions, or update the page for the latest version, to eliminate the confusion.

    Thanks for a fantastic tool.


    • Strider says:

      David —

      I clarified the change in the post, but just FYI, leaving that file the old way doesn’t hurt anything.

      It’s one less file for new installs, but the old wp-config.php / wp-config-vmb.php combo works fine with new VMB, and if just wp-config.php is updated, then the -vmb file is ignored and just sits there.

Leave a Reply to The Plaid Cow Cancel reply

Your email address will not be published.