<?php echo "Hello Again, World!"; ?>
Note: If upgrading to VMB 2.5 from a previous version, please read the upgrade instructions.
Greetings and salutations.
This is my second blog, which is here to serve as a repository for the really die-hard geekery that I feel just doesn’t belong in my regular blog. When I realized the need for a second blog, installing it ended up being a longer process than i anticipated, and I thought I would share the fruits of my experience.
Let me step back for a moment. I am a true hacker at heart, in the traditional sense: I love to pull things apart and take a look. To see how they work and how they might work better. I’m also an avid Mac-head, and since the rise of OS X, I’ve been learning the ins and outs of its Unix-like underbelly.
In a nutshell, my computer is highly customized.
A few years back I got a second computer — a laptop — and quickly discovered that while keeping one computer tweaked to prime operation just the way I like it is kind of fun, trying to keep two computers in such a state, and relatively synchronized, is a frustrating exercise in futility.
I also know a good bit of web coding. As I’ve been working with WordPress for a couple years now, I’ve come across a number of good plugins and expansions along the way. Beyond issues involved with installing them, (which is admittedly pretty easy, usually) over time I have to keep up with updates to these — not to mention updates to WordPress itself. From time to time I even delve into the plugin files myself and make improvements….
And I want to put in a second blog? Am I nuts??? Thinking of what a pain it would be to maintain two copies of WordPress, I started looking into the various multi-blog solutions people have come up with. Most of them involve a lot of weird modifications to several files and basically comprise major modifications to large swaths of the WordPress code that are fundamentally incompatible with the regular version.
I am a great fan of what I consider “elegant” coding, which means that the designer does his job with the simplest and most straightforward methodology possible. And I found a very elegant solution to the “multiple blog on one install” question. Allan Mertner came up with something that blew me away with its simplicity and power.
WordPress holds all of its data in a MySQL database, and there is a single file called wp-config.php that holds the database login information. Allan looked at this and realized that if you can change that one file, you can completely replace the blog. With this key realization he came up with a cunningly straightforward multi-blog system:
- Replace the standard wp-config.php file with a new version that calls a different configuration set depending on what directory it’s in.
- Set up symbolic links that serve as “virtual directories” that all point to the WordPress directory.
Using the example of this site, I have an install of WordPress in the root web directory, and a symbolic link called “nerdaphernalia” (that’s right, you’re soaking in it!) that points back to the root. The modified wp-config file points to either the default or nerdaphernalia config file, depending on which of those two directories it thinks it’s in.
So other than a happy user, where do I come in in all this? Well, I made a number of improvements. First, Allan’s system was great, but it required us to install various files in and around the core WordPress files, which for me at least defeats part of the purpose of using a multiblog system in the first place. I’m trying to make updates easier, remember? Updating WordPress generally involves deleting everything but the wp-config.php file and the wp-content folder, and then dropping in the new versions of everything else; but if there are important but non-standard files strewn about, I can’t just do that. I have to remember to go through and preserve those files, and then replace them when they’re done. Add in a few plugins that work the same way, and we have a real hassle.
So first off, I tucked all the files, except for the one modified wp-config.php, into a folder in a safe place. Next, I greatly streamlined the install process. At a minimum, the user only need edit a single configuration file, autoconfig.php. If desired, the various blogs can each have individual config files, but it’s no longer necessary.
I’ve added user-accessible functions (and the really handy VUSER constant) that can be used in themes and plugins. I’ve added the ability to customize the location of the configuration files, so the security-conscious can move them entirely out of the Web directories if they wish. Overall, we are left with a easy but powerful system for running virtually any number of blogs off a single install of WordPress.
Install instructions are included with the download. Still have questions? Check out the readme and the FAQ. (Note: Sometimes the readme will list a higher version than the download. That happens if I have a development version installed.)
User “JZ” is selling written instructions for installing the system. (Please Note: I have not even seen his instructions, I’m just letting you all know.) More info in this comment.
…And if the directions are worth money to you, perhaps the actual software is worth something as well?
Download
Here’s what you’re really looking for: the download link. Have at it!
History/ Acknowledgements
For a detailed history, please see the readme file in the download.
Many of the improvements to version 2 were based upon or inspired by commenters to my blog. To them, and to everyone who has sent comments, I am grateful.
Good luck. Have fun.
684 Comments
Pages: « 1 … 21 22 23 24 25 [26] 27 28 29 30 31 … 35 » Show All
Michael — sorry for the delay.
You are doing subdomains. You want to set the web server so that all of the domains/subdomains point to the same Web Root. In the Web Root install WordPress with Virtual Multiblog. Use your web browser to go to each of those domains/subdomains. Each should show the normal WordPress install screen.
So…
designs.pl –> /home/www/
erik.designs.pl –> /home/www/
mark.designs.pl –> /home/www/
All point to the same directory.
Install WordPress in /home/www/
Install Virtual Multiblog
Good luck.
I’ve been looking into the whole “mu plugin” methodology, and I’ve made a discovery. The mu-plugin system is part of regular WordPress, so it works in regular WordPress.
So… go into your wp-content folder and make a folder called “mu-plugins”. Put plugins inside that folder and they will load automatically for all blogs.
NOTE: Not all plugins will work properly this way — it depends on the plugin. For example, anything that calculates its own URL based in the “plugins” folder will get it wrong.
ALSO: It appears that it doesn’t load plugins within folders, which is the opposite of what is becoming standard in regular WP. What I’ve done in a quick test is put a “load.php” file in the mu-plugins folder, and that has a quick script to include() the plugins I want.
Not heavily tested, but it seems to work. A nice head start anyway.
***In other news*** I’m working on a Tips and Tricks page, culled in part from the 600+ comments that have been left by users regarding Virtual Multiblog (on this and its original page). I’ll have something up soon, and expect it to grow — I have a long list of “to add” items that will take a while to complete. Cheers.
I set up a mu-plugins folder and dropped the Hello Dolly plugin (hello.php) that comes with every install of WP. Did not work.
I also tried a gzip plugin. Still nothing.
Finally, I tried using a load.php file. Strike 3.
What plugin did you test?
What path did you use for your load.php includes?
I would love, love, love. To activate plugins blog network wide. I am ready and waiting to donate to make that happen
The kicker is it doesn’t find plugins in *subfolders* — just bare PHP files in the mu-plugins folder. Thus I put a load.php file in the bare mu-plugins folder that include()s the “main” plugin files contained in the plugin subfolders.
Didn’t work for all, but for some.
Hi Stephen,
I keep discovering new VMB features.
Recently I noticed that, when $table_prefix is not set, VMB sets it to wp_domain_tld_ depending on the domain it is accessed through. I assume this is not limited to domains, but actually does a “wp_”.$vuser.”_”, right?
Anyway, that’s a great feature, as it does not enforce manually setting $table_prefix, and I think it is definitely worth documenting it. (Or did I miss its description?)
Keep it up the great work.
It’s actually the “clean” VUSER. Take a look at the get_virtual_user() function, and the “clean” parameter (bottom of vmb_core.php). Basically it converts dots and such to underscores, so that the VUSER can be used in file names. That is:
get_virtual_user() returns the virtual user — same as VUSER constant
get_virtual_user( true ) returns the “clean” virtual user.
The “auto prefix” feature is basically documented in the distinction between “Easy” and “Advanced” setup. With Easy Setup, you only do the one config file, and the table prefixes are automatically generated. Thus you have to use Advanced Setup if you wish to specify the prefix.
Admittedly the documentation could use a bit of work.
Just FYI — I’m hard on the heels of an “auto activate plugins” feature. It’s actually (barring unforseen roadblocks) easier than I thought it would be to implement. Setup for the user will involve adding a simple array to the blog’s config file.
(Not sure if plugin activate/deactivate hooks will fire though — that may or may not be a trick to do….)
I’ve read quite a bit here about porting to bbpress. And even though I’ve just started to use both wordpress and bbpress, I recognize the need. I’de be willing to test it for you, not really learned enough to do it my self.
Virtual Multiblog v2.6 is ready for release, but I’m waiting a bit, because its primary new feature is only compatible with WordPress 2.8 — which isn’t yet released.
[edit: The new feature is auto-plugins. You can specify plugins that will be automatically activated -- for those plugins this overrides the normal activate/deactivate function of WordPress.]
For those of you using the WP 2.8 beta who want to preview the new VMB, you can preview the new version by downloading it from this link: Virtual Multiblog 2.6
Instructions are in the new readme. Let me know how it works out for you.
Hooray!! WoW, this is fast
Hello Stephen,
Congratulation for this excellent system. It looks that it fits perfectly for me. I have some questions:
1) Does this works with the WP Super Cache plugin? It writes some sentences in the .htaccess, I wonder if this could create a conflict.
2) Is it possible to have separated robots.txt file per blog?
Many thanks
JC
1) Plugins that write to .htaccess are the only known conflict with Virtual Multiblog. I’m sure you could get it to work with some custom mod_rewrite work, but I haven’t figured that out yet. If you get it working please let me know what you come up with.
FYI, VMB does not write anything to .htaccess (yet). If you’re looking at the code, you’ll see a function that does, but that’s not called from anywhere at the moment because it’s unfinished.
2) I don’t think you can have separate robots.txt, but I think you can pretty much duplicate that functionality with robots meta tags in the pages themselves.
Hi Stephen,
First, great piece of software, thank you!
I have an interesting problem that no one else in the comments seems to have. I just started playing with VMB and have a test set up on a brand new web host. First thing I actually did was just stand up a stock WordPress 2.7.1 install to test out my host and it works great – just lightning fast.
Then I set up an instance of VMB on a different domain altogether and dropped in a few blogs. Did my symlinking, etc. and tried them out. They worked, but …. they are really slow – both the site and the WP Admin. We’re talking 6+ seconds after a click before the next page even starts showing up in the browser, whereas with the stock WP install, it feels instantaneous.
Any ideas? Perhaps just point me in the right/some direction – I would appreciate it greatly.
_KJH
StephenKJH,I won’t say it isn’t possible but I’d be very surprised if VMB is the cause of your slow response times. Because you say this slow sites are on a different domain (but I assume at the same host), I’d be inclined to think it was a DNS issue. Check response times from the DNS servers for the two sites.
Thanks for the quick response Henry. Actually, I did 2 things that should eliminate DNS as the issue:
1. I ‘moved’ over (symlinking) the original stock WP site into VMB. ‘Moving’ it back sped it right back up.
2. I’m actually ‘fudging’ DNS by having entries on WinXP box in my drivers/etc/hosts file, so there are no DNS lookups.
Go here and check under “Storage of symbolic links” : http://en.wikipedia.org/wiki/Symbolic_link
Check your type of symlink.
Do you have slow or fast symlinks. According to the article, fast symlinks fall back to slow symlinks when certain conditions apply.
Hi Robert,
Thanks for the suggestion. I read the Wikipedia entry on symlinks and the fast vs slow text seemed mostly historical in nature to me. But I ran some further tests anyway:
1. Created a new test PHP file (x.php) that ran phpinfo(). I symlinked to this from the test site’s htdocs dir. This ran just as quickly in both cases – symlinked and non-symlinked versions. Again, I keep falling back to some issue with VMB or perhaps my configuration of it.
2. I tried shortening up my symlinks by using relative paths (../../. . .) instead of absolute ones (/var/www/vhosts/domain/ . . .). Same results.
3. I forgot to mention that even when I ran the ‘main’ VMB site (so no symlinks involved), it was just as slow, which says to me that symlinks aren’t at issue here.
_Khalid
Hi Khalid,
Yeah, it was a long shot.
I also had long delays and I never used symlinks, because I’m using subdomains pointing directly to /public_html.
My main domain is pointing to /public_html/wordpress.
In the directory public_html I had a one-line index.php file with a re-direct :
So each subdomain was re-directed to the main wordpress installation.
But, it was taking donkies years to re-direct.
I was looking at a blank page for 4-5 seconds.
For me, the problem was with the PHP redirect, not with VMB.
I renamed the index.php with the re-direct, and replaced it with a .htaccess file in the root of my shared server. One level up from public_html.
From there I re-direct, the main domain, all subdomains (by wildcard), and when necessary I re-write the name of the main domain from “maindomain.com” to “www.maindomain.com”.
All with 301 mod_rewrites.
Not as fast as server level re-writes, but with a much shorter delay.
Best,
Robert
KJH —
I’ve not encountered slow-down issues, so I’m not sure what might cause it. Still… Questions:
1) Are you running any plugins or other add-ons of any kind?
2) OS? (I’m guessing Linux, but you never know….)
3) What VMB features are you using beyond the basic “Easy Install”? Are you using a $vusers[] list? Setting Constants?
4) I think you’ve already answered this, but just to be sure: What happens if you run the single main blog on VMB? NO Symlinks — keep everything just as you would run regular WordPress, but run it on the VMB version of wp-config.php, etc.
Not sure how much I could help with this one, but maybe answering those questions will clue somebody else in….
Hi Stephen – thanks for the quick response.
Answers to your questions:
1. I’m still in the testing phase, so bare bones WP install. However, I did install 1 plugin (Ultimate Google Analytics) to ensure that it would still work (it does). Deactivating makes no difference.
2. OS: CentOS release 5 (Final)
3. Advanced intall of VMB. Am using mb-users.php with a handful of $vusers[]. Not using any VMB_* constants. I realized that I had defined the WP NONCE_KEY as a vmb_const in my mb-config-domain.php configs but it wasn’t part of the sample, so I stripped those, but no difference.
4. Yup, I did run this test and it was just as slow (I outlined in comment #517)
Thanks!
_Khalid
Pages: « 1 … 21 22 23 24 25 [26] 27 28 29 30 31 … 35 » Show All