If you’ve set up WordPress in a localhost testing environment you may already be familiar with the vagaries of site_url and home.

Basically, these values correspond to the “WordPress address” and “Blog address” fields under the Options section of the WP admin interface. For a localhost install you’d, quite naturally, want to pick something based off of localhost. This won’t be too useful though if you plan to view your WordPress site from other machines. (That includes virtual machines on the same computer—like, say, testing Internet Explorer from Parallels on your MacBook.) WordPress will hand out URLs literally containing localhost, prompting your remote machine to immediately turn around and begin contemplating its own navel. No good.

Okay then, so what about using an IP address instead?

Therein lies the rub. What if your machine moves from network to network (like said MacBook) or is on DHCP? That’s a rhetorical question of course, since I wouldn’t be writing this if I hadn’t already gone ahead and done this (precocious lad that I am). If you hard-code an IP as the value of site_url or home, and the IP of the host changes, large swathes of your WordPress site (including the ever-important admin) will become inaccessible.

It really comes down to what’s more valuable to you. If you simply need a self-contained development environment, stick with localhost. If you’re like me though, and need a platform to test against, the IP address is really the only way to go that I know of. So what’s really needed to make this latter case workable is a quick way to update site_url and home. And no, you can’t just go into the WP admin and change them. (The admin will be out of commission by the time you find out what your new IP is, remember?)

There are instructions out there for doing this kind of update via phpMyAdmin, but I prefer going straight to MySQL. To see what the current values are use the following SQL statements (where blog is the name of your own WordPress database):

SELECT * FROM blog.wp_options WHERE option_name = 'siteurl';

SELECT * FROM blog.wp_options WHERE option_name = 'home';

The current addresses will be under the option_value column. To edit these use the following, again replacing blog with the name of your WordPress database and inserting your own IP/blog path where appropriate (without trailing slashes):

UPDATE blog.wp_options SET option_value = "http://xxx.xxx.xxx.xxx/blog" WHERE option_name = 'siteurl';

UPDATE blog.wp_options SET option_value = "http://xxx.xxx.xxx.xxx/blog" WHERE option_name = 'home';

And there you have it. A fast update that lets you maintain a portable WordPress testing environment.

While gearing up to get the latest version of Stuntbox out the door I set up a new localhost testing environment on my MacBook. That included fresh installs of MySQL and WordPress (using the already-baked-into-OS-X versions of Apache and PHP). Nothing unusual there.

Apparently it had been a little while since I had actively used the combination though, because somebody went and made some changes while I had my back turned.

Cue Breaking Glass

If you’ve ever set up PHP/MySQL on OS X you know it’s no big deal. Uncomment a couple of lines in Apache’s http.conf file, then download a fresh MySQL install and follow the relatively straightforward instructions. (You always remember to secure your initial user accounts, right?) If you’re used to this sort of dance the whole thing will take you all of a half hour, if that. So I wasn’t paying too much attention post-install when I started throwing other applications into the mix. Phooey on me for not testing the PHP/MySQL connection first though because WordPress immediately coughed up the following hairball:

Error establishing a database connection. This either means that the username and password information in your wp-config.php file is incorrect or we can’t contact the database server at localhost. This could mean your host’s database server is down.

Well my wp-config.php was fine, and MySQL was very much up and running, so that left the database connection. After some trial and error with Google I came across a tech note on Apple’s support site called Mac OS X Server 10.4.4: Improvements to Apache/PHP/MySQL. Turns out that, as of OS X 10.4.4, the default socket location for PHP and MySQL has been moved. Fortunately an easy fix is detailed under the second section of the note. Basically it comes down to editing the socket location in your php.ini file (or creating one if it doesn’t exist yet).

I find it more than a little odd that I had to dig up a note about the server version of the OS to uncover an explanation from Apple about this. That’s important because, while there are other fixes out there, this is the only that has any hope of explaining why the change was made.

Snow Leopard Update

Since this post was originally written, OS X 10.6 “Snow Leopard” has been released. A modified version of the above instructions now applies.