FAQ — Virtual Multiblog

This page should hopefully help out with the most common questions people have. I will be adding to this page as time goes on. If you don’t find answers here or in the readme, please feel free to ask questions. 🙂

Q: Are my plugins compatible with Virtual Multiblog?

A: Almost all plugins are completely compatible with this system. The only known exceptions are plugins that alter the .htaccess file; this mostly comprises caching plugins such as WP Super Cache.

Q: Why are all of the blog addresses showing the same blog?

A: Most likely, the system can’t figure out the VUSER for some reason. When that happens, it uses the autoconfig info, or if you’ve set up a $vusers[] list, the first entry on that list. To confirm that it’s just defaulting to the first thing on $vusers[], move something else to the top of the list.

Similar problems can be caused if a config file has an incorrect name, so check that as well.

Q: Okay, I’ve made a folder for a second blog. Now what do I put in it?

A: Nothing. In fact, get rid of the folder. If you want a “virtual” blog in a subdirectory, that subdirectory isn’t going to actually be a folder, it’s going to be a symbolic link. (See more on Symbolic Links.)

If you’re making a virtual blog in a subdomain (e.g. newblog.example.com ) you don’t even need the symlink. Simply point the subdomain to the same location as your primary domain.

The whole point of this exercise is that all your blogs will run off a single set of WordPress files. You should never have to have multiple copies of the files in different places.

Q: Does Virtual Multiblog work with WordPress version x.x?

A: As of this writing, Virtual Multiblog 2.6 has been tested through WordPress 2.8. Because of the nature of the VMB system, I do not anticipate basic functionality breaking in future versions, unless WordPress radically changes the way it works.

Although people tend to refer to VMB as a “plugin” for WordPress, it really isn’t: Virtual Multiblog doesn’t run on top of WordPress, WordPress runs on top of Virtual Multiblog! (This is why I consistently refer to it as a “system” rather than a “plugin”.) Because of this, there is very little in the basic function that depends on how WordPress works. That makes it pretty future proof.

It does have some “plugin-like” functions that are more dependent on WordPress, and thus may change or break over time. At this time that code adds no major functionality beyond a diagnostic page in Admin.

Q: The new version is missing the plugin folder. What happened? Do I still need it?

A: Sorry, that’s two questions. The plugin is no longer needed as of VMB version 2.4. Before upgrading, you should deactivate the “Virtual Multiblog Support” plugin in all blogs. The easiest way to do that is to delete the file. The functions formerly handled by the plugin are still there; I just got rid of the plugin, which was acting as a bootstrap.

Q: Can the blogs have different themes and plugins?

A: Yes. Each blog runs as a completely separate install of WordPress. As such, they have separate Admin sections, separate Users, and separate settings (including which themes or plugins are active).

A: A symbolic link, or “symlink” is a type of shortcut originating in Unix-like operating systems. Basically, it is a second representation of a particular file (or in this case, directory). A symbolic link basically acts as though it is the target file or folder. In the case of this system, you can put WordPress files in one folder and make a symlink pointing to that first folder. The symlink acts as a second folder that has all the contents of the original.

As for making them, that’s a huge topic, and too big for this page. It totally depends on your system, your OS, settings within your OS, and so forth, though I can say that they can be made in Unix or Linux; I have personally made them in Mac OS X (using Cocktail); and I am informed by commenters that you can make them in Windows.

If you don’t know much about them, it might be best to ask your hosting company to make them for you. That’s what I do. 🙂

For further information, you might find the page at Wikipedia useful.

Q: I’ve redirected different domains to my site, and set up the config files, but the domains all show the same blog. What’s going wrong?

A: It could be many things. First off, a URL redirect will not work; the domains must all point directly to the server (or name server). Next, the server must have those domains pointing to the same directory with the install of WordPress. (In Apache the server admin would most likely set up “Virtual Hosts” that all point to the same place.)

A bit of info that might help with troubleshooting: if the system can’t figure out what VUSER to use, it will try to use the default. (If you’ve set up the $vusers[] list, the default is the first on the list.) Thus, problems determining VUSER can result in different virtual blogs displaying the same content.

Q: How do I upgrade to a new version?

Step 1: Set your configuration files aside.

Step 2: Delete the existing /wp-content/multiblog/ folder. Replace it with the new copy. Put your existing config files back into the /config/ folder.

Step 3: In the root WordPress folder, replace the old wp-config.php with the new one.

Step 4: If you have the multiblog-support plugin installed in your plugins folder, delete it. You don’t need it anymore.

NOTE: If you previously had to do strange things to your $vusers[] or table-prefixes relating to double-slashes, I think that’s fixed as of in 2.2. So if you’re having trouble, you may try undoing whatever you had to tweak in the old version. (I was never able to reproduce that error, so I don’t know what exactly caused it, but I’m hearing that it’s fixed now.)

Q: Is there a way to make it so that when you log on to one blog you’re logged on to them all?

A: Not at present. Somewhere down the line I would like to implement this, but I don’t expect it any time soon.

90 Responses to FAQ — Virtual Multiblog

  1. Frettbuzz, it isn’t a plugin… as in you don’t upload it to the plugins directory and enable from your dashboard. Instead you follow the instructions provided with the download.

    A hint to anyone struggling with symlinks as described in the README. PHP offers a symlink() function. It may or may not work depending on whether your hosting provider will allow it. I installed on a shared server, so the function was my only option. Worked like a charm. Check the PHP manual for more info. Be sure to put the relative location of your installation FIRST (referred to as $target in the manual).

    I’m running WP 2.7.1 (the latest stable release). So no bugs yet that I can see of with this release.

  2. Troy says:

    Is it possible to make the One-click updater work with this? http://wordpress.org/extend/plugins/one-click-plugin-up... I would really like to eliminate the need to give admins an FTP account or other access.

    I can see that the theme and plugin-in paths are hardcoded in /do_update.php but it doesn’t seem to fix anything when I try to hardcode a different path.

    I am using a custom plugin and themes dir for all of my multiblogs and they all are working with everything else. Is there a way to add a $vmb_user variable in there?

  3. Troy says:

    ok, I found that if I can use the $vuser in the ‘do_update.php’ file within the plugin then I could solve this problem. I have a working version by changing the $plugin_dir and $theme_dir variables as shown below…

    $vuser = ‘some_blog_com’;

    $plugin_dir = ABSPATH .’wp-content/’.$vuser.’/plugins’ . ‘/’;

    $theme_dir = realpath(ABSPATH . ‘wp-content/’.$vuser.’/themes’).’/’;

    Any help on how I can get the $vuser value into this plugin would be very helpful! It’s working great now but I’d like to complete the automation. I’ll be happy to submit the solution to multiblog and on-click-updater.

  4. Stephen says:

    Troy — You comment got lost in the shuffle — sorry about that.

    For directory names, you want the “clean” VUSER. Use get_virtual_user(true)

    The “clean” version is more directory and file name friendly — it converts any slashes and dots into underscores. (This is the function used internally to determine which config file each VUSER looks for.)

  5. Lee Graham says:

    Hi Stephen,
    is it possible to protect the virtual directories? i.e. can I go into CPanel and use the “Protect Directory” fuction and point to the virtual directory same as one can with a normal directory?

    What I’m hoping to do is have the main blog for general purpose use and a virtual blog for members, I would them password protect the members blog.

    I realize I could password protect WP pages/posts or use a membership plugin but that’s not the route I want to take.

    • Stephen says:

      Lee — I’m not hugely familiar with .htaccess commands, but I think it can be done.

      Using the normal “default” method, I think you would be locking *all* your blogs, as they would all have that .htaccess file. The trick is figuring out the command so that it just applies to a particular directory. I think you’ll be using a <Files …> command.

  6. Sandy says:


    I’m having a problem that I can’t solve that has been narrowed down to the functionality of this plugin. Please excuse me if this topic has already been addressed somewhere – I am not technically savvy enough to be able to make much sense of this.

    When I initially setup Virtual Multiblog, the address of my blog was “blog.domain.com”. I then used the plugin to create “blog.domain.com/fr/” to facilitate a French version of the site. Now I need to change the primary domain of the site from “blog.domain.com” to just “domain.com”. Now knowing any better, I went ahead and made the change within the WordPress admin and things just broke down. Every address I attempted to connect to within the blog just produced the initial WordPress install page.

    The diagnoses of a technical contact was as follows:


    Due to the use of this plugin, there are 3 options tables in your wordpress database, when there is traditionally only 1. These tables are as follows:


    There are 2 entries in each table, one called “siteurl” and the other called “home” which are supposed to contain the URL being used to access the blog. When you update the blog settings through the WordPress admin to use a new URL, it is supposed to update these entries accordingly.

    The problem, as I have discovered, is 2 fold. The first problem is that when you update this setting through WordPress admin, it is only updating 1 of the 3 tables: wp_blog_domain_com_options

    There is a function within wordpress where it checks to see if it has been installed. It is supposed to come up as “installed” based on what URL you are using to access the site. If it comes back that it has not been – it redirects you to Step 1 of the installation procedure, which is the behavior you see now. After making the URL update through WordPress admin, this check ALWAYS fails using any URL other than “blog.domain.com”. As far as we can tell, this has something to do with the way in which the virtual mutliblog plugin modifies this check.


    Please excuse the length of this question – I wanted to be as thorough and precise as possible to provide the best possible chance for a resolution. I would dearly appreciate it if you could share some advise on how to solve the problem.

    Thanks a lot!

    • Stephen says:

      Sandy — You can “hard” set those variables in your config file, thus:

      $vmb_const[‘WP_SITEURL’] = ‘http://domain.com’;
      $vmb_const[‘WP_HOME’] = ‘http://domain.com’;

      (WP_HOME is the location of the actual WordPress files, which may differ from the location of the site. That’s standard WP stuff….)

      If you don’t have separate config files for each blog, create them in the /multiblog/config/ directory — e.g. mb-config-domain_com.php. Temporarily you may want to also create mb-config-blog_domain_com.php as well, with the same lines in it.

      If you’re using an mb-users.php file, you need to update the $vusers[] list with your new domain.

  7. Sandy says:

    Thanks so much for your prompt reply Stephen.

    I don’t mean to be such a new guy, but would it be possible for you to repeat your advise with just a little more specificity?

    You mention “hard” setting those variables in my config file, but as far as I can tell I have at least 3 working on the go: wp-config-vmb.php and wp-config.php (both in the root), and mb-autoconfig.php (in wp-content/multiblog). To which are you referring? Does it matter where in those files I insert that code? Does adding that code mean I do or don’t have to change the address within the WordPress general settings, and if I still do, should I do it before or after I have added this code to my config file?

    I don’t believe I am using separate config files for the French and English versions of my blog. As mentioned above, the only config file other than the “samples” in the multiblog folder is mb-autoconfig.php. I believe I understand the naming convention you explained (mb-config-domain_com.php) to create separate config files for each version of the blog within the multiblog folder, but what content do I add to the files themselves and where do I get it from? Should I just copy and paste out of mb-autoconfig.php and rename the files accordingly? Do I need to make pointers to these files anywhere else?

    I don’t believe I’m using the mb-users.php file.

    If you could provide me with just a little more information on how to set this up properly, I would so be so grateful. If you can help me get this working, I would very gladly make a donation as thanks well earned.


    • Stephen says:

      Sandy — setting those in the config files overrides whatever is set in WordPress, and can help fix problems such as yours. Set up config for both blog.domain.com and domain.com and set the same variables in both — pointing WP to domain.com. In your case the entire content of those config files might be:

      $vmb_const['WP_SITEURL'] = ?http://domain.com?;
      $vmb_const['WP_HOME'] = ?http://domain.com?;

      These are new config files in the same folder as mb_autoconfig.php. Their names should be mb-config-domain_com.php and mb-config-blog_domain_com.php.

  8. Sandy says:

    Dang, sorry for screwing up the structure of my last post. If an option existed to edit or delete (and rewrite) it, I would.

    /me is embarrassed!

    [All fixed! — ed.]

  9. Sandy says:

    Hi Steven,

    I did what you recommended with some unexpected results. It seems to have succeeded in replacing the previous domain (blog.domain.com) with the new desired one (domain.com) in all page addresses, but instead of displaying the correct pages, all attempts lead to what resembles a fresh WordPress install – completely bare of anything but the default values.

    I was wondering…do I need to remove mb_autoconfig.php once those custom ones you asked me to create are added? Perhaps am I supposed to copy the settings from mb_autoconfig.php to the new config files? It just seems like the new config files succeed, but they don’t reference the existing database at all and the settings contained within mb_autoconfig.php appear to be ignored. This is all just uninformed speculation on my part…it seems I’m closer to a resolution but something is still missing. Any ideas?

  10. Sandy says:

    Also…should I change the blog address in WordPress general settings at any point? Right now and since I installed it, it has been set to blog.domain.com. I know these settings are supposed to override this, but I thought I should ask anyways.

    I also wanted to add that the problem described above (all page links opening the first page of a default WP installation) is only when the new domain (domain.com) is used in the address. When I manually add “blog.” to the beginning, the right page comes up.

    • Stephen says:

      i missed a step.

      Your existing blog at blog.domain.com should have auto-generated a table prefix of “wp_blog_domain_com_”. In your config file you should set that to “wp_domain_com_”

      So… add the following to your mb-config-domain_com.php file:

      $table_prefix = 'wp_blog_domain_com_';

      Once that one is working, I trust you can work out the /fr/ variation. 😉

      I believe you will not need the mb-config-blog_domain_com.php file when all is done.

      [edit: fixed a typo]

    • Stephen says:

      Oh, and while they’re set in the config files, I believe WordPress won’t allow you to change the blog address, etc. The field is greyed out on the Admin page. But if you have direct access to the MySQL database (which I think you do), you can go in directly and change it in the options table. Just be sure you change ALL of the occurrences of the URL string.

      If you do that you can probably drop those lines from your config files. It’s optional, but does keep things tidy.

  11. Sandy says:

    I love ya Steven…that missing ingredient stirred the soup! …except I had to add an underscore to the end to get it working:

    $table_prefix = ‘wp_blog_domain_com_’;


    I’m afraid you’ve given me too much credit though…It’s not completely clear to me how to get the French version working. What’s tripping me up is how to handle the forward slash(es).

    I’m dying to quit nagging you, so let me take a stab here and maybe you could just correct me if necessary?

    1. create mb-config-domain_com_fr.php in config folder.
    2. insert code:

    $vmb_const['WP_SITEURL'] = 'http://domain.com';
    $vmb_const['WP_HOME'] = 'http://domain.com';
    $table_prefix = 'wp_blog_domain_com_fr_';

    Do I win? Do I need to create mb-config-blog_domain_com_fr.php too?

    • Stephen says:

      1) Code is almost correct. SITEURL and HOME are probably “http://domain.com/fr”

      2) You may or may not need the config files with the “blog_” part in the name. Try it without, and if that doesn’t work, add them. I think you will not need them.

  12. Irving Washington says:

    Has anyone used mb with nginx?

    I’m on Ubuntu Jaunty, nginx 8.5 (compiled from source), the latest mb, wp 2.8.1 via svn.

    I’ve used the advanced method, and have two dbs, two domains, and two blogs – well, I at least have two admin pages for two seperate blogs, BUT:

    i seem to be having trouble with my nginx rewriting. This is my first nginx attempt.

    – a.org and http://www.a.org work as per expected.

    http://www.b.org works as expected.

    – b.org redirects to http://www.a.org for some reason?

    this is what I have in my a.org and b.org nginx conf files

    is it line 45? are my regex/rewrites all wrong?

  13. Irving Washington says:

    sorry, here are my nginx conf files: http://datakid.pastebin.com/m4b48c07c

  14. Stephen says:

    Irving —

    I’m not familiar with that sort of server file, but they seem reasonable to me.

    You might show me your VMB config files instead (XXX your passwords etc.)

  15. Irving Washington says:

    Hey, thanks for the response – I’ve vaguely worked it out, and realised I did my domain obfuscation poorly as well.

    1. Part of the problem was the dual “server” parts (one rewrite, one with rest of details) for each domain – and the alphabetically second domain (my “a.org”) was over riding the b.org server rewrite config. This was discovered through testing.

    2. By removing the re-write part of the conf’s and merely adding the extra domain to the server_name line in the main part of the configuration seems to have solved the problem.

    ie: server_name http://www.a.org a.org; (in a.org conf)
    and: server_name http://www.b.org b.org; (in b.org conf)

    3. Having said that (“solved”), I am still not sure about my nginx skills, and neither blog has been tested or populated with real data as yet, so there may be further issues down the track. I will address those when they appear 🙂

  16. Lee says:


    Thanks for the great code; it’s made my life much easier for the past couple of years.

    I recently updated both WordPress and VMB, and now all three blog addresses direct to the same blog. I’ve updated the code in mb-autoconfig.php, created separate mb-config.php files for each of the blogs, each of which contains a table prefix reference to the auto-generated value. (I’m just guessing the value is auto-generated, because I don’t recall setting that up myself.)

    The result is still the same: All addresses direct to the blog that is listed first in the mb-users.php file.

    Your FAQ answer seems to address this problem, but it doesn’t give a solution. Can you point me in the right direction? Thanks very much!

    Here’s my setup: I have three subdomains (home, blog, and diaries), each of which is for a separate blog. WordPress is installed in a WordPress folder on the root.

    Here’s my mb-autoconfig.php file:

    if ( ! defined( 'ABSPATH' ) ) exit(); // sanity check

    // ** MySQL settings ** //

    $vmb_const['DB_NAME'] = '’; // The name of the database

    $vmb_const[‘DB_USER’] = ”; // Your MySQL username

    $vmb_const[‘DB_PASSWORD’] = ”; // …and password

    $vmb_const[‘DB_HOST’] = ”; // 99% chance you won’t need to change this value

    $vmb_const[‘DB_CHARSET’] = ‘utf8’;

    $vmb_const[‘DB_COLLATE’] = ”;

    $vmb_const[‘AUTH_KEY’] = ”;

    $vmb_const[‘SECURE_AUTH_KEY’] = ”;

    $vmb_const[‘LOGGED_IN_KEY’] = ”;

    $vmb_const[‘NONCE_KEY’] = ”;


    Here’s my mb-users.php file:

    if ( !defined('ABSPATH') ) exit(); // sanity check

    $mydomain = '.net’;
    $vusers[] = ‘home’;
    $vusers[] = ‘blog’;
    $vusers[] = ‘diaries’;



    Finally, here’s my mb-config-home__net.php file:

    if ( ! defined( 'ABSPATH' ) ) exit(); // sanity check

    $table_prefix = 'wp_home__net_’;


  17. Andrew Blanda says:

    Hi Stephen,

    I have been struggling to find a good, easy solution to running 2 blogs on one database, and am happy to have found VMB (based on the number of positive reviews out there on the web! 🙂

    To start off, I have a main domain (mpl.com) and a second domain (ab.com). I have pointed the 2nd domain to mpl.com/wordpress (where WP is installed). Installed VMB following the Easy setup. When I get to step 7 & login through the 2nd domain (http://ab.com/wp-admin), it allows me to login in to the DB, but then reverts to the main blog (mpl.com) contents, plugins, posts, etc. The URL in the browser window now shows http://mpl.com/wordpress/wp-admin!

    In essence, I am hitting the same problem described in your FAQ question 2: (Why are all of the blog addresses showing the same blog?). So, I went back and followed step 2 of the Advanced setup (setting the $vusers):

    $vusers[] = ‘ab.com’;
    $vusers[] = ‘mpl.com’;

    (I put them in this order to test whether there was a fallback happening to ab.com, as per this Qn in your FAQ: I?ve redirected different domains to my site, and set up the config files, but the domains all show the same blog. What?s going wrong?)

    All I seem to have now, is a domain redirect that replaces ab.com with mpl.com. I don’t believe I have URL redirect; in my hosting provider’s control panel I have set the ab.com under the domain pointing option (is that a URL redirect?)

    Let me know if you need other info!


    • Strider says:

      Andrew —

      “in my hosting provider?s control panel I have set the ab.com under the domain pointing option (is that a URL redirect?)”

      It certainly might be a redirect. Best to ask them. Pointing two domains to the same directory on a server, without a redirect, is sort of unusual, so you should ask them what it’s doing.

    • Strider says:

      If it is a redirect, you might try setting

      define( 'VMB_ACCEPT_REDIRECTS', true );

      in wp-config.php

  18. I want to combine two separate, already existing, blogs using multiblog. Is it possible and what should I do? I tried the most obvious approach – set separate config files using the info from the existing blogs. Any Ideas?

    • Stephen R says:

      In short, yes: create a config file for each and set the table prefixes to whatever they are for the existing blogs. Then it should pull the existing data from the database and give you the same blogs.

  19. Nerml says:

    Perfect. Bog simple to get going, and works a treat.

  20. Pete says:

    In order to give my multiple blogs each need their own uploads folder and theme folder, I gave the individual config files this line:

    $vmb_const[‘WP_CONTENT_DIR’] = ‘/home/user/content/blogname’;

    In that directory, I placed a themes and uploads folder and a symlink to the multiblog plugins folder (since I don’t want each blog to have its own plugins, just its own themes and uploads).

    The virtual blog I tried this one works without error, but it seems to ignore the config setting and just use the main installation wp-content folder instead.

    What am I doing wrong? Is there a better way to achieve my goals?

Comments are closed.