Recovered from the Wayback Machine.
L is for Linux, A is for Apache, M is for MySQL, and P is for PHP
At this time, being able to create multiple instances of WordPress weblogs isn’t built into the tool interface, and some folks have been turned off of the product because of this. After all, if people are looking to move from Movable Type, it’s most likely because the new licensing system restricts the number of weblogs created. It would make sense they would, then, be interested in moving to a system that provides multiple weblog support.
While WordPress doesn’t yet have push button support for it, implementing multiple weblogs is actually quite easy if you’re willing to go beyond the button stage. And since I know you’re all closet hackers, I feel comfortable that the button was left behind, long ago.
In this LAMP essay, I’m going to cover the steps you can take to implement multiple weblogs. In addition, I’m going to cover my own little ‘multi weblog management’ hack hinted about in an earlier writing. However, I’m going to cover a couple of different options when creating new weblogs: 1 for those who aren’t quite comfortable with the Linux command line; another for those on the hacker track. All total, I’ll be creating, oh, 4 or 5 weblogs. We’ll see how I feel by the time I finish writing this.
(And I’m thinking of doing them all the same design, but in different rainbow colors: bright violet and purple with maybe a touch of yellow; deep pinks and roses, with a hint of olive; oceans of blue; the obiquitous bittersweet and orange; and of course, where would I be without Missouri green, with just a hint of lime to show that I can still salsa with the best of them. I’ll call the latter blog, the “Margarita Blog”.)
Creating each Weblog
First step is to download WordPress and create your first weblog, the mold if you will, for all the other weblogs. To do this, I created the subdirectory, following the steps detailed in The Command Line is Fine, Come on In. The database has already been created, and then it’s a matter of installing the weblog tables and software as described in Installing the Weblogging Tools. At this point in these essays, there is one working weblog, at http://wordpress.burningbird.net.
Before creating a second weblog, now would be the time to implement any changes to that you want reflected across all the weblogs, regardless of look and use. If your changes aren’t to the primary index.php file, or any of the other files that are going to be modified at each site, you can wait and copy the changed file at a later time. Or you might be able to get away without any copying, with a few tricks, discussed at the end of this writing.
Now is also the time to clean up the installation. For instance, if you’re not importing any data from another weblogging tool, you don’t need any of the import-*.php files contained in the wp-admin directory. In addition, what looks like legacy files from previous implementations of the software–b2rdf.php, b2rss.php, b2rss2.php–shouldn’t be needed; or the wp-comments-popup.php file if you’re not supporting pop-up comments, and so on. It’s worth the time now to go through the files in the primary directory of the tool, the root directory if you will, and make sure it’s as clean as possible.
Don’t delete the files you don’t want. Create a second subdirectory somewhere off your web path, and put the files there. Just in case. You can use your FTP program to examine and clean these files up, or use vi (remember vi?) to see what the files are doing, and the Unix move command, mv to move the files:
mkdir /home/shelley/tmp
$mv b2rdf.php /home/shelley/tmp
In this case, I created a directory for the files, and then moved the b2rdf.php file to it.
Once you’re satisfied that you have a good, clean, working install, now you’re ready to create your second weblog–and to install the Weblog Switcher. The first approach we’ll look at to create a another weblog is the simplest from a Linux perspective, but also the hardest to maintain over time.
Creating a Second Weblog by Copying Files
Create a new directory to hold your new weblog, following previously given directions. Once finished, you’re going to copy all of the files from the first weblog directory over to the second. My second WordPress weblog is at http://wordpress2.burningbird.net, and I’m going to copy the files from the original wordpress directory to the wordpress2 directory:
cd /home/shelley/www/wordpress
cp -r * /home/shelley/www/wordpress2/.
The first command takes me to my original weblog’s directory; the second copies everything, including directories (recursively followed using the ‘r’ option), to wordpress2. If you’re not on the hacker track, then use your FTP application to just copy the files from the first directory to the second.
After the files are copied, you need to create the second set of WordPress tables to support this new weblog. To be forward compatible with multi-weblog support in WordPress, it’s important that the tables are created in the same database as your first weblog’s tables. To do this, open the wp-config.php file that you created for the first weblog, but copied over to the second, and leave everything the same except the following line. You need to change the table prefix to something different in order to create the second set of tables. You can use whatever you want, but the example shows that the tables are prefixed with “wp2_”:
$table_prefix = ‘wp2_’; // example: ‘wp_’ or ‘b2′ or ‘mylogin_’
Again, you can use the vi text editor to make this change in Linux; or use your text editor on your home computer, using FTP to bring the file down, make the change, and then upload it again.
After you make the edit and save the file, run the wp-admin/install.php application in the new weblog location to create the tables. As with the first weblog, it’s just a matter of opening the page in your browser and clicking the Let’s Go link.
Once finished, congratulations: you’ve just created your second WordPress weblog. Not quite pushbutton–but close. Close.
(Of course you still have all that design stuff, but we all know how easy this is. )
To work with each weblog, you have to load each weblog’s admin page. It would be nice to be able to switch back and forth between the weblogs without having to hand type in the URL for the WordPress administration page, or the weblog page. That’s where the next change comes in, customizing WordPress to install a new administration page to handle this for you.
Adding in Switcher
Switcher is a page that’s dropped into the WordPress administrative interface, which allows you to record edit and view URLs for all weblogs you create, and then use this to switch between the weblogs. It doesn’t create a weblog, and you can’t use it to delete a weblog–yet. All it does is help you track and navigate between weblogs.
I’ll install Switcher into the original weblog’s administrative pages. The first step to install Switcher is to copy the zipped file containing the software. It can be found here, though note that downloading in Firefox requires saving the file and then opening it separately in Winzip, if you’re getting the file from your Windows machine. However, if you have access to the command line, a quicker approach is to use ‘wget’:
$wget http://wordpress2.burningbird.net/multiweblog.tar.gz
tar -xzvf multiweblog.tar.gz
mv menu.php /home/shelley/www/wordpress/wp-admin/.
mv install-multi.php /home/shelley/www/wordpress/wp-admin/.
mv switch.php /home/shelley/www/wordpress/wp-admin/.
These commands downloaded the software, unzipped the compressed file and extracted the files from the tar file (a tar file is a Unix archive file, a way of grouping files together for easier handling). Then the files were moved to the wp-admin directory of the primary weblog. If you unzipped them on your home computer, FTP them to your server.
When you copied the menu.php file into wp-admin, you overrode the existing one. Switcher is an independent application, but it does need to be installed into the WordPress menu to be accessible. Luckily, menu.php is easily modified to add a new option. All that’s required is to find the code where the array of menu items is being created:
$menu = array(
array(__(’Write’), 1, ‘post.php’),
array(__(’Edit’), 1, ‘edit.php’),
array(__(’Categories’), 3, ‘categories.php’),
array(__(’Links’), 5, ‘link-manager.php’),
array(__(’Users’), 3, ‘users.php’),
array(__(’Options’), 6, ‘options-general.php’),
array(__(’Plugins’), 8, ‘plugins.php’),
array(__(’Templates’), 4, ‘templates.php’),
array(__(’Upload’), get_settings(’fileupload_minlevel’), ‘upload.php’),
array(__(’Profile’), 0, ‘profile.php’)
);
Then, add Switcher as the last option:
$menu = array(
array(__(’Write’), 1, ‘post.php’),
array(__(’Edit’), 1, ‘edit.php’),
array(__(’Categories’), 3, ‘categories.php’),
array(__(’Links’), 5, ‘link-manager.php’),
array(__(’Users’), 3, ‘users.php’),
array(__(’Options’), 6, ‘options-general.php’),
array(__(’Plugins’), 8, ‘plugins.php’),
array(__(’Templates’), 4, ‘templates.php’),
array(__(’Upload’), get_settings(’fileupload_minlevel’), ‘upload.php’),
array(__(’Profile’), 0, ‘profile.php’),
array(__(’Switch Blogs’),0,’switch.php’)
);
Though this change is simple, unfortunately if you install a new version of WordPress, this menu.php file will be overriden unless you choose not to install the new menu.php; or do so, and then re-add this small notification.
(Note: As long as I’m an active weblogger, I’ll provide updates to this code. Hopefully when full multi-weblogs is implemented, it won’t be needed.)
What this edit does is add a new menu item labeled “Switch Blogs”, pointed to an application page called “switch.php”. This page is provided as is, and requires no modification of existing code – just drop the file into wp-admin.
Before you open the page in your browser, you have to do one more thing – create the multi-weblog management database table, wp_multi_blogs. You could try accessing MySQL at the command line and create the table…but an easier approach would be to load the page “install-multi.php” into your browser, which creates the table for you.
At this point, you’ve installed Switcher and if you open WordPress, you’ll see the new option in the menu. Clicking on it will open a page with a form with fields for a weblog’s name, the URL for the Weblog’s WordPress administration page, and the URL for the weblog itself. The image below shows both WordPress test weblogs and Burningbird.
Of course, as you’ve probably realized, Switcher is only available in the original weblog’s WordPress administration pages. To add to each additional weblog, you’ll have to copy the menu.php and switch.php pages to the wp-admin directories for each. You don’t have to install the database table again, or add the weblogs, either. Adding a weblog in one administration page, adds it for all.
Of course, a better approach to all of this would be to have one installation of WordPress shared by all weblogs. Well, I can say that I gave this my best effort, but was defeated by a little thing called a symbolic link. And that leads to a second approach to creating another weblog in WordPress.
Symbolic Links and WordPress
Now, this solution I’m about to detail is a Unix-based solution, and takes us down to the iron of Unix, so to speak. Instead of copying all files, what you’ll do instead is copy the files that are unique to each weblog–the PHP and CSS files located in the root directory. But instead of copying the other WordPress directories, such as wp-includes and wp-images, what you’ll do is create a link from your new weblog to the directories associated with the original weblog.
To follow this approach, again create a third WordPress subdirectory; mine is located at http://wordpress3.burningbird.net. Copy the files located in the root directory of the original weblog installation, and make an edit to the wp-config.php file to change the prefix to ‘wp3_’ to create a third set of tables.
Unlike the previous approach, the only other copies you’ll make are the wp-admin and wp-includes directories to the new site. For the other directories, what you’re going to do is create what is known as a symbolic link between the directories at the old location and the new location.
A symbolic link in Unix is a way of accessing the same files in a given directory in two different places. For all intents and purposes, when WordPress accesses a library function in wp-includes, or a plugin in wp-content in the new weblog directory, it behaves no differently than if the directory was actually, physically duplicated. However, and this is a big however, if you make a change in wp-content, let’s say add a new plugin, in either WordPress weblog, the change is reflected across both.
As you can imagine, this is a simplified approach to maintaining the weblog. Instead of having to updated one version, and then the other– you upgrade one, and you’ve automatically upgraded the other.
To create a symbolic link, you’ll use the Unix link command, ‘ln’, with the ’s’ for symbolic option. You specify the source of the link, and then the target. For this example, linking to the wp-content directory in the old directory is accomplished with the following:
$ ln -s /home/shelley/www/wordpress/wp-content wp-content
Unfortunately, this is one command you have to give at the command line; your FTP program will be no help. At least, that I know of.
Use the same approach to link the wp-images directory, and any other that can be shared between the installation. When finished, if you list out the contents of the directory using the long listing format (with ‘l’ option), you’ll see something like the following:
rw-r–r– 1 shelley shelley 1061 May 19 18:35 wp-config-local.php
-rw-r–r– 1 shelley shelley 992 May 19 18:35 wp-config-sample.php
-rw-r–r– 1 shelley shelley 1001 May 19 19:26 wp-config.php
lrwxrwxrwx 1 shelley shelley 38 May 19 20:36 wp-content -> /home/shelley/www/wordpress/wp-content
-rw-r–r– 1 shelley shelley 585 May 19 18:35 wp-feed.php
lrwxrwxrwx 1 shelley shelley 37 May 19 18:35 wp-images -> /home/shelley/www/wordpress/wp-images
-rw-r–r– 1 shelley shelley 4656 May 19 18:35 wp-layout.css
-rw-r–r– 1 shelley shelley 2182 May 19 18:35 wp-links-opml.php
You might be asking yourself about now, why didn’t I link wp-admin and wp-includes? Well, it wasn’t for lack of trying.
One major dependency in the whole system is the wp-config.php file, located in the root directory of the WordPress installation. Not only does it provide database access, but it also defines the location of the installation, in a variable called ABSPATH, set like so in the code:
define(’ABSPATH’, dirname(__FILE__).’/’);
This variable and the data connection information is used all throughout the system. It’s incorporated by including the wp-config.php file within other PHP files. The code used in the files is the same as the following, found in the admin-header.php file:
require_once(’../wp-config.php’);
Unfortunately, that little reference to a relative location, ‘../’ in the code defeats the symbolic link within PHP code. No matter how you try and trick it. So, the wp-admin and wp-includes files don’t access the specific version of wp-config.php in each weblog directory– they access the one in the initial WordPress installation, every time.
Not too handy if you’re trying to access wordpress2 or wordpress3, or wordpress(n).
Until I find a workaround, you’ll have to just copy wp-admin and wp-includes. And to be honest, if you’re not comfortable with the Unix system, you’re going to just want to copy all of the files. It is easier that way. You just have to remember when upgrading to make copies across all the installations.
Where to next
This is all a workaround, and a hack. It definitely works, and you shouldn’t have problems – but it exposes way more of the Unix environment than a lot of people are comfortable with. Heck, even I got lost a time or two. Or three. And you don’t even want to know what I was saying about symbolic links, relative directory references, and PHP.
The next step is to take this into full multiple weblog management, and this doesn’t have to be complicated, but will require more coding. Specifically:
- First, the concept of the table with metadata for each of the weblogs is good, but it needs to be extended to include the table prefix for each weblog installation. In addition, a second table to record users per weblog should be added to restrict access to the weblog to authorized folks.
- Once this is done, then the wp-config.php file should be altered to point to the database, not a specific implementation. This means we would have one wp-config.php file for the entire installation.
- Instead of running an installation program, an introductory page would provide access to functions to create a new weblog. The subdirectory would still need to be created, but the administration page would not only create the set of tables for each weblog, it would record information about the weblog so that the next time the page is accessed, the weblog shows in a list.
- The administration page would allow you to select any one of the active weblogs, and when you proceed to the WordPress pages you see now, they would be activated for this particular weblog. This will require some, but not excessive amounts of edits to the current admin pages. The WordPress folk have followed some good, clean coding techniques separating the data from the process as much as possible, which makes this task far easier.
- For a little frosting on the cake, when we create the weblog, we could also copy the individual weblog pages into the new account, except for one thing: write permissions. That thing I wrote about in the last LAMP essay. The only way we can copy files into the new directory would be to set the write permissions to global in that directory. To be honest, I think a better approach would be to create a separate subdirectory in the WordPress install with files that need to be copied for each new weblog, and just let the folks handle the copy. Sometimes, less is more.
- Finally, a set of cross-weblog functions should be created to allow one to access posts across weblogs, in addition to comments, and maybe even categories. This can be managed in SQL, as long as the database is a certain vesion. Yeah, for SQL.
I won’t take on this hack. Why? Because open source is not chaotic source.
The WordPress development team has multiple weblog support planned for a near-term upgrade, and I can’t see why both of us would be coding at cross purposes. In addition, my design idea may not be compatible with the existing development team’s idea of how to implement this beastie. Why introduce contradictory implementations?
As it stands now, my little emulation system is forward compatible with multiple weblog support because the plan has always been to support different tables for each weblog. When this happens, just drop my table, and my menu.php, and we’re ready to rock and roll.
I hope no one is disappointed that I don’t have something more sophisticated. If you see errors with the implementation, please let me know. If you see a better approach, then please, either add a comment, or even write it up at your site. This is a lot of typing, and I need a break from the LAMP series, and I’m tired – so please excuse what are, I’m sure, many typos.