First steps were the usual round of updates to install, update to WordPress 3.2.1 and a new theme with some little tweaks from me. This even included the usage of one of Google’s web fonts. World of wonders, this even worked in the three browsers, that I tried (Firefox, Chrome and IE8).

Of course, the usual problem solving was also necessary. Blogging clients like Blogilo or ScribeFire wouldn’t get the older posts list from the site. To fix this PHP’s memory limit needed to be changed. With WordPress 2.9 16M was enough. Now with WordPress 3.2.1 after some tries I set the limit to 36M, the maximum, which my provider allowes.

Again, I did the update a bit different compared to the documentation on the WP site. First I compared the files from this site to the WP 2.0.2 distribution directory to find out about any local changes. In my case I modified wp-comments-post.php to support AuthImage. Then I compares to distributions 2.0.2 and 2.0.4 against one another to find out about new or changed files. This is the list of changed files. I zipped them after having included the changes for AuthImage in wp-comments-post.php, transferred them to this site and extracted them in the WordPress installation directory. Done.

This worked for me, it might even work for you.

Anyway, I mirrored the data from the website to my local Linux box, first to have backup and second to do the actual update on the local system. Update went smoothly due to the very good instructions. After that I needed to update some plug-ins or reintroduce the changes, that one of the plug-ins required. Since I only use AuthImage, Markdown, IImage-Browser and Spam Karma 2 this wasn’t much work.

Finally I deactivated the plug-ins on the website, rsync’d the local WordPress directory to the website, ran the upgrade.php script and reactivated the plug-ins. Done.

Cudos to the WordPress developers. I guess, it’s now time to create some new theme and update the look of the site.

./jblogeditor -vmargs -Dhttp.proxyHost=proxy.... \
    -Dhttp.proxyPort=81

Might have been obvious to someone with more Eclipse experience.

Anyway, I’m still running the September, 2001 version of TWiki with some local design modifications. Since I have redesigned my departments website, I thought, it was time for an Twiki refresh as well. A release candidate for version 4.0 was announced recently on freshmeat, so I gave this version a try. And I must say, that I’m very probably going to switch to Drupal. I found TWiki’s customization layer not very user friendly and somewhat hard to understand. There are so many files with so many TMPL definition. In the end I might not have tried hard enough to understand it all, but it sure looks intimidating. Drupal on the other hand was very easy to understand, one template file styled with CSS. To have a little more flexibility, I installed the PHPtemplate engine and after about a hour I had a basic working design implementation even though I never have programmed one line in PHP. With the installed Markdown module, text input for any user will be just as easy as with a Wiki.

So, I guess, Drupal will be it in the end.

Either the SPAMMERs found a way around AuthImage by examining the image or WordPress sports another security bug. Anyway, this SPAM is really annoying. I guess I have to have a new look at the available WordPress plugins.

Since I’m fortunate enough to have SSH access to my web site, I was able to quickly rsync the WP directory from the web site to my local backup directory, make an additional backup, patch WP with the command “patch -l -N -p1 -b -Vsimple” with the above patch file and rsynced the WP directory back. The patch applied cleanly, although I have the plugins AuthImage and IImage Browser installed.

This was an update with really very minimal hassle.

So, I finally found the time this evening to update both version. All went pretty smoothly. Even better than described in the documentation of both products, since I’ve ssh access to my website I could apply rsync for the task. This increased the transparency greatly. And in case of WordPress I executed this find command: find wp-admin/ wp-includes/ -type f -exec touch -t 200501010000 {} \; before the upload of the new files. This command set the time stamp of the file to the 1st. January 2005. This allowed me to distinguish any possibly on longer used old files from the newly installed.