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
-
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.
-
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.
-
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!
-
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.
