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!

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

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…

• Comments Missing in WordPress Dashboard After 2.5.1 Upgrade
• Faking Multiple Templates in WordPress
• Current Status of the Code Viewer WordPress Plugin
• Optimal Title Functionality Now in WordPress Core

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: Code Viewer
• HOWTO: Install WordPress on Nginx
• 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
• Faking Multiple Templates in WordPress
• Current Status of the Code Viewer WordPress Plugin
• WP Plugin: Code Viewer

WordPress uses PHP to pull data from a database, and then subsequently creates the needed HTML based off of that data. Without the PHP, your page would merely render as junk. Thus, in order to see a design change made in your CSS, you’re usually forced to upload the file to your server so WordPress has access to its heart and soul. Not anymore…

The Sandbox

In an effort to make things easier on WordPress users wanting to customize the default installation, I’ve created a static version of the default WP template and have placed it in a zip file along with a clean copy of wp-layout.css and print.css. The template includes a sample entry that utilizes many common HTML elements so you can tell exactly what they would look like on your page.

In this developmental sandbox, you can make structural code changes, try out new CSS techniques, whatever you want…all without having to worry about messing up your live site. Once you get things the way you like them, simply update your real files accordingly, and you’re good to go!

Installation

1. Download wp-design-sandbox.zip
2. Create a new directory on your local machine in which you’d like to place the test files
3. Unzip the three files into the newly created directory
4. Design away

• Faking Multiple Templates in WordPress
• Design by Fire Cleanup
• HOWTO: Install WordPress on Nginx
• Optimal Title Functionality Now in WordPress Core