<?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 … 20 21 22 23 24 [25] 26 27 28 29 30 … 35 » Show All
can’t speak for others’ experience with virtual multiblog but the setup i created required a few tweaks so automatic upgrade is definitely not an option… i don’t much care though, since i’m generally of the philosophy not to upgrade software until it becomes totally necessary, not avoidable, etc. i haven’t been compelled to upgrade yet.
I have started to write code that will help you manage the plugins as suggested by Asylum in #479, but I never got back to it to complete it. I am including the code here (I hope this is appropriate), so that perhaps someone else can use it.
The code looks in the database where the multis are kept. Finds the options table with the plugins, then create a record in another database with the domain, tablename, and plugin name. This is to help organize what plugins are being used by what domains. What is needed then is to create a function and interface to add and remove from plugins by changing the field value in the options table using the structure found in the code.
CODE STARTS HERE
$database_name = ENTER DATABASE NAME;
$username = ENTER NAME OF DATABASE USER;
$password = ENTER PASSWORD OF DATABASE USER;
$link = mysql_connect(“localhost”, $username , $password);
mysql_select_db($database_name,$link);
$plugin_table_name = “admin_domain_plugin”;
//Must create a table that contains fields
//domain_name
//table_name
//plugin_name
//remove data from plugins tables
$sql = “delete from $database_name.$plugin_table_name”;
mysql_query($sql, $link);
//get the options tables
$sql = “SHOW TABLES from $database_name where (Tables_in_$database_name like ‘wp_%_options’) “;
$table_result = mysql_query($sql, $link);
if (mysql_error() 0) {
echo mysql_error() . ” ” . mysql_errno();
}
$iCount = mysql_num_rows($table_result);
while ( $table_row = mysql_fetch_array($table_result) ) {
$theme_sql = “select * from $database_name.” . $table_row['Tables_in_' . $database_name] . ” where option_name=’active_plugins’”;
$result = mysql_query($theme_sql, $link);
//echo mysql_error();
//echo mysql_num_rows($result);
//$row = mysql_fetch_array($result);
while ( $row = mysql_fetch_array($result) ) {
if (!empty($row['option_value'])) {
//example a:2:{i:0;s:39:”multiblog-support/multiblog-support.php”;i:1;s:37:”revision-control/revision-control.php”;}
$regex=’/a:(.*?):{(.*?)}/s’;
if (preg_match($regex, $row['option_value'], $plugin_start)) {
$plugin_count = $plugin_start[2];
$regex2=’/i:(.*?);s:(.*?):\”(.*?)\”;/s’;
preg_match_all(
$regex2,
$plugin_start[2],
$plugins, // array name
PREG_SET_ORDER // formats data into an array of posts
);
foreach ($plugins as $plugin) {
//$plugin_order = $plugin[1];
//$plugin_name_length = $plugin[2];
$plugin_name = $plugin[3];
echo $plugin_name . “”;
$sql = “insert into $database_name.$plugin_table_name (domain_name, table_name, plugin_name) values(‘” . get_domain($table_row['Tables_in_' . $database_name]) . “‘, ‘” . $table_row['Tables_in_' . $database_name] . “‘, ‘$plugin_name’)”;
//echo $sql;
//exit;
mysql_query($sql, $link);
echo mysql_error();
}
}
}
}
}
function get_domain($thedomain) {
//echo $thedomain;
//$thedomain = substr($thedomain, 3);
$thedomain = substr($thedomain, 3, -8);
$x = strpos($thedomain, “_”);
$x = strpos($thedomain, “_”, $x+1);
$thedomain = str_replace(“_”, “.”, $thedomain);
if (empty($x)) {
$thedomain=”www.”.$thedomain;
}
return $thedomain;
}
Wow!
Thank you Michael, this could be a revolution!
I don’t have the time now to use your code but I will in a week or two.
Cause Michael gently posted something that could be useful to everyone, I want to do the same with a personal research I did to resolve the “files” problem that a multi-installation of WP could create.
If someone resolved that problem someway, please write it here.
Unfortunately I’m stuck here:
http://forum.modrewrite.com/viewtopic.php?t=34283&p...
I added a small change to allow you to change
the default wp_ prefix for security purposes.
mb-autoconfig.php
$vmb_const['DB_PREFIX'] = ‘xyz_’;
vmb-init.php
if( empty( $table_prefix ) ) $table_prefix = DB_PREFIX . get_virtual_user( true ) . ‘_’;
IN regard to my previous comment
I have not tested this a great deal but it seems to do the trick for me.
What we have is a list of default plugins that should be automatically loaded for every blog using vmb.
At the bottom of vmb-init.php I added the following
include_once( ‘vmb-plugins.php’ );
Then created resources/vmb-plugins.php
Sorry the last comment got chewed up because of the PHP tags. Here is the contents of resources/vmb-plugins.php
/**
* Add plugins to the array that you would
* like to have automatically loaded for
* all blogs using virtual multi blog.
* Could get these from a database table
* and then set this up so only one default
* blog has an admin option to view/add/delete
* and then maybe even add the ability to
* manage different default plugins on a per
* blog basis.
*/
$default_plugins = array(
‘xyzplugin.php’
);
$current = get_option(‘active_plugins’);
foreach ($default_plugins as $plugin) : // loop through the default plugins
if (!empty($current) && !in_array($plugin, $current)) // if $current has value and is an array
$current = array_merge($current, $default_plugins); // merge it with $default_plugins
elseif (empty($current)) // $current has no plugins
$current[] = $plugin; // add default plugins to $current
update_option(‘active_plugins’, $current); // update the wordpress options table for active_plugins
endforeach;
Man… go out of town for a few days and the comments come rolling in!
Nokao– Look at WP_CONTENT_DIR and WP_CONTENT_URL. They may offer a simpler answer to your issue.
Michael and Asylum– thanks for the auto-plugin code. I’ll definitely take a look. If I integrate something like this I will probably take the MU route and have the “auto” plugins go in a separate folder from the regular plugins. A few reasons — probably easier to just “activate” everything in that folder, and you don’t want individual admins having the ability to double-activate (or delete!) those plugins.
Also: Something I really do need to figure out is how to *remove* the ability of admins to add or delete plugins. As of WordPress 2.7 there is potential for mischief with admins deleting plugins that another blog is using. (The ability to delete was added directly to the WP Admin interface.)
Asylum — Changing the default table header prefix is what my security-oriented colleagues refer to as “security through obscurity” and generally derided as not much use. I’ll consider adding this, though – I may or may not at this point.
Stephen, if you make the plugin files read-only, then they will not be able to be deleted by any interface–WP even gets rid of the delete link. (I had to use this when something kept deleting one of my plugin files–not sure why it was happening.)
Auto plugins, mu type folder to activate sets of plugins, be still my wp-geek heart.
What do you need to make that happen?
I’d be glad to make a larger donation in support of this. Plugin activation/management has become quite cumbersome.
Hello Stephen, yes changing the prefix of the wp database and tables is a form of security through obscurity. My outlook on this is that no one method alone makes anything secure but with a number of methods you gain more security. Security through obscurity is a good thing “only” when it is not the sole form of security involved. The largest reason for doing the change to the default prefix is that “all” published wp hacks rely on the prefix wp_. The average break in attempts are made by those running prefab scripts and only basic knowledge of wp.
I have Suhosin installed on my server and get a nice view of attempts made against the server and websites. So far for the past 5 years of running wp installs every hack or break in attempt has been with the wp_ prefix so IMHO anyway this is a very big thing. Aside from this by having it in the config it allows the user to have the choice at their fingertips without having to delve into the core files of vmb.
I like your idea on going the MU route of having all the default plugins in a separate directory. That would make it much smoother and better to manage and then the array could be made up from scandir or rscandir to get the plugins that reside in directories of their own. http://us3.php.net/manual/en/function.scandir.php#84638
It would also make securing that set of plugins that much easier without interfering with normal plugin operation. One more thing I just thought of is that it could allow “if wanted” each blog to have their own set of default plugins or use the base set. Gave me so many more ideas with that anyway.
I did run into one issue with the method I posted above. I found that with all the blogs I have there are actually only a set of them that I want plugins auto loading on. For the others loading these default plugins posed an issue of failing code due to missing dependencies. (These failing blogs use their own databases)
What I did to remedy this is added a variable in the auto config that the auto plugin code then looks for. If it is true then it loads the default plugins and if it is false or does not exist then it moves over the auto loading.
[...] decided to do a Google search to see if anyone else had tried this approach before. I found this article on Virtual Multiblogs which is based on a similar approach. It looks like he used a bunch of different directories all [...]
Hi.
First of all, sorry for my bad English.
I have server with files of WP. I need do something like that:
Hompage – designs.pl
Erik Blog – erik.designs.pl
Mark Blog – mark.designs.pl
And now the question: I must make 2 subdomains direct to hompage ? And then script make a 3 others blogs ?
Please, use easy language in re.
Thanks a lot,
Michael (PL).
Do not feel bad about your English. Remember I do not speak you language.
I pay my bills using my knowledge so I cannot give it away for free.
But, I can provide you English instructions for $25.00 USD by paypal that will fix your problem. You must agree not to publish those instructions in any other language or on the internet.
I share some of money with Steve the author who deserves it. [Clarification: Steve is the author of Virtual Multiblog. JZ is the author of the instructions for which he charges money. The two are not "officially" affiliated.]
If you are interested let me know
JZ
Thanks, but I better speak than write
So anyone cannot help me for free ? I have only one question: “I must make 2 subdomains direct to hompage ? And then script make a 3 others blogs ? “.
So?
Michael
[...] WordPress?2.7???????????????????????????????????????????WordPress????????????????????????????WordPress?????????????????????????????????????????????????????????????????? Virtual Multiblog for WordPress – Nerdaphernalia?????WordPress???????????????????????? [...]
Does VMB support wordpress with directory structure like
ln -s /var/www/ABC Vblog1
ln -s /var/www/ABC Vblog2
ln -s /var/www/ABC Vblog3
Thanks
Is there, by chance, a ‘Virtual Multiblog for Dummies’? I definitely want to implement this solution but find myself getting stuck on things that are probably intuitive for folks with coding experience.
JZ is selling a set of instructions. I’ve not read them myself, so I can’t endorse them, per se. Details here.
He says they:
“cover everything from creating subdomains using CPANEL to creating a database and username. Then on to installing Multiblog 2.4 with what I call EXACT KEYSTROKES. Following the instructions you should be able to set-up 6 blogs in 30 minutes.”
[...] an error 500 showed up. All of my blogs run on one WordPress installation using a method called Virtual MultiBlog. This means that all blogs also share the plug-in [...]
[...] first public beta of Hackadelic Multiblog Kit, or VMBKit vor short. With this plugin, and the great Virtual Multiblog system for WordPress, you can create blog farms1 with ease. The Supported Usage [...]
Pages: « 1 … 20 21 22 23 24 [25] 26 27 28 29 30 … 35 » Show All