I became aware of an annoying little glitch on the Urban Mainframe yesterday. It seems that WordPress, on which this site is running, doesn’t handle the URL http://example.com/index.html on an unmodified install (I’ve confirmed this on a handful of other WordPress sites). This is significant because index.html is a special file on many web-servers, often being the “home” page of a directory on the server. Without special handling, a request for index.html on a WordPress installation generates a 404 (file not found) error — which is obviously something we don’t want our visitors to be presented with.

In my case the impact of the glitch was magnified because I employ a quite aggressive caching policy on this website — and yesterday an unlikely combination of factors resulted in my 404 error page replacing my home page for a complete cache cycle. It went something like this:

• cached “home” page expires
• next “home” page request is for http://urbanmainframe.com/index.html
• index.html file request results in a 404 error
• 404 error page is cached
• all subsequent requests for http://urbanmainframe.com/ — and other “home” page URLs — return the cached 404 error page until the cache is next invalidated

Quite a serious glitch then!

There are two things that shouldn’t have happened here.

1. Requests for index.html should not result in 404 errors.
2. Error pages should never be cached.

I resolved the first issue by adding the following snippet of code to the very beginning of the 404.php file in my WordPress theme:

<?php
if ($_SERVER['REQUEST_URI'] == '/index.html') { header("Location: http://urbanmainframe.com/"); exit; }
?>

For the second issue I’ve filed a bug report with the authors of W3 Total Cache, which is the caching system I use here on the Urban Mainframe.

A large part of my professional work involves the build and deployment of WordPress-based websites. Now as any designers/developers among you will appreciate, it can be extremely annoying frustrating to sign off a build only to come back later to see that your client has (inadvertantly) messed things up because WordPress has placed too much power in their hands.

I was delighted then to read “10 WordPress Dashboard Hacks” because there are some really useful code snippets presented therein:

• Remove Dashboard Menus: At last I can remove certain menus from the client’s view — whilst obviously still leaving full control for the Admin user
• Define Login and Dashboard Logos: Great for branding.
• Disable the “Please Upgrade Now” message: I never want my clients to do this. I think this is one of my responsibilities.
• Customise Dashboard Widgets: Again, it’s about keeping control. Not exposing the client to things which could be hazardous.
• Provide Help Messages: Because they’re helpful (if done correctly).

Some of these are definitely going to be rolled out on to some of my client’s sites in the near future.

An interesting WordPress plugin from Joen Asmussen. I don’t think I’ll employ it at the moment but it’ll be worth keeping an eye on the plugin’s development.

A long time ago, in a galaxy far, far away… oh sorry, wrong script. I’ll start over. In the dim and distant past, I wrote about my efforts to eke a little bit more performance out of the WordPress installation that this glorious website runs upon. What I’d done was fairly basic: content compression, reduced page weights, database tuning… the usual stuff.

I also described how I’d failed to get WP Super Cache working and wrote that I was investigating PHP accelerators. Yet, despite my endeavours, the website’s performance continued to be, well, pitiful. Some time later I managed to get WP Super Cache working and things improved, but were still disappointing to me.

I come from a mod_perl background and one of mod_perl’s strengths is the speed at which it can run its applications. The PHP app’s that I now find myself working with just can’t compete. I believed that I’d just have to accept that the performance goals I was aiming for weren’t achievable.

However, I was recently forced to reconsider my position when I was contracted to build a website on top of the Zend Framework — because, despite being written entirely in PHP, nursesstore.co.uk turned out to be very fast.

Suddenly, I knew that it was possible to build fast PHP applications. So I turned my attention, once again, to the speed-deficient Urban Mainframe with the fire of the true zealot burning in my eyes.

Continue Reading…

The paint has now dried on the redesign of the Urban Mainframe’s home-page. The celebrations have begun to diminish and normality is being restored. As the dust settles, I thought I’d write a little about the thought processes behind the design. I’d also like to document a few of the little tricks I’ve employed (because I’m ever so proud of them).

Despite trying various tweaks and reshuffles of the previous version of the home-page, I was never totally happy with it. Looking back, I think I tried to convey way too much information on that page, which made it look terribly cluttered. It simply didn’t “feel” right to me. The problem was that I had no idea of how to remodel it, no inspiration.

Continue Reading…

Photo Credit: Syntax Error - Folded Up Beyond All Recognition by Simon Pow

Oh the weather outside is frightful
By my Mac it’s so delightful
Sign on to my WordPress node
Hack the code, hack the code, hack the code

Er, sorry about that folks (and Mr. Brooks). So I’ve spent my weekend fooling around with WordPress plug-ins and enjoying some hard-core coding action with a hot PHP interpreter. The results of which, are a handful of new features on this site, a few little things that should make your stay here even more rewarding than it already is (I know, I know – that hardly seems possible – but I’ve managed it, superstar hacker that I am.)

Continue Reading…

Photo Credit: George Steinmetz/Corbis, © National Geographic

A directory of my recent bookmarks. Maximum coolness!

Continue Reading…

I recently finished working on a project for Qwerty Design, a website redesign for Whiteghyll Visual Fabrications Limited. Richard Dale over at Qwerty designed it and I produced the CSS, markup and added a little bit of WordPress magic.

Continue Reading…

Let’s say you have an existing WordPress site that needs a bit of a visual refresh. The design changes are large enough that it’s not really something you could do quickly on the live site, and you don’t want the site to look jacked up for the one or two days that you’re working on it. You could duplicate the site and database and work with the clone or… you could use WordPress’ live theme preview. A neat discovery by Brandon Weiss.

Photo Credit: “Hide the Graffiti!” by incurable_hippie

Here’s a small but incredibly useful snippet of code I’d like to share. When I’m developing WordPress websites, I often find myself in a situation where I need to code on a site that’s actually live. Naturally I want to keep my prototyping invisible to the visitors of that site. After all, I don’t want anyone seeing all my mistakes now do I?

The following wrapper can be applied to a block of code and the results will only be visible on the live site to users who are logged in with admin privileges.

Continue Reading…