NSLog();

I last wrote about the 404 Search in February 2003 (both here and here. Since that time, I've been using the 404 search code quite heavily on every site with MovableType (or any other blogging package).

It's undergone some improvements, however, and the version currently used on The Sand Trap looks like this. An explanation - and a question - follow.

The first three lines grab the filename from the (incorrect) URL (i.e. http://thesandtrap.com/archives/blah/some_url_here.php -> some_url_here.php). If the filename is one common to Internet viruses that troll for IIS servers, I simply exit quickly. I could put this if clause just before the explode and probably save a little processing time, but I think leaving it where it is makes the code easier to read.

Because MovableType's built-in search doesn't know much about filenames, I strip the file extension and save it for later. Then I create the variable for the basic search URL. The extension is important if the filename is .jpg, .gif, or .png - my staff members and I routinely re-use stock shots of people like Tiger Woods, Annika Sorenstam, etc., so occasionally we look for prior use so that we can properly attribute the image's copyright. If we're looking for an image, I add the extension back to the search term; otherwise, I strip the underscores and replace them with spaces ("%20" is a space in a URL) because The Sand Trap's filenames are "dirified" versions of the article, so "Bobby Jones Wins Again" becomes "bobby_jones_wins_again."

Along the way, I quickly compose an email to myself (it helps me to monitor missing files, as these searches are only triggered via a 404).

Finally, I implode the results of the file() call (a byproduct of which is that the search is actually performed) to create one big string. I match the string against something that appears in links to the matching articles: class="search result". If only one match is found, I forward the user directly to that article. If more than one match is found, I print the search results.

This search function has served me well (I routinely type http://thesandtrap.com/search term here to perform quick searches), and the "automatic forwarding" works in certain cases to shuffle people along. For example:

http://thesandtrap.com/archives/clubs/titleist_introduces_735_cm_combo_irons.php

Unfortunately, I've noticed a trend lately for some search results not to work as one would hope. Take this, for example:

http://thesandtrap.com/archives/clubs/sneak_peek_at_taylormades

I think what is happening is that some people may send an email and, due to line-wrapping in email clients, people are not getting the full URL:

http://thesandtrap.com/archives/clubs/sneak_peek_at_taylormades_2006_new_products.php

What's worse, because the article does not include "taylormades" - the title includes "TaylorMade's" with an apostrophe - the article that should appear does not appear in the search results. What's even worse, since we link to the "sneak peek" article in a review, the review thus contains "taylormades" (as part of the URL in the link), and so the reader is forwarded there.

Ideally, there would be some fast way to look at filenames and, if something is close, to send the user there. But that seems altogether too tedious: files are located in several directories and people don't always include every directory (i.e. searches for /clubs/blah_blah_blah are common, but the file actually resides in /archives/clubs/ - another directory down). This may not be too big a problem, as every article is inside of /archives/xxxxx/file.php where xxxxx is the category.

Does anyone have any suggestions? The "chopped off filename" happens frequently enough that I'd like to resolve it, but I'm not sure how to do so quickly and without searching through every folder inside of archives. I figure the code to forward the user to the proper URL would fit in best where I have commented "TAKE USER TO TRUNCATED FILENAME IF EXISTS," but I'm open to suggestions.

Anyone have any? Feel free to comment on other portions of the code, but please don't be upset if I don't pay attention to those comments: I'm primarily interested in getting the last bit working.

P.S. The search code I use here on nslog.com has a few other pieces in it. You can view that source here. It has the distinct advantage of allowing me to type "http://nslog.com/123" to visit the entry with the entry ID 123. Before I discovered the "dirify" (now "basename" in MovableType 3.2), my articles existed at http://nslog.com/000123.php and the code you see in this modified version forwards the user to the new URL for me.

Comments RSS