Tag: Search

Wow… Ask.com just became a serious contender (again?)

It’s been around for years, but frankly I’ve never given Ask.com much serious attention. There never really seemed to be anything wrong with it; it just wasn’t anything special. So I used Yahoo!… then Hotbot (remember that one?)… then AltaVista (known today only for its notorious offshoot, Babelfish)… then Google. Ah yes, Google… the end all be all of search engines.

Well… maybe.

Check out Ask.com. Not only is it glossed up with Web 2.0 goodness, it actually has some really cool features. Of course the search box has AJAX-based auto-complete. But it’s the results page that’s really impressive. I did a search on John Coltrane (of course… but not solely out of narcissism) and here are the results.

Everything fades in nicely as the results come back. The main column is your typical search results list. The left column gives a bunch of suggestions for narrowing or expanding your search, as well as searching on similar or related topics. The right column is what’s really cool though: different sections feature images, audio, an encyclopedia (well, Wikipedia) entry, and YouTube videos.

Sure, all of that stuff on the right side reeks of “synergistic” partnerships between Ask.com and the source sites. But whether they’re all throwing money at each other or not, the sources are well-chosen, and the overall effect is very cool.

Big thumbs up to Ask.com for their efforts on this. The big question, of course, is how good are the results? I am going to make this my primary search engine for a while, and put it through its paces.

A fix for a fix in WordPress 2.1

One thing that surprised me when I started using WordPress again is that its search function only searches on blog posts, not on static pages. I suppose if most WordPress sites are 99.9% blog posts, then it probably makes sense, but I have enough static pages on my site that I’d like to make searchable to warrant changing this.

Fortunately, someone has. Unfortunately this “Search Pages” plug-in is out of date and no longer works with current versions of WordPress. I dug in a bit and figured out why: the plug-in alters the SQL query that performs the search, but the substring it replaces in the query no longer exists! So I hunted down the place where the query occurs in the WordPress core, adjusted the plug-in as needed, and it works!

Here, then, is my hack of the Search Pages plug-in, modified to work with WordPress 2.1. (I’m not sure which other versions of WordPress it will or will not work with.)

[ search_pages.php.tar.gz ] [ search_pages.php.zip ]

Forget what I said before; we have a winner!

It’s a given that anything I post here is going to be brain-deflatingly stupid. But this one goes beyond even what I would have expected of Microsoft. Fortunately, thanks to a highly effective Google search, I was able to solve the problem in minutes.

The problem was this: For a site I’m working on, we are manipulating the 404 error feature to allow users to set up customized URLs. If the URL entered doesn’t match a real page, it gets fed into this 404 error script, which looks up the path in a database and redirects the user to their customized page. A bit of a hack, but it’s pretty slick.

As usual, I am developing the site using Firefox as my test browser. But… UH-OH! Surprise! When giving a demo of this feature today using Internet Explorer, we discovered it didn’t work! Internet Explorer was not returning the server’s 404 error page, instead using its own internal version (which we’ve all seen and most generally ignore).

Drat! What to do? Well, as it turns out (thanks to the aforementioned Google search), the problem is quite simple. To quote the unbelievable but, as I verified, 100% accurate description I found on this page:

Internet Explorer has a lightly-documented “feature” that stops it from serving any custom 404 error page that is less than 512 bytes long. Your visitors will instead be sent to IE’s own 404 page, which is generic and suggests they use an MSN search to “look for information on the Internet.” That’s one way to lose visitors! Make sure your custom 404 error page is over this limit — about 10 full lines of text and HTML should be enough.

Yep, that’s it. I did my best Bart Simpson-at-the-blackboard impersonation, filling my 404.html file with a large comment block wherein I repeated (about 130 times, for good measure) the phrase “This block exists solely to force Internet Explorer to load this page.”

Sure enough, it worked. D’oh!

Thinking a bit more about this, I at least think I understand why Microsoft chose to do this. “If the server’s default 404 error page is so short,” I imagine them musing, “then it probably doesn’t offer users much helpful information. And since our wonderful web browser is much more important to our users than the web pages themselves, let’s just butt in and do things our way. (Is there really any other way anyway?)”