{"id":26,"date":"2004-08-02T00:00:41","date_gmt":"2004-08-02T08:00:41","guid":{"rendered":""},"modified":"2016-05-25T23:34:40","modified_gmt":"2016-05-26T06:34:40","slug":"smart-urls-and-smarter-404s","status":"publish","type":"post","link":"https:\/\/mikeindustries.com\/blog\/archive\/2004\/08\/smart-urls-and-smarter-404s","title":{"rendered":"Beautification Revisited"},"content":{"rendered":"
<\/span><\/div>\n
\n
<\/span><\/div>\n

Beauty comes in many forms. For normal people, maybe it’s Ashley Judd in a bedsheet on a Sunday morning. For web dorks, however, it can be something as mundane as extensionless URLs or intelligent error pages. Sad as that may be, most of us don’t have the Ashley Judd option available anyway, so we shouldn’t feel too bad about deifying code.<\/p>\n

Last week’s post on dirified URLs<\/a> was supposed to bring about some sort of consensus opinion on smart URL-naming conventions. Thanks to everyone who posted their very helpful and enlightening comments, but in the end, we only discovered more options and came to no mutual conclusions. It appears that people just look for different things in their URLs and what you do with yours is up to you.<\/p>\n

Having said that, I have completely redone my URL structure and 404 strategy at Mike Industries based on the comments received and some additional research.<\/p>\n<\/div>\n

<\/p>\n

\n

URLs<\/h3>\n

I’ve reached the conclusion that URLs should neither be automatically generated from post titles nor should they use an automatically incrementing number system. The inability to change a post title after publishing makes the former method too limiting. Combine that with the fact that auto-generated dirified URLs can get needlessly long or truncated awkwardly and you have a recipe for headaches.<\/p>\n

On the other hand, the latter method, which uses an incrementing numbering system, is not the least bit useful to humans who will inevitably need to interact with the raw URLs. URLs are not like ISBN numbers or database keyfields after all. Why? Because ISBN numbers and database keyfields are almost always dealt with by computers and not humans. The raw URL (besides as a simple domain name) was ideally supposed to be hidden from users, but the reality of our world is that it is not. It’s in the location bar, it’s on web pages, it’s in your history, it’s on TV, it’s everywhere. To not include at least some human-readable content in your URLs is to ignore how prevalent the raw URL has become in our visual routines.<\/p>\n

The other hot issue with URLs was whether or not (and how) to hide file extensions. There did seem to be a consensus that hiding extensions was necessary to properly future-proof URLs, but people disagreed on the best way to do it. Some people create directories based on the title of the post and throw an index.php file in the directory like so:<\/p>\n


\nStructure: \"\/of-mice-and-men\/index.php\"
\nVia the web: \"\/of-mice-and-men\/\" or \"\/of-mice-and-men\"
\n<\/code><\/p>\n

Others remove the file extensions completely from the files themselves like so:<\/p>\n


\nStructure: \"\/of-mice-and-men\"
\nVia the web: \"\/of-mice-and-men\"
\n<\/code><\/p>\n

And still others keep the file extensions on the files themselves and use an htaccess file or other server filter to serve the correct file like so:<\/p>\n


\nStructure: \"\/of-mice-and-men.php\"
\nVia the web: \"\/of-mice-and-men\"
\n<\/code><\/p>\n

The first example seems like the most popular, but it is also the most wrong. First, creating new directories for every entry is extraneous, and it introduces a convention whereby one should then encase all other site files in their own directories as well. Hassle. Pain. Not good.<\/p>\n

Secondly, and much more importantly, it creates two URLs and not one. “\/of-mice-and-men\/” and “\/of-mice-and-men” are not<\/em> technically the same location. One points to where a file should be and one points to a directory. Deploy a system like this and you’ll have people pointing to both locations, depending on if they use the trailing slash when linking to you.<\/p>\n

The second example seems the most extreme, and I like it, but it’s really URL-permanence we’re seeking here and not necessarily local filename permanence. If I switch publishing systems, like PhotoMatt<\/a> keeps telling me I should, I will of course be re-exporting all of my pages from a database, so the files themselves don’t matter so much. Additionally, removing file extensions from the files themselves introduces other minor problems like FTP mode negotiation, local file editing, and other non-crucial, but annoying side-effects.<\/p>\n

The third example is what I settled on. It provides the future-proof URLs I was looking for, without introducing other issues into my life. I’m not going to give a full tutorial on making this conversion here, since not all of the info is mine, but here’s an overview of what needs to be done:<\/p>\n

Take care of .htaccess<\/h4>\n

Add this to the .htaccess file on the root of your server:<\/p>\n


\nRewriteEngine on
\nRewriteBase \/
\nRewriteCond %{REQUEST_FILENAME}.php -f
\nRewriteCond %{REQUEST_URI} !\/$
\nRewriteRule (.*) $1\\.php [L]
\nRewriteCond %{REQUEST_FILENAME} !-d
\nRewriteRule ^(.+)\/$ \/$1 [R=301,L]
\n<\/code><\/p>\n

This instructs all requests for the file “http:\/\/yoursite\/whatever” to resolve to “http:\/\/yoursite\/whatever.php”. Keep in mind this is not a redirect and the user will never see the .php extension. The page will simply be served and the URL will remain clean. Obviously you can use this method with non-PHP pages as well… just change the file extension in the code above.<\/p>\n

Turn Movable Type on to your extension-hatin’ ways<\/h4>\n

First, head on over to M\u00c3\u00a1r \u00c3\u2013rlygsson’s site<\/a> and read through his excellent tutorial. M\u00c3\u00a1r is a believer in pure numeric URLs (based on date\/time) so I didn’t follow his steps verbatim, but I was able to achieve what I wanted by merely substituting these values in during Step 1 of his process:<\/p>\n


\nIndividual: <MTEntryDate format="%Y">\/<MTEntryDate format="%m">\/<MTEntryKeywords>.php
\nMonthly: <MTEntryDate format="%Y">\/<MTEntryDate format="%m">\/index.php
\nCategory: <MTCategoryLabel dirifyplus="pld">\/index.php
\n<\/code><\/p>\n

… and then changing the RegEx line in Step 2 to this:<\/p>\n


\n<MTAddRegex name="stripFile">s\/index\\.php|\\.php\/\/g<\/MTAddRegex>
\n<\/code><\/p>\n

So what’s the <MTEntryKeywords> tag doing in there? Ah, that is the key to solving the auto-dirification issue! Movable Type has a field called “Keywords” which is hidden by default in the “Create an Entry” screen. Click the customize button on your “Create an Entry” screen, check the “Keywords” box and boom… you’ve got another field to play with. Using the above steps, whatever you enter into the Keywords field will become the filename of your post. For instance, “a-walk-in-the-park” or “motorhead”.<\/p>\n

We now have complete control over our filenames, human-readable unique URLs, and no reliance on entry title permanence. Life is good.<\/p>\n

404s<\/h3>\n

With clean URLs taken care of, I wanted to follow through on some code that would thoroughly smarten-up my 404s. The idea, as spelled out in my previous post, would be to create a system whereby:<\/p>\n

https:\/\/mikeindustries.com\/vegemite sandwich<\/p>\n

… would automatically query all blog entries on my site, and if only one entry matched the words “vegemite sandwich”, it would instantly redirect the user to that entry. If more than one entry matched, it would take the user to a page listing all matching pages.<\/p>\n

Using Erik Barzeski’s code<\/a> as a starting point, I put together a smart 404 page which does exactly that. For some reason, Erik’s code wasn’t working for me, so I turned to my favorite PHP function “file_get_contents()” and all was well.<\/p>\n

Here’s what’s necessary to get the job done:<\/p>\n

Take care of .htaccess<\/h4>\n

Add this to the .htaccess file on the root of your server:<\/p>\n

ErrorDocument 404 \/404.php<\/code><\/p>\n

Create your PHP-based 404 page (404.php)<\/h4>\n

Here is the full-text of the 404.php page I created:<\/p>\n