Changing the location of a WordPress installation isn’t as harrowing as it may sound. Although no tools exist to do it automatically, some knowledge of the Linux command line and MySQL makes it do-able. This post is a summary of the steps I performed to relocate my blog folder; this assumes you are hosting under Linux, MySQL, and cPanel. Take a gander at the official Moving WordPress documentation before you begin.

Make a Backup

Be sure to make a backup of your installation.

Change the Current Blog Folder

Rename your existing WordPress folder (i.e.: /journal) to the new name. FTP or ssh (i.e.: mv journal blog) can be used for this.

Update the blog path settings within the admin panel.

Updating Paths in the Database

If your blog posts contain images or links using the old folder they must be changed. There is a simple SQL command which performs a search and replace. I suggest using phpMyAdmin instead of MySQL’s command line.

Take a look at your wp_options table in phpMyAdmin. You may find that plug-ins are using your old path in their settings which may be not accessible through the admin interface.

Don’t Break Trackbacks

If anyone is linking to your blog they’ll be using the old folder name. To ensure those links don’t break with your folder we can use a symbolic link and a 301 redirect.

Login to your Linux hosting account using ssh and navigate to the root folder of your web site such as public_html. Enter the following command:

ln -s /path/to/new /path/to/old

Replace /path/to/new and /path/to/old with the absolute folder names. For example:

ln -s /home/your-domain/www/blog /home/your-domain/www/journal

You may be tempted to add a redirect using cPanel but don’t - the symlink above is doing this for you.

Unfortunately, permalinks still won’t work. For example, a permalink of http://your-blog/journal/2008/06/my-post will generate a 404 Not Found instead of redirecting to http://your-blog/blog/2008/06/my-post. Don’t bother with the Redirection plug-in because it doesn’t build a library of prior permalinks.

Instead, use Alexandra’s technique to modify your .htaccess file and all of your old permalinks will 301 properly.

An email has been languishing in my inbox for months regarding the release of Triangle, the latest novel in the Seeds of Civilization undersea adventure series.

New novel is set 2,100 feet deep in the “lost city of Cuba” Little is known about the actual discovery of “MEGA”—a city submerged in more than 2,000 feet of water off the Western tip of Cuba. While secrecy still clouds the real site, Archer takes his readers on a fictional tour of the underwater ruins and reveals some amazing connections to both the island of Cuba and the mysteries of the Bahamas.

I haven’t read the book and passing it along if you’re into this sort of thing.

During the edit of a 60-second spot using RED footage I used QuickTime proxy files. Although this meant continuous rendering of transitions and effects it was painless. Eventually I needed to conform the proxies to their 1080/24p ProRes 422 counterparts. I didn’t bother with Crimson because there were only about 20-30 cuts.

With speed changes and video effects reapplied I prepared for the final render. It wasn’t long before Final Cut Pro generated this error message:

The effect ‘Scrub’ cannot be rendered in a sequence of this size with the current graphics card.

The Scrub filter had been successfully used throughout the entire edit: from proxy files to scrubbing the timeline in ProRes. I tested different video effects and received the same error message.

A forum post at CreativeCOW describes a similar problem. This was just one of many issues plauging my project so I took the easy way out by replacing the Scrub filter with one from Joe’s Filters.

While I was writing this I found a solution at LAFCPUG. Modify the render depth from 10-bit to 8-bit in the sequence settings.

This solution is also referenced in an Apple Support document. Unfortunately it doesn’t address why late-model Apple video cards generate the error. Lack of 10-bit color support or a bug?

The upgrade from VMware Fusion 1.x to 2.0 was smooth except for an error from Windows XP’s Device Manager. Before I could install the newest VMware Tools, Windows complained about “missing driver for Base System Device.”

Dismissing the error I installed VMware Tools 2.0 but the error persisted. On this tip I reinstalled VMware Tools using the Custom option. The VMCI driver was already selected (a head scratcher since this would suggest it was previously installed) but I continued the installation. Upon restart the missing driver was found.

Today I was tussling with a client’s computer in an effort to remove malware. During the process Windows XP decided it was no longer activated and during a reboot demanded to be activated or I would be logged off.

Windows Product Activation was either hosed and/or the malware prevented me from properly accessing the Internet. I decided against the 4-to-8 hour reinstall of Windows and application software while preserving existing user data. My shortcut? A spare hard drive and legit copy of Windows XP.

Cracking open the PC case I plugged in the spare hard disk, disconnecting the original one. The next hour was spent installing Windows XP to the same Service Pack level (WPA has changed over time). Without installing any additional updates I copied the WPA data file (c:\windows\system32\wpa.dbl) to a USB flash drive.

Reverting to the original hard disk I booted into Safe Mode (which recognizes USB flash drives) and copied the wpa.dbl file to its respective location on C:. Reboot.

At login, Windows asked to be activated and prompted me with choices - I was no longer stuck. The rest of the process was quick and painless.

Regardless of your backup strategy consider keeping a copy of the WPA file. Lest I forget to mention it, the malware was successfully removed.