Giving up on a local WordPress install on Mac.

Summary

WordPress is nice, but setting up a local instance in a nonstandard environment is more trouble than it's worth. WordPress was designed for shared-hosting environments that have a classic "LAMP" application stack preconfigured (Linux+Apache+MySQL+PHP). It was specifically not designed to run on a wide variety of server environments.

Fortunately, for the kind of work I want to do (blog template design) there are acceptable workarounds. But this latest encounter with the MySQL and PHP ecosystems has left me, once again, sorely tempted to just build my own blogging system.

Read on if you want to geek out on some of the details. If you just want the conclusion, it is: use a standard virtual machine (VM) or set up a sandbox blog in a shared environment. Either one of those will work well enough, and the VM approach is probably the closest you'll get to a "safe" install. Unless you're being paid for the setup time, I strongly advise against trying to make it work locally in anything but a stock configuration.

Motivation

A while ago I set up a blog with a friend of mine: Migratorium. It's an outlet for our travel writing, or at least it will be.

It runs on WordPress in a shared-hosting environment over at Dreamhost: bang, meet buck, at least for small projects. I really like the WordPress user interface, but even with great templates like veryplaintxt I quickly became frustrated with the design possibilities.

In short, you have to learn some PHP (painful but not so hard) and the arcane, under-documented WordPress templating system (ditto) in order to do any meaningful design. Since I already know HTML, CSS, Perl, and Template Toolkit, I thought I'd be much happier building my own sites using those technologies. And it would keep me away from PHP, which I dislike, and MySQL, which I abhor.

Then I thought about setting up an RSS feed. No biggie, just another afternoon. Then I thought about setting up a decent editing UI. No biggie, just another weekend. Then I thought about making it easy for my non-computer-geek friends to use. Uh-oh... that started to sound like real work.

So I decided to make at least one serious effort to teach myself enough WordPress Templatese to either do serious design in that ecosystem or give it up from an informed position. And for that I need a local copy of WordPress in which to hack the templates.

Technical Goals

I'm doing this on an Intel Mac running the latest version of Leopard (OS X 10.5.5 as of this writing). I use lighttpd as my local web server and would prefer to use that, but I will use the built-in Apache if I must. I have MacPorts installed, but I would prefer to run this under the system default PHP. I also want this to run on SQLite if at all possible, since I want to hack templates, not databases.

Trying to Get There

1. I checked Google first.

   Oh-oh. The first thing I found is that only MySQL is supported, as WordPress doesn't have a database abstraction layer. That's a shame, but it seems like an absolute.

   There is one plug-in that gets you close: PDO, but its limitations make it sound just about as onerous for my purposes as MySQL itself.

2. Install MySQL

   OK, let's see if this can be done with minimal exposure to MySQL. 2 tablespoons has some instructions for getting MySQL running under MacPorts. That almost worked, but not quite. Following more info under the comments I found I had to set the socket file in /opt/local/etc/mysql5/my.cnf:

   [mysqld_safe]
   socket = /tmp/mysql.sock
   [mysqld]
   socket = /tmp/mysql.sock
               

   I also had to create the run directory:

   sudo mkdir -p /opt/local/var/run/mysql5
               

   Now I was able to start the system, but everything complained about the socket file location. I fixed that in my aliases in .bash_profile:

   # evil mysql is required for local wordpress
   alias mysql5='mysql5 --socket=/tmp/mysql.sock'
   alias mysqladmin5='mysqladmin5 --socket=/tmp/mysql.sock'
   alias mysqlstart='sudo /opt/local/bin/mysqld_safe5 &'
   alias mysqlstop='/opt/local/bin/mysqladmin5 -u root -p shutdown \
   --socket=/tmp/mysql.sock'
               

   Backgrounding your startup command with & is a Very Bad Practice but it seems like that's what mysqld wants; I may be using the wrong command altogether. Also note that you will almost certainly have to set that socket location explicitly in other commands/configs as well. Once you have the above aliases in effect don't forget to set your MySQL "root" password (not to be confused with the system root password). Press RETURN at the Password prompt, or enter whatever the previous password was.

   mysqladmin5 -u root -p password MYSECRETPW                
               

   At this point I'm able to connect to the database server with mysql5 and issue some simple commands, so I consider it done-ish after about two hours of work. Further tweaks will be listed below.

3. Pour another glass of tasty Basque wine; do not give up yet!

   This little exercise is already confirming my various prejudices against MySQL and PHP and all sloppy engineering everywhere in the universe. But man, I do love that editing UI. Must... persist! Thank you Xarmant Txakolina!

4. Install PHP from source. Ouch.

   I'd actually gotten far enough to have the PHP running, more or less, though without valid HTTP headers and without a successful database connection. And then I hit the php-cgi wall. Turns out you have to install from source, the standard install doesn't work properly with lighttpd.

   Fortunately Simplistic Complexity had a helpful blog post.

   Unfortunately that doesn't work with MySQL installed via MacPorts.

   I tried a few of the obvious tweaks to the make process and realized I would have to reinstall MySQL. And that's where I hit the wall.

Hitting the Wall

Having spent most of the day on this and gotten very close, I had to ask myself: Is it worth it to push on through?

Since I make software for a living I'm always tempted to put on my Big Fat Engineer's Hat and complain about the quality gaps in whatever piece of software I'm pounding my head against at the moment. But that wouldn't be even close to fair in the WordPress case: here is a product I really like as long as I don't have to look under the hood; and its content-management UI is frankly more usable than any equivalent thing I've ever built, and even if it is finicky on the server side I think the proof of its value is in the client experience.

I love WordPress for its content-management UI, and there's no special reason why its installation prerequisites or developer documentation should be tailored to my needs. If I cared that much I could contribute to the project, or fork it, or write my own.

So in the interest of fairness to a justly popular blogging system, and also in the interest of my own sanity, I gave up on my little snowflake of a local WordPress installation.

Instead, I'll try it their way and see if I can make some headway with the templates. A lot of generous people have given a lot of their time to this open-source product, and I still hold onto the hope that I can more easily beef up my WordPress templates than use (or write) a different blogging system.

To be continued (perhaps virtually).

I think the most sensible thing to do now is install a VMWare image with a recent version of WordPress. It looks like rPath has one.

That has the advantage of still being more or less "local" even if a bit resource-intensive; and if it doesn't work, it's always possible to just set up a sandbox WordPress account with an obfuscated URL.

I'll be sure to update the blog with the results of that operation when I have time for it.