I spoke too soon. Last night, I wrote:

I think I’ve tested it. I think I’ve fixed all the (sufficiently important) bugs. But that’s just me wearing my developer hat saying “It works on my machine.” If you happen to notice any problems with the new WordPress theme, I’d be most grateful if you could let me know. Oh, and you can let me know if you like it too. Thanks!

Within minutes of posting that, I realized that the graphics were jaggy and ugly on a PC. Hmph. So I pulled down the new look and the “New Look” post, and went to bed grumbling about ugly PCs vs. beautiful Macs.

Depending on your perspective, I either pulled it down too fast, or not fast enough. By the time I pulled it, Google had already indexed it, and feed readers all over had already gotten the new post via RSS. But when folks went to the site, they got the old look, and no sign of the “New Look (Beta)” post. Confusing to say the least.

But if I’d done things differently, I wouldn’t have gotten Zach’s hilarious email this morning chronicling his adventures trying to find the mysterious “New Look” post.

Anyway…

What I suspect (um, hope) you all don’t know is that I spent a fair amount of time last night fixing functional problems with the site through the tried-and-true, but oh-so-cowboy, process of take-it-live, find-the-fatal-error, take-it-down, fix, and repeat. So by the time I posted the “New Look (Beta)” message I had already solved numerous very real problems and just wanted to be done.

Bugs showing up in production that didn’t show up in the development and test configuration? How could that be?

In trying to create a development and test environment on my local network, I downloaded WordPress and installed it on my Mac. And I then used the Default theme as a starting place. You see, I don’t actually know PHP, and am relatively unskilled at WordPress theme creation. So starting with something that works well, then tweaking it until I got the look I wanted, seemed like a good way to go. (Some of you may be thinking, “Wow, this site looks nothing like the default.” Behold the power of CSS. That, and I learned an awful lot over the last couple of days about how WordPress works. But I digress.)

When I took the new theme live for the first time last night, I discovered my fatal error. The version of WordPress on my local machine is 2.3.1. The version of WordPress installed by my host, GoDaddy, is 2.0.4. And the new theme was incompatible with the version 2.0.4 of WordPress. I got fatal errors all over the place.

So at this point (about 10PM my time), I decided to do something that I would never do if this had been a real software project with real consequences. I decided the fastest way to get from broken to working would be to:

1. Look at the live site to get the error message.
2. Change back to the old theme while I worked to fix the bug.
3. Grep the local files to figure out where the offending code was coming from.
4. Fix each instance of offending code and test locally.
5. Upload the fixes.
6. Change the presentation to the new theme and go back to step 1. Repeat till done.

Cowboy, yes. But it worked. Within 15 minutes I’d fixed all the fatal errors and the site was actually functioning. Like I said: not recommended for real projects, but this is my blog, not a mission critical web app. And it would have taken me at least an hour to downgrade my local WordPress instance and do this the proper way. I didn’t have an hour.

After all that, I was so proud that it worked, I overconfidently posted the “New Look (Beta)” message. And only then did I finally got around to looking at the new site on a PC. In retrospect, that was the wrong order to do those things in. In any case, looking at the new design on a PC was just depressing, and I’d had enough for one night.

This morning, I figured out that although Macs make scaled-down images look nice in a browser, PCs don’t. I’d taken a shortcut and rather than resizing the images properly as I tweaked the design, I just used the WIDTH and HEIGHT attributes in the IMG tag to change their size. The result was that the images looked oh-so-1985 jaggy on a PC.

This whole experience underscores the importance of cross-browser and cross-functional testing before taking a site live. I knew that. Really I did. But I ignored it because my local network just isn’t set up to make this kind of thing easy. I knew it would be a little bit of a hassle to get a PC to surf to WordPress hosted on my Mac, and I couldn’t be bothered. I was overconfident about my ability to create designs that work cross-browser and cross-platform. And I was willing to take the risk if I was wrong. Mostly, I was just being impatient. I wanted to get the new look live before I went to bed, and I was tired and wanted to sleep.

These are all really bad reasons not to test. But then this is why I develop my own websites instead of outsourcing the effort. I need these reminders of how easy it is to choose to do the wrong thing for bad - but legitimate sounding at the time - reasons.

You see, I hear “we can’t do that kind of testing because it’s too hard” from my clients on a regular basis. And it would be too easy for me to become all judgmental and say “it’s not that hard; you’re just lazy.” But I can’t say that because I make the same dang mistakes in my own development. So instead of grumbling about lazy developers, I say “I know it’s hard. But it’s important. So instead of telling me that it can’t be done, please tell me what it would take to make it more feasible, and we’ll work on that.”

Oh, and for the record I’ve now set up my Mac and PC so I can surf to the test site running on the Mac from the PC easily. (Mostly that involved adding entries to the hosts file on the PC.) Still haven’t downgraded my local WordPress instance, but I will before I do any more serious theme development. Next time will be different. But since I tend to do these big site redesigns about once a year, next time is also a long way off.

Unless y’all absolutely hate the new look. So tell me what you think…