. . . an examination of things of interest to jad

I went on my first real wordpress odyssey last week[skip the tiresome narrative]. I encountered a number of sites that helped me on my way. Now I plan to “give something back” in the form of documenting the steps and missteps I took in the hopes that, should someone else find themselves in a similar situation, they can use this post as a resource to find their way home.

A number of tools of modern web development (and software development in general) attempt to provide a clean and simple(r) interface to rather complicated processes. WordPress is one such tool. The idea is to abstract away the various elements of site development and allow the WordPress user to focus on content. The obvious advantage of all such tools is the inclusion of non-expert site developers among the potential software users. This expands the base of people that can communicate their ideas in modern networked forums.

The downside is, when something goes wrong, it can often be at a “level” that the site maintainer may not be expert in, and may not even be aware of.

Example:

I am a novice user of WordPress. My level of expertise was such that I could install updates–a process which with my provider must be done manually. I had version 2.7.1 installed when I saw that an update was available. Knowing that updates are generally responses to super-heinous security vulnerabilities, I attempted to upgrade using my trusty notes on the process.

Upon completing the upgrade, I looked at the “new” site and saw this. A totally blank page. Being the computer genius that I am (and following my wisely conservative notes), I had the old version on hand, so I rolled it back in and went googling for information. I saw a couple of other people had encountered this problem, but all of their situations seemed, at a glance far more complicated than mine. I didn’t see any simple solutions provided so I decided to wait awhile in the hopes that somebody would notice and fix the problem in the next WordPress release–I adopt this type of tactic frequently, with mixed results.

A couple weeks passed (I’m the opposite of a prolific blogger) and another version of WordPress was released. I tried again to upgrade and I got the same results–blank screen. This time, I was determined put in some time and fix whatever it was that was broke. Thus began my adventure . . .

The Boring Technical Details (or, perhaps, the Reason You’re Reading this Post)

I make numerous indirect references to my install instructions.
Part of the setup at my provider is a personal “public” folder that is the document root for the entire site. My WordPress installation is a sub-directory of public (/home/public/wordpress). As a step in my (and any) upgradeThe first thing I did, to be extra super safe is to create a tar file of my old wordpress installation, wordpress.20100216.tar. No matter what, I’d have a working version [foreshadowing]. Now I could operate in my typical manner, with reckless abandon.

I had three wordpress installations–three subdirectories of public: wordpress-old, the working original copy; wordpress-blank, the latest wordpress install, but with my wp-config.php and wp-config directories copied over; and wordpress which was latest.tar.gz unzipped and extracted with a generic wp-config.php.

Beginning of Useful Information

My first reference was Velvet Blues, who have, apparently, suffered all kinds of blank page woes. Another site, High Tech Dad, was the first place I saw the term White Screen of Death (WSOD). Searching for WSOD brought a bunch of additional stuff. If you’re suffering WSOD, you’re solution is out there . . . unless you have the problem I was having*.

I was able to rule out all of the content, plugin, theme problems. I copied the wp-content directory over and built a new wp-config.php (via the web interface) which resulted in a functioning wordpress install–without my content. When I copied wp-config.php over, WSOD.

So I followed #5 from the Velvet Blues article, excerpted from another excellent WSOD article by a McNulty–which is awesome, I’m a huge Wire fan. He suggested that white space in the wp-config.php file could be the culprit. When I crack it open in vi, my config file looks like this:

/** ^M
* The base configurations of the WordPress.^M
*^M
* This file has the following configurations: MySQL settings, Table Prefix,^M
* Secret Keys, WordPress Language, and ABSPATH. You can find more information b
y^M
* visiting {@link http://codex.wordpress.org/Editing_wp-config.php Editing^M
* wp-config.php} Codex page. You can get the MySQL settings from your web host.
^M
*^M


Narrative Interlude

My provider hosts with FreeBSD. I transfer the files from a windows machine and, there or in the original, the control-M (carriage return) is tacked on the end of each line. FreeBSD doesn't use carriage returns, but the control character is still on there. Of course, this hadn't been a problem for my old wordpress installation, but maybe the latest release is finicky? In any case, I figure I'll try to strip them out. While I'm at it, I decide to strip them out of the entire distribution. After popping over here to refresh my memory on entering control characters, I do the following:

find . | xargs perl -pi -e "s:^V^M::g"

Still got WSOD. Oh, and I accidentally ran in in public, instead of public/wordpress, so I stripped all the control characters (^M) out of every file under the document root. Careless move, but no big deal, they're not used in unix [more foreshadowing].

I should have made note of this when it happened, the details are fuzzy a week later--maybe I'm trying to blank it out. Somehow in all of the moving things around I deleted wordpress-old (or maybe just wp-contents in there). Anyhow, I'd lost my original installation. Luckily, I had my tar file . . . without the ^M's that are apparently used in non-text files, even in FreeBSD.

Without ever solving my first problem, I was now facing a second--how to connect a totally new wordpress instance with my still existing database backend.

Installing a New WordPress Instance with an Existing Database

At first, this looked trivial. According to the codex, I just needed to point a clean copy of wordpress at the existing DB. So I extracted a fresh copy of the latest distribution and attempted to point it at the existing database. It wouldn't let me continue, giving the following error:
"Already installed! To reinstall please clear your old database tables first."

So then I tried giving it a "fake" table prefix so that it would complete installation, and then go end and change the table prefix by hand to match my existing DB . . . WSOD. It was getting late and I was resigned to the fact that I wasn't going to get my upgrade/recovery done before my cognitive skills degraded to the point that I would further endanger my chances of ever succeeding.

Upon waking up the next morning, I had a pretty good feeling that I could fix my site. I figured the damage must be inside my database itself, so I would just copy the tables one-by-one until I got the WSOD. Then, knowing the culprit, I would repeat the procedure but leave out the corrupted table, which I would copy over from a new installation.

So I unzipped a new copy of the latest distribution. This time, upon creating the wp-config.php--again, from the web interface--I provided another, totally new, prefix. During the course of my searches on prefixes, I discovered that I probably should have a non-standard prefix anyway. Apologies to the original source--I couldn't find it again. I picked up and installed the phpMyAdmin plugin. It showed my original wp_ prefixed tables as well as a set of tables for each of my two other installs.

One-by-one I dropped the tables from the new installation and copied the wp_ tables to the new installation prefix. It turns out, something in the options table was causing the problem. I copied all the other tables over, and voila, a functioning website.

On the Dangers of Blogging 10+ Days After an Event

To be honest, there was one additional hurdle to do with the salts in the options table (or keys, as they're labelled in wp-config.php). They need to match, and . . . something else is required as well. In any case, I've forgotten exactly what the problem was--I solved it by dropping the options and user tables and creating a new wp-config.php (all together) "via the web interface".

* My problem may have been on the list. I may have had to figure it out the hard way.

For no healthy reason, I love this sort of thing. Rad Geek, a member of the Alliance of the Libertarian Left, registers, via post, his advocacy of revolution against the federal, state, and local government. This is in accordance with south carolina state law.

The entire letter is well written, and I’m sure it will get an interesting reaction, “Merle, where *do* we keep that list of subversive organziations?”

My favorite bit is at the end: “PS. I am told that there is a processing fee in the amount of $5.00 for the registration of a subversive organization. Our organization is in fact so dastardly that we have refused to remit the fee.“