No, that’s not backwards. My three-month experiment was an unexpected failure. While WordPress is easy to install, feels very slick and has some innovative features (especially with Ajax plugins), there have been enough serious problems that I have gone to the effort to move back to MovableType. Tonight, I’ll highlight the three most serious problems I’ve had. In part 2 (later this week), I’ll detail what was involved in migrating from WordPress to MovableType.
- WordPress has too many updates – In mid-December, I installed WordPress 2.0.5, which had been released in late October 2006. There were five subsequent releases:
January 5, 2007 2.0.6 “important security fix” – this was unspecified, but as it’s a security fix, I applied it. January 15, 2007 2.0.7 “PHP vulnerability fix” – again, unspecified, but something they’re able to work around. January 22, 2007 2.1 “major release” – includes some very cool features. I had known this was coming. February 21, 2007 2.1.1 “minor bug fixes.” Okay, it’s been a month, minor bug fixes, sure why not. March 2, 2007 2.1.2 a security exploit” had been introduced in the 2.1.1 distribution. The “emergency upgrade” was the last straw. It’s bad enough they’re always having to patch security issues, but having a release compromised is not encouraging.
- PHP is fragile – Though it seems ideal for the web,
there appears to be enough instability between PHP versions that things break. Randomly. For example, in mid-February, my web service provider started upgrading their machines to 5.2. They reverted, rescheduled, then retried using a subsequent version. In the mean time, functions on my blog were breaking in bizarre ways. For example, Steve reported that perma-linked pages were blank. I hadn’t changed anything, nor were there errors in the Apache log files. I went through all of the WordPress configuration menus, finally identifying a workaround: untick the “WordPress should compress articles (gzip) if browsers ask for them” option. huh?
Then my comments mysteriously broke because the plugin that had been working with the earlier version of PHP 5 was somehow incompatible with 5.2.x. I don’t recall point release of perl ever being fragile. - WordPress truncates tables. While editing this entry, I pasted in a table from Excel. It previewed nicely, leaving me impressed with the WYSIWYG editor in WordPress. When I saved it, the table was truncated. Lather. Rinse. Repeat. In haste, I pasted an image of the Excel table.
Later, I noticed several of the blog entries that I imported also had parts — all tables — truncated. For example, in my how to (not) lose 95 pounds by April, I had a table that looked like this:<table> <tr valign=top><td align=left><b> The basic truth:</b></td></tr> <tr valign=top><td align=right> Weight loss (lbs)</td><td> = </td><td>(calories burned - calories consumed) / 3500</center></td></tr> <tr valign=top><td align=left><b> Rearranging the equation:</b></td></tr> <tr valign=top><td align=right> Calories Burned - Calories Consumed</td><td>=</td><td>Weight loss (lbs)* 3500</center></td></tr> <tr valign=top><td align=right> Calories Burned - Calories Consumed</td><td>=</td><td>12 pounds * 3,500 calories / pound </td></tr> <tr valign=top><td align=right> Calories Burned</td><td>=</td><td>42,000 + Calories Consumed </td></tr> <tr valign=top><td align=right></td><td>=</td><td>42,000 + 2,000 calories/day * 7 days </td></tr> <tr valign=top><td align=right></td><td>=</td><td>42,000 + 14,000</td></tr> <tr valign=top><td></td><td>=</td><td><b>56,000 calories</b></td></tr> </table>
WordPress mangled the source, leaving only this showing:
The basic truth:
In this particular example, I would have ideally enclosed the html options in quotes. But that’s a browser problem. I don’t know why wordpress refuses to save what I tell it to save.
It’s going to be tedious going back and verifying my favorite entries. Thank goodness I made a site backup before I did the switch.
Ouch. Ouch. I’m sending sympathetic vibes your way (especially about the tables — losing content is just not acceptable!).