When I first got my G5 XServe, I tried setting up Movable Type the “normal” way (using MySQL), but for some frustrating reason, the MySQL that comes pre-installed on Mac OS X Server 10.4 is missing a key perl module that allows Movable Type to interact with MySQL, so after days of trying to install the module via CPAN, I gave up and used SQLite. It works fine, but it’s tough to find tools to deal with SQLite databases the way you can with MySQL databases using, say, phpMyAdmin.
So, when my colocation facility informed me that it was dramatically raising the price for XServe customers, I bought the on-paper faster dual-core Mac Mini and Mac OS X Server 10.5. Again I tried setting up Movable Type using MySQL, but ran into the same problem. I wondered about WordPress, but figured it would have the same database connectivity issue as Movable Type, so I didn’t even try it. (Also, I wasn’t keen on the idea of having to transition everything from Movable Type to WordPress on my tight schedule for swapping out the servers.)
Last week, however, it occurred to me that one of my sites might benefit from having blog/CMS software available, and rather than install another instance of Movable Type, I took a shot at WordPress (see here for a potential installation gotcha). I fully expected to fail, because unlike Movable Type WordPress works only with MySQL; there is no option for SQLite.
So, I set up a new MySQL database, downloaded WordPress to the destination folder, checked ownership and permissions, and then called up the install wizard in my browser.
No go, but as I said, it was no surprise.
Just as I was about to delete WordPress and proceed with Movable Type, I opened Terminal.app to delete the database I’d created. However, the response to every command I typed was that as root @ localhost I didn’t have permission to access MySQL! On a whim I opened up my MySQL management software and tried to delete the database, and was given the same message.
On a whim, I tried gaining access as root @ the FQDN for my server, and it was granted immediately. Ah ha! I then edited the WordPress config file to reflect the FQDN in place of the localhost designation, and from that point on, everything ran flawlessly.
My initial failure with WordPress (localhost vs. FQDN) may be more of an issue with the way I have my server set up than anything else, but the bottom line is that WordPress does run on an unmodified, unpatched, untinkered-with Mac OS X Server 10.5 using MySQL where Movable Type apparently does not.
Note that there are those who scrap the pre-installed MySQL and then install their own version from scratch, but really, even my geekiness has its limits, and that is beyond mine.
My only problem now is that I must decide whether the game of transferring my existing Movable Type CMS to WordPress is worth the candle. As luck would have it, the first several hundred entries have nice HTML tags and transfer over beautifully. I subsequently became lazy on my data entry, though, and began relying on Markdown and SmartyPants, and for reasons not yet understood, the WordPress Markdown and SmartyPants modules handle Markdown syntax much differently than either Movable Type or BBEdit. I may have to hack the modules to get the same results, as I don’t see myself going through my Markdown entries in the Movable Type export file and recoding them with HTML tags. Ugghh.
Well, at least the Movable Type install is running fine … there is no reason to transfer that section of the site to WordPress. And, for all future CMS installs, I can always use WordPress. I’ll just have to remember to change my rsync backup strategy to include the MySQL databases for the WordPress installs, as the SQLite backups are simply file transfers — one of the benefits of using SQLite.