<?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 … 25 26 27 28 29 30 31 [32] 33 34 35 » Show All
Can some guide me how to create an symlink
I want to redirect http://domain.com/wp to http://domain.com
Domain.com has the word press installed, but that is not the root of public_html
its public_html/domain.com/
I have shell access but no support from the hosts
My set up will be
domain1.com/blog
domain2.com/blog
domain3.com/blog
Each will have their own database.
Can this plugin work with Thesis theme? I ask this because Thesis has a custom folder in their theme.
Also, I am trying to find out if each site can have their own uploads folder? I don’t want all images in one big upload folder.
Lastly, I like this plugin because it seems the most future proof. I want to have the option to move any site in this setup to it’s own hosting account with normal WordPress install. Will I be able to just set up a new hosting account and use the database and upload all the images? Will there be any conflict in images path?
Thank you again for such a useful plugin.
I’m stuck at this part.
I am using different domains for each blog?
Am I right to say I should add each domain as an addon domain to the folder contain wp files?
How about Parked Domains, Redirects?
If I use Addon domains method, then there will be a subdomain created on the main domain for each new domain, how to solve this? This would create many duplicate domain.
There is a problem,if I use add these domains via addon, all pointing to the same wp folder, this means I can’t have other non-wp files/directories like domain.com/forum domain.com/directory as they will need to be created in wp files folder and will also be accessible by all the addon domains?
When we talk about using different database, are we actually referring to creating a new database in the original wp installation domain?
WPMU would be the better choice for that type of scenario I’d think. WP on an individual basis requires enough write access for that to be an issue. This is more about simplifying the process of creating and updating multiple blogs of your own.
Jay,
I am not sure what and ‘addon’ domain is. If that is like an alias domain, then no, that is not what you want to do.
If you are on a VPS or Dedicated box you’d want to a new site/domain. Then you need to point the DocumentRoot of that site to the folder where the WP files are located. How you do that is dependent on what your server set up is.
Yes, any other folder in the WP root folder will be technically accessible via all domains. However, a user won’t find them unless you link to them. You could block spiders per domain using 301 redirects if you were concerned about them getting crawled and associated with two domains an thus possibly getting dinged as duplicate content.
With VMB you can have completely different databases if you wish OR you can have one ‘master’ database that is filled with a unique set of tables for each blog installed as part of the multiblog.
I couldn’t get success with the plugin. It’s not working on my WP blog
I want each blog to have it’s own uploads folder to future proof, in case I need to move any blog to a standard WP installation in future.
Should I edit mb-config_DOMAIN_COM.php
// In WordPress 2.6+ you can change the location of wp-content and/or plugins
// $vmb_const['WP_CONTENT_DIR'] = ”;
// $vmb_const['WP_CONTENT_URL'] = ”;
Or, should I edit in WP Control Panel
/wp-admin/options-misc.php ?
Miscellaneous Settings
Uploading Files
Full URL path to files
What theme are you guys using?
Is there a theme that work well with VMB in the sense that we are able to create a totally different look for each site?
I am using Thesis, changing the design options in one blog affects all the other blogs.
Jay, here’s how I have my sites set up with private upload and theme directories and a shared plugin directory.
In each user’s home directory I create a wordpress-content directory with two subdirectories, uploads and themes. I also put an index.php file there with in it. Finally, there is a symlink to the /wordpress/wp-content/multiblog directory.
index.php
multiblog -> ../../wordpress/wp-content/multiblog
themes
uploads
In wordpress/wp-content/ I still have a plugins directory but no upload or theme directories. In the mb-config-domain_com.php file, I set WP_CONTENT_DIR and WP_CONTENT_URL to point to /wordpress-content and WP_PLUGIN_DIR and WP_PLUGIN_URL to point to the shared plugin directory. Finally, on the miscellaneous settings page I set the uploads directory to /wordpress-content/uploads.
It isolates both uploaded files and themes from other blog owners (don’t want one blog owner to edit the theme of another owner, now do we?). Since the plugins are shared, I only have to maintain one copy of those. Activating plugins is still per blog, which is also just fine with me.
Hi Henry,
Thanks for sharing. You have an interesting different approach.
Do you use addon domains to point your domains to the wp files?
The way I do it is I installed WP on domain1 root.
Then at domain1, I add an addon domain2.com, pointing to public_html
But from what you shared, it seems you use a different method.
It seems that each of your domains has their individual domainX.com folders inside the WP folder.
If so, how does each of your domain connect to VMB and WP?
By using addon domains, I faced 2 problems.
- a subdomain get created with each addon domain and I am unable to remove them. Luckily these subdomains show the default blog so I won’t have much of a problem with duplicate content.
- By pointing all my addon domains to the WP files folder, I am unable to have other scripts like forums, directory and plain html files as these will be accessible by all other domains since they are all pointing to the same place.
Sorry, a few bits of my comment doesn’t display. Specifically, anything between less-than and greater-than symbols got dropped. So, here is it again with square brackets wherever I used less-than and greater-than before. (oh, and this is a test < and > should display right)
Jay, here’s how I have my sites set up with private upload and theme directories and a shared plugin directory.
In each user’s home directory I create a wordpress-content directory with two subdirectories, uploads and themes. I also put an index.php file there with [?php // silence ?] in it. Finally, there is a symlink to the /wordpress/wp-content/multiblog directory.
index.php
multiblog -> ../../wordpress/wp-content/multiblog
themes
uploads
In wordpress/wp-content/ I still have a plugins directory but no upload or theme directories. In the mb-config-domain_com.php file, I set WP_CONTENT_DIR and WP_CONTENT_URL to point to [userhome]/wordpress-content and WP_PLUGIN_DIR and WP_PLUGIN_URL to point to the shared plugin directory (wordpress/wp-content/plugins). Finally, on the miscellaneous settings page I set the uploads directory to [userhome]/wordpress-content/uploads.
It isolates both uploaded files and themes from other blog owners (don’t want one blog owner to edit the theme of another owner, now do we?). Since the plugins are shared, I only have to maintain one copy of those. Activating plugins is still per blog, which is also just fine with me.
Stephen,
VMB is powerful and the most future proof method I have found. I tried MU but found that it’s not compatible with a lot of plugins and themes. I tried Drupal multisites too, but Drupal has a higher learning curve compared to WP. Your solution is the best I have found at the moment.
My multi sites are all domains.
I have the wp files at domain1.com root.
I have read through all the 600+ comments here. But I don’t get a very clear idea on the domain pointing part.
Should I point my multi sites domains all at the same place to domain1.com root?
Or, should I create individual domain folders inside domain1.com?
Like
domain1.com
domain1.com/domain2.com/
domain1.com/domain3.com/
domain1.com/domain4.com/
I am also using Add-On domains. Is this the correct method to point the domains?
By using Add-On domains to point the domains, I face 2 problems. I wonder if you guys also face the same issue?
Issue 1. Each addon domain has a subdomain which I am unable to delete.
Issue 2 – When I point all domains to the same place, the multi domains will have all the same files. For example, if I create a html file sales.html and a folder /directory/ , these will also be accessible by other domains with the same file and directory name.
DO you guys face the same issue? So I know I am on the correct path…
I have been testing various plugins on several sites. Is there a way to tell which plugins are enabled on which VMB sites?
Just going to each blog’s Plugins page (or looking at the database directly I suppose….)
I have a patch that I am testing that I feel would be useful to the general public. It allows you to set up domain aliases (setting a vuser based on alias hostnames) such that mb-users would be something like this.
Thereby loading the correct database so that plugins like Domain Mirror will still function.
Pretty simple patch, I haven’t tested it fully but I have high hopes it will work; I did my best to utilize the framework you had built for implementing tests.
I do realize the same could be accomplished by using symbolic links and extra $vusers entries, but other code I have relies upon VUSER being the parent value (and not one of the aliases) for determining the filesystem location of things like uploads and for some customizations we did to wp-supercache.
[edit: added link to Domain Mirror plugin -- ed.]
Todd –
Interesting idea. The concept could work, but there may be a vulnerability there. I haven’t tested, but I think a malicious site could monkey around with yoursite.com.evilsite.ru and such. I’ll have to give a closer look to be sure.
I would be interested to see what you did with wp-supercache, since I don’t know of any caching systems that work with VMB.
Also… I noticed the domain of you email address. Without naming names, I’d be curious to know — is that company using Virtual Multiblog???
You can drop me a line if you want to respond outside of comments.
We’re still evaluating it, we have a number of wordpress blogs and we want to cut it down to a single instance for ease of management of the codebase. WordPress MU was just not at all suited for our needs, and VMB presented an elegant solution. Or at least it might, once we’re sure it works for our needs!
As far as WP-supercache goes, we use the VUSER constant to set the directory that the cache files are written to ($cache_path in wp-cache-config.php) , and then alias them in to /wp-content/ via mod_alias in our apache config. This was one of the things that I still have yet to test out fully.
I agree that there may be a vulnerability of some sort here; I personally don’t like the use of eval()’s in the tests process, but that was the technique you chose so I stuck with it. Since $server is ostensibly user-supplied input, it should probably be sanitized better to prevent the eval from being used for a code injection attack (or, the evals should disappear entirely). You could probably modify this to use preg_match and set yourself a list of regexes rather than using eval. Those are my $.02 anyways, but take it with a grain of salt considering that I’m a sysadmin and not a PHP developer
I will update once I have more information on whether supercache can be made to work with VMB.
Thanks!
- Todd
I can confirm that wp-supercache does in fact work with VMB, and we’ve collapsed all our wordpress blogs down to a single install!
The aliasing also seems to work a treat. Hope the contribution helps someone else who needs to use the Domain Mirror plugin along with VMB.
Todd– I’m in the process of making some changes to the system, including eliminating the eval() calls. Instead I just do each test directly in turn, which also allows for more flexibility in what the tests can do (e.g. anything they want) rather than the one-liners required by the tests[] array. It should be coming as an update soon.
As for your $valias patch, I will not be adding it into “core” VMB until I’ve gone over the full ramifications of it. It could be very useful.
What I *may* do though is implement some sort of plugin mechanism so that people can add their own tests via config. Of course that could be a security issue (though not much of a risk unless somebody can somehow put code on your server, in which case you have worse issues than that!)
Do you think your company might consider a donation?
Also, how much did you have to modify wp-supercache? If it’s relatively minor, it might be worth my contacting the author and convincing him to add VMB compatibility….
Pages: « 1 … 25 26 27 28 29 30 31 [32] 33 34 35 » Show All