After searching for a bit and checking my sever logs, I found that the upgrade script did not add the proper index to the “comment_date_gmt” column in the comments table for my WordPress database:

Apr 25 18:22:17 php-cgi: WordPress database error Key 'comment_date_gmt' doesn't exist in table 'wp_comment' for query...

The Solution

If you don’t want to wait until the upgrade script gets fixed in a later WordPress release, you’ll have to add the missing index to the database table yourself to get things working again. I’ll demonstrate how to do that using the MySQL command line interface, however, if you’re more comfortable with using phpMyAdmin, see the steps outlined here.

Check for Proper Privileges

First of all, you must have the proper privileges on your WordPress database in order to add an index. To check that, follow these steps:

1. Log in to MySQL with whatever account credentials you know.

   $ mysql -u root -p
   Enter password:
   Welcome to the MySQL monitor.  Commands end with ; or \g.
   Your MySQL connection id is 59202
   Server version: 5.0.51a Source distribution
   
   Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
   
   mysql>

2. Specify that you want to access the “mysql” database, then ensure that you do have the privileges to add indexes.

   mysql> use mysql
   Database changed
   mysql> SELECT user, index_priv FROM user;
   +------------+------------+
   | user       | index_priv |
   +------------+------------+
   | root       | Y          |
   | elasticdog | N          |
   +------------+------------+
   2 rows in set (0.00 sec)

As long as you see a ‘Y’ next to your username, then you should be good to go.

Add the Index to the Comments Table

Once you have access to an account that can add indexes, then follow these steps to add the missing index:

1. Specify that you want to access your WordPress database. If you don’t know the name of your WordPress database, run show databases; to see a list of databases you have access to.

   mysql> use elasticdog_wordpress
   Database changed

2. Add the index. The table names for WordPress are fairly standard, but if you don’t have one named “wp_comments”, run show tables; to see a list of contenders and it should be easy to figure out.

   mysql> CREATE INDEX comment_date_gmt ON wp_comments (comment_date_gmt);
   Query OK, 458 rows affected (0.14 sec)
   Records: 458  Duplicates: 0  Warnings: 0

3. If want to verify that the index was created, run
   SHOW INDEX FROM wp_comments; to list all indexes, and then you can exit out.

If everything went as planned, all will be right in the world and your comments should be viewable through the dashboard once again!

• Faking Multiple Templates in WordPress
• WordPress Design Sandbox
• Current Status of the Code Viewer WordPress Plugin
• HOWTO: Install WordPress on Nginx

Apache is a very well-establish web server that can handle just about any situation. Unfortunately, that flexibility comes at the cost of size and relatively high demands on server resources. Nginx (“engine x”) is a lightweight web server/reverse proxy that is very efficient and perfect for hosting WordPress. Read on to see how that can be done…

Step One: FastCGI

First off, Nginx does not provide FastCGI for you (FastCGI is what your web server uses to interact with WordPress’s PHP code), so you’ve got to have a way to spawn your own FastCGI processes. My preferred method is to use the spawn-fcgi program provided by the web server lighttpd. You can use PHP’s built-in FastCGI manager php-cgi to do the same thing, but it’s not as straight-forward. Plus, if you learn how to use spawn-fcgi, you can easily adapt it for use with other web applications requiring FastCGI.

Install spawn-fcgi

To download and install spawn-fcgi, run the following commands. Don’t worry, all of the building happens in your current directory…nothing else will be installed on your machine.

$ wget http://www.lighttpd.net/download/lighttpd-1.4.18.tar.bz2
$ tar -xvjf lighttpd-1.4.18.tar.bz2
$ cd lighttpd-1.4.18/
$ ./configure
$ make
$ sudo cp src/spawn-fcgi /usr/bin/spawn-fcgi

NOTE: If you’re following the steps above verbatim, you will need to have root privileges in order to copy the binary to its final location…everything else should work fine as a normal user. To gain root privileges, the program sudo was used in the example above; you may or may not have access to sudo on your machine.

After spawn-fcgi has been copied to the desired location, you can safely remove the build directory and original source file:

$ cd ..
$ rm -rf lighttpd-1.4.18/
$ rm lighttpd-1.4.18.tar.bz2

Run spawn-fcgi

This part will be fairly distribution-specific, but I’ll provide the basic command that you’ll need. What you want to do is find a way to run this command as part of your init scripts so the processes will be spawned automatically when you reboot your server.

/usr/bin/spawn-fcgi -f /usr/bin/php-cgi -a 127.0.0.1 -p 53217 -P /var/run/fastcgi-php.pid

• -f → the filename of the fcgi-application; in our case we want “php-cgi”, which is provided by your distribution’s PHP package. If you don’t know where to find it, try running which php-cgi on the command line.
• -a → the IP address to bind the processes to; in our case we want the localhost
• -p → the port number to bind the processes to; pick whatever you want that won’t cause a conflict (technically it would be best to pick a random number between 49152 and 65535), just make sure to remember the number and use that same port for your Nginx configuration file later on
• -P → the location where to save the process id file; you can use this file to easily kill the processes later

For better security, you can also spawn the processes as a non-privileged user by specifying the user/group with the -u and -g flags respectively. For more information on all the available options, run spawn-fcgi -h on the command line.

If you’re interested in seeing the complete init script that I wrote for use with Arch Linux, you can download it here: fastcgi-php

Step Two: Complete 83.33% of the Famous 5-Minute Install

Next you should download the WordPress files and extract them to their final location on your server. Simply follow steps 1–5 of the Famous 5-Minute Install (the 6th and final step requires that your web server be up and running properly, so we’ll do it later). This guide will assume that you extracted the WordPress core files here: /srv/www/nginx/domain.com/

Step Three: Nginx Configuration

To get the web server up and running properly, the file you need to edit is called “nginx.conf” and is installed in different places depending on your Linux distribution. If you install Nginx from source, the default location is /usr/local/nginx/conf/nginx.conf, however yours may be somewhere else.

Once you find that file, open it with your favorite text editor and add a server declaration that looks something like this (I’ll cover what each part means after posting the code):

server {
    listen       12.34.56.78:80;  # your server's public IP address
    server_name  domain.com;      # your domain name

    location / {
        root   /srv/www/nginx/domain.com;  # absolute path to your WordPress installation
        index  index.php index.html index.htm;

        # this serves static files that exist without running other rewrite tests
        if (-f $request_filename) {
            expires 30d;
            break;
        }

        # this sends all non-existing file or directory requests to index.php
        if (!-e $request_filename) {
            rewrite ^(.+)$ /index.php?q=$1 last;
        }
    }

    location ~ \.php$ {
        fastcgi_pass   localhost:53217;  # port where FastCGI processes were spawned
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME    /srv/www/nginx/domain.com$fastcgi_script_name;  # same path as above

        fastcgi_param  QUERY_STRING       $query_string;
        fastcgi_param  REQUEST_METHOD     $request_method;
        fastcgi_param  CONTENT_TYPE       $content_type;
        fastcgi_param  CONTENT_LENGTH     $content_length;

        fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
        fastcgi_param  REQUEST_URI        $request_uri;
        fastcgi_param  DOCUMENT_URI       $document_uri;
        fastcgi_param  DOCUMENT_ROOT      $document_root;
        fastcgi_param  SERVER_PROTOCOL    $server_protocol;

        fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
        fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

        fastcgi_param  REMOTE_ADDR        $remote_addr;
        fastcgi_param  REMOTE_PORT        $remote_port;
        fastcgi_param  SERVER_ADDR        $server_addr;
        fastcgi_param  SERVER_PORT        $server_port;
        fastcgi_param  SERVER_NAME        $server_name;

        # required if PHP was built with --enable-force-cgi-redirect
        fastcgi_param  REDIRECT_STATUS    200;
    }
}

You will need to edit all of the highlighted sections above using your own information. The first part is merely the server declaration where you define what your server’s publicly available IP address is and what domain name that address is associated with.

Next we add to that some default settings for the root location. The key part here is that WordPress uses the “Front Controller” design pattern, meaning that any request for a file that does not exist on the server should be handled by the main index.php file. To do this, we need an appropriate set of rewrite rules pointing to the proper path of our installation.

Last, we add one more location block that tells Nginx to dynamically forward PHP requests to the FastCGI processes we spawned earlier. That’s it!

Step Four: Finishing Up

Everything should be good to go…all you need to do now is start your Nginx server process (another distribution specific command), then complete the 6th step of the Famous 5-Minute Install and you should have WordPress up and running on Nginx!

If any of this needs further clarification or you’re just having trouble, leave me a comment and I’ll see what I can do to help…

• Faking Multiple Templates in WordPress
• WordPress Design Sandbox
• Optimal Title Functionality Now in WordPress Core
• Comments Missing in WordPress Dashboard After 2.5.1 Upgrade

Code Viewer now supports syntax highlighting using GeSHi, can display specific line numbers, and has user-configurable scrollbars (among a few other niceties). On top of those changes, the default code path variable can now be configured directly in WordPress’s admin interface rather than editing the plugin code by hand…very nice!

Reactions

I don’t agree with all of the design choices they made with the new changes, but my qualms are minor. Specifically, I don’t like some of the chosen defaults, nor the new format when specifying viewcode tags:
[viewcode ] src=/code/example.txt link=yes[/viewcode]
…in comparison to the original:
<viewcode src="/code/example.txt" link="yes" />

That said, it is a cool feeling to find out that other people appreciate your work and chose to carry on with its development in your absence.

Passing the Torch

With the latest design incarnation here at ElasticDog, I decided to no longer use Code Viewer for displaying code snippets. Instead, I went with the plugin Code Markup, which allows me to easily embed custom markup within code blocks. It’s a completely different way of going about displaying code in blog entries when compared to Code Viewer, but it does the job well and suits my needs for the time being.

Although I haven’t actually worked on the development of Code Viewer since late 2004, I did register to have it hosted at the WordPress Plugin Repository. Unfortunately, I never got around to packaging it up for general consumption.

Trying to not be a slacker anymore, I have contacted Håkan in hopes of persuading him to take the reins and officially manage the plugin at the centralized WordPress repository. If he agrees, you should be able to download the plugin here very shortly:
http://wordpress.org/extend/plugins/code-viewer/

In the mean time, you can find the most up to date version of Code Viewer at Håkan’s site. Happy coding!

• WP Plugin: Optimal Title
• WP Plugin: Code Viewer
• Optimal Title Functionality Now in WordPress Core
• Comments Missing in WordPress Dashboard After 2.5.1 Upgrade

A Change in WordPress v2.5

As of the beginning of this year, a changeset was checked in to WordPress’s SVN repository which adds a “separator location” argument to the built-in wp_title() function. What that means, is that when WordPress v2.5 is released around March 10th of this year, users will be able to change the ordering of their HTML title tags without having to use a third-party plugin.

The developers decided not to change the default behavior of wp_title(), and instead added the additional argument to the function in order to prevent breaking existing themes that rely on the current behavior.

How to Make the Change

If you’re currently using Optimal Title and want to change your template back to using wp_title() after upgrading to WordPress v2.5 (and you should), here’s what you need to do…

Using the simplified example from the original Optimal Title article, you should currently have something like this in your theme’s header.php file:

<title><?php optimal_title(); ?> <?php bloginfo('name'); ?></title>

Just replace the function call optimal_title() with a call to wp_title('»',TRUE,'right'), and you’ll end up with something like this:

<title><?php wp_title('&raquo;',TRUE,'right'); ?> <?php bloginfo('name'); ?></title>

That’s it!

Parameters

The wp_title codex page won’t be updated until the next release, however, here is how wp_title() will work after WordPress v2.5 is out:

<?php wp_title('separator', display, 'seplocation'); ?>

• 'separator' - string - The text to place between portions of the page title, such as the blog name and the category. Defaults to '»' (»).
• display - boolean - Should the title be displayed (TRUE) or returned for use in PHP (FALSE). Defaults to TRUE.
• 'seplocation' - string - The location of the separator in relation to the title. All values default to the standard left position, with the exception of 'right', which will place the separator after the title rather than before.

I’m Glad

Even though it took so long to get this done, I’m glad WordPress finally came around to the idea and added Optimal Title’s functionality to the core. Regardless of whether or not you were using Optimal Title before, I’d highly recommend that all users make this simple change to their templates in order to take advantage of the many benefits that a proper title tag has to offer.

• WP Plugin: Optimal Title
• WP Plugin: Code Viewer
• Faking Multiple Templates in WordPress
• Current Status of the Code Viewer WordPress Plugin

The trouble is, we both buy music from iTunes on a regular basis using our own individual Apple ID accounts, and there isn’t an easy way to share our music seamlessly with one another. We have similar tastes in music and we’d like it so that when one person buys a new song, it is immediately available for the other person to listen to. Ideally, we’d also be able to create our own unique playlists and assign ratings to the various songs to reflect our own personal likes/dislikes. This article lays out the details of how I accomplished that goal…

The Problem

The main problem with assigning two iTunes Libraries to the same location comes down to permissions. By default, when you download music through iTunes, it assigns permissions based on the user that’s logged in. It only allows that user and people in the UNIX group “wheel” to read the music file (if you’re UNIX-literate, that means it has 640 file permissions). Since a different user (in this case, my girlfriend) would not fit into those categories, she doesn’t have the proper permissions to read any of the music I download. To put it simply…music needs to be world readable.

The Solution

These permissions can be easily fixed by running a simple script that uses the chmod command to modify your music so anyone can play it. To give you a breakdown, the script runs a few safety checks to ensure that you have the proper permissions to modify the files, it then checks that your specified library actually exists, and then it recursively looks at all of your music making sure it is world readable.

The trick is getting the script to run only when necessary as not to waste resources. You could set up a cron job, but then it would have to run on a fixed time table. Either it would run more often than necessary, or not often enough…so cron is out. You could set up a launchd/launchctl configuration file and specify it to run when your Library folder is modified, but unfortunately that doesn’t get triggered when a sub-folder gets modified…so launchd is out.

The key ends up being something called a “LoginHook” that is configured in the /etc/ttys file. Creating a LoginHook will ensure that whenever any user logs in to the machine, the script will be run and proper permissions will be set on the entire library.

Putting it All Together

This should go without saying, but I’m saying it…back up all of your music files before doing anything else! Once that’s done, proceed with the following steps:

1. First you must pick a centralized location that all your users have access to and make sure the directory exists. I picked /Users/Shared/Music/iTunes and created it on the command-line using:
   mkdir -p /Users/Shared/Music/iTunes
2. Next, you must adjust your iTunes settings to point to the new location. You do this by launching iTunes, then navigate to iTunes » Preferences… » Advanced, and under the General tab, click the Change… button next to the “iTunes Music folder location” box. Navigate to your newly-created centralized folder (in my case /Users/Shared/Music/iTunes), and click Choose.
3. For ease of maintenance and to prevent duplicate files from being generated, make sure the checkbox labeled “Copy files to iTunes Music folder when adding to library” is not selected (this is also under the Advanced section of the Preferences dialog box).
4. Click OK to accept the changes you made to your preferences.
5. To copy your current library to the new location, navigate to Advanced » Consolidate Library… then proceed by clicking Consolidate. This step only needs to be performed one time per user to ensure that everything gets moved over to the new location.
6. Repeat these configuration steps for all users that you wish to consolidate libraries for.

At this point, you’ve done all that is necessary to do within iTunes, and all that is left is fixing the file permissions. To do that, log in as a user with administrator privileges and follow these steps:

1. Download the script and put it anywhere you want. I made another directory called /Users/Shared/bin/ and put the script there, but the location doesn’t really matter.
2. Modify the script’s LIBRARY variable (in the CONSTANTS section) to point to the centralized music directory you created above.
3. Ensure that the script is executable by running:
   chmod 755 /Users/Shared/bin/share-itunes
4. Then edit the /etc/ttys file with your favorite text editor, and change the line starting with “console” to add:
   -LoginHook /Users/Shared/bin/share-itunes
   right after the “loginwindow” declaration. Make sure you actually point it to the location where you downloaded the script to. The line should have looked something like this before you edited it:

   console "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" vt100 on secure onoption="/usr/libexec/getty std.9600"

   …and look like this after you edit it:

   console "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow -LoginHook /Users/Shared/bin/share-itunes" vt100 on secure onoption="/usr/libexec/getty std.9600"

5. Save the file, and close your text editor.

That’s it! Everything should be all set to go and your permissions will be checked each time you log in to the computer.

Caveats

The only thing I wasn’t able to automate was adding new music purchased by my girlfriend in to my library so it actually shows up when I launch iTunes. For all I know, there may be an easy way to automate it, but I haven’t found one at this time. Luckily it’s a fast/easy procedure to do by hand…

To actually have new music purchased by another user show up in your library, all you have to do is launch iTunes, go to File » Add to Library…, then navigate to your shared music folder and click Choose. It will take a few seconds to parse through your library, but after it’s done, all of the music should be available for you to play. You will have to do that every time you know that music has been added by another user, but everything else should be automated for you.

Why it Works

Unless you get tricky, iTunes always stores your album artwork, playlists, and song rating information in a file under your home directory (well, in ~/Music/iTunes, to be precise). It also stores a meta file with information regarding what it thinks should be included in your library. These files will be unique to the user even if you choose to share your actual music collections. So when you update your iTunes preferences to move the location of your Library, you still retain the ability to have all your own custom settings regardless of what other users add to the common music folder.

By periodically telling iTunes to add the common music directory in to your library, you’re simply forcing it to update the library meta file so it reflects whatever actually exists in that directory…regardless of whether or not you were the person to purchase the music.

Hopefully these steps will be able to help someone else out there having a similar issue. When I first started looking in to how to accomplish this configuration, I though surely it would be easy and done before, but alas, things got a bit more complicated than I had hoped. If you know of a better way, please do leave a comment and let us know what works for you. If you have any trouble understanding these procedures or getting it to work, let me know and I’ll see what I can do to help out…happy listening!

None Found