Backstory on last night’s side project: a friend was lamenting the horrendous performance impact of bad URL references to an image repository that shares a home with his WordPress powered blog. The images are in a directory that rides sidebar to his WordPress installation; he has foobar.com as the WordPress install root and foobar.com/images is his collection of snaps. Pretty straightforward, until someone references foobar.com/images/nope.jpg where nope is a filename that doesn’t exist in the images directory. It happens relatively frequently – someone mistypes part of a pathname or filename, and you get a bad reference.
What you’d want to happen here is an HTTP 404 error – be told the file doesn’t exist so you can quite literally check your spelling. But in this case, users referencing the non-existent file get treated to the “home” page of the WordPress install living at foobar.com. My puzzle: make it stop, because those random references (when they happened) were killing performance on the target website, with what should have been simple image references generating full-scale WordPress content selection and generation.
Root cause: WordPress pretty permalinks. When you turn on pretty permalinks, WordPress installs the following code snippet in the .htaccess file at the root of your WordPress install.
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
This set of rewrite conditions is the magic that lets nice, mnemonic URLs with tag, category and title slugs in them go right through Apache and be parsed by WordPress. The two conditions say “if the requested filename isn’t a directory or file, load the index.php file”. You need this check because you don’t want to skirt explicit references to files like wp-admin; so if Apache thinks the URL is a synthetic one representing a pretty permalink, it lets WordPress deal with it.
But what if the URL points to a non-existent image file in that sister /images directory? In that case, the rewrite conditions are met (the file doesn’t in fact exist, even though the fat-fingered author wanted it to), and the URL is handed off for parsing and interpretation. Except it doesn’t match any known keywords for categories, archives, or tags, so WordPress does a best guess and returns the home page. You don’t get a smart JPEG image; you get a lot of smart words.
The fix is relatively simple – tell Apache to treat the images directory as a special case by adding the following line before the WordPress-installed content in .htaccess:
RewriteRule ^images/(.*) images/$1 [L]
This rewrite rule says “if the URL has images/ after the domain name, return that URL and stop rewriting”. If the image file exists, Apache returns the pretty picture, and if not, you get a less than pretty 404 error. But there’s no pretty permalink parsing attempt.
That’s just one of the things I’ll be talking about at WordCamp Chicago this weekend; if you’re around buy a ticket (you’re getting 16 hours of WP smarties at less than $3 per hour) otherwise I’ll post the slides here after Sunday’s gig.
[ad#Google Adsense]
Comments are closed, but trackbacks and pingbacks are open.