Category: Weblogging

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

L is for Linux, A is for Apache, and P is for PHP

Before providing instructions for two of the tweaks I made to WordPress 1.2–multiple weblog emulated support and generating static pages–I need to spend some time on the issue of permissions and writing to directories from a PHP application.

Typically, when a web page is accessed from the Internet, it starts a processing thread in the operating system to allow the web server to serve that page. If you have followed this series and bravely embraced SSH, you can log into your site now and take a peek at these processes just by typing the Unix command, ‘ps’ (short for process status). To see processes other than just your own, and to get a nice, full listing of information, use the command options of ‘e’ (for every process), and ‘f’ (for full listing):

$ps -ef

You’ll get a lot of stuff back, but some of what you get back should look similar to the following:

nobody 19905 24708 0 16:58 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 20054 24708 0 16:59 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 20059 24708 0 16:59 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 21016 24708 0 17:00 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 21018 24708 0 17:00 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 21019 24708 0 17:00 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 21022 24708 0 17:00 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL
nobody 21095 24708 0 17:00 ? 00:00:00 /usr/local/apache/bin/httpd -DSSL

These are threads serving web requests. The first column in the output is the ‘owner’ of the process, and as you can see, requests to the Apache web server are owned by ‘nobody’.

When an Apache web server is started, it’s started by the special user known as ‘nobody’. By restricting the environment in which ‘nobody’ operates, only a narrow window of accessibility is allowed into the system, to prevent or at least slow down malicious activity. After all, ‘nobody’ owns any directories, or belongs to any groups–what can it do?

(That’s not to say ‘nobody’ owns all web page accesses. A CGI-based application, such as Movable Type, can operate with expanded permissions in an environment (implemented through the application of a web server add on, such as suexec) that redefines the owner associated with the web request process: instead of the generic ‘nobody’, the page runs within a process controlled by the actual owner of the web site. This means that when you access a page from within these cgi-bin directories, they operate with all the permissions of the owner of the subdirectory.)

Though that nobody owns most of the web requests on your system, but since you’re not a system admin or webmaster, what does this mean to you? A great deal, as a matter of fact, if you’re using applications built on PHP. Any action within PHP that results in output to a directory requires setting permissions on the directory to allow that nefarious user, ‘nobody’, write access. Since ‘nobody’ is really anybody that means setting a directory to wide open write access.

If the PHP application allows file uploads into this directory, the file name can be manipulated in such a way that it exposes files that normally shouldn’t be read–such as the /etc/password file containing user/passwords for the server. In addition, other combinations of file names and actions can result in directories being deleted, or sensitive material being placed in system that when accessed via web server can result in odd behavior. At best.

Having a directory open to global write access is a system vulnerability. However, before you run to your server to wipe your PHP weblogging software from it, take a deep breath, relax, and access your administrative pages for your software. The first thing you should hit is a login page to provide a username and password.

PHP applications that have some form of file upload almost always have some form of password protection to keep that infamous ‘nobody’ from accessing the page, and hence uploading the ‘bad stuff’. Though the server sees the access as ‘nobody’, the application ensures that the access is from ’somebody’.

Of course, this isn’t a totally reliable solution–someone could also run a sniffer on the network, grab your password if you don’t access your weblog tools using SSL security, https, and then log into your system and do havoc. But then, they can do this with those cgi-bin applications I mentioned earlier, too.

(There is a version of suexec being circulated about for PHP called phpsuexec. However, with the limitations associated with it, including running PHP as a CGI application, I can’t see its use spreading very quickly. )

The short end to this long story is that write access and file and directory permissions are always an issue when working with PHP applications. However, by restricting global write access to as few a directories as possible, wrapping authorization about the software that does the writing, and then ensuring that good user permissions are maintained by the system administrator for our computers, unless we get specifically targetted by some of the more clever of the bad guys, we should be safe. And let’s face it: nothing keeps out the really clever bad guys, regardless of what we do, other than unplugging the machine from the Net.

However, having to enable global write access for directories where uploads or changes are going to land also means there’s some extra work for you when installing the software. PHP-based weblogging software such as WordPress almost always require that at least one directory is set to global write (usually detailed in the installation instructions). Not a problem you think, but when you create the directories, they’re initially created without global write permission. Unfortunately, since you’re in a fever of anticipation about getting the software up and running, you tend to forget to change the permissions and get an error such as this:

Sorry, I can’t write to the directory. You’ll have to either change the permissions on your WordPress directory or create your wp-config.php manually

More likely, you’ll get a less friendly message, such as the following:

Warning: fopen(../wp-config.php): failed to open stream: Permission denied in /home/…/wordpress2/wp-admin/install-config.php on line 122

If you’ve installed PHP applications before, you know what’s wrong; but if you haven’t it may take some help from support folk to figure out what’s going on. Well, until now – now you know why you’re getting those errors.

Are you curious as to why the global write isn’t set when you first create the directory? Of course you are. It’s kind of like the seventh Harry Potter book of Unix knowledge.

When creating a directory for the first time, there’s a basic set of permissions given it by default that have been predefined for our user accounts by our system administrators. This is called the umask or user mask, named that way because setting permissions can be seen as a masking operation.

Just think of file and directory permissions as a filter with three holes: small, medium, and large. If you throw a bunch of rocks into it and all the holes are open, all the rocks will fall through. However, if you cover the large and medium holes using masking tape, then the only rocks falling through are the small ones.

Masking tape. Masking. Mask. User mask. Umask. And here you thought that Unix terms were bizarre.

Anyway, no system administrator worth her salt would ever define a umask that automatically sets directories to write enabled: not unless it’s her last day of work and she’s just won the lottery. And she’s a malicious bitch to boot.

No, you, as just any old user on the system, will have to change the global write permissions using the chmod command, and has luck would have it, I’ve already written how to use this command.

(Or you can have your FTP program change the permissions for you if you’re bypassing the hacker track on this series. )

Just remember to keep those file write errors in mind as you read the next few LAMP essays – not that there’s any doubt you’ll forget this essential element after this essay. Why, I bet you never forget write permissions on a directory ever again.