Up until today, I’d been redirecting 404 errors on my new site to an archive version of the old site. I’m confident enough at this point that all of my previous content (that I’m concerned with) is properly redirecting and search engines are all updated with the new permalink structure. So I turned that off.
Just in case, though, I thought I’d smarten up the 404 to offer possible options based on the URL that a person comes in on. C’mon, it’s Sunday.
- dissects the request url path and sanitizes the string (removes dashes, slashes, percents and numbers)
- runs a fuzzy string match1 with the url terms against the contents of search.json
- sorts the list by match score, trims it to 15 and adds it to the page
This means that bad or truncated urls can still lead a person to the content that they were looking for. It also, just for fun, means that you can easily search the site using keywords with a simple url, such as brettterpstra.com/applescript or brettterpstra.com/jekyll.
While I’m nerd-boasting about stuff, check out my blink(1) telling me that my Jekyll site is generating.
Because I use a system that schedules builds for future dates, it’s cool to know when the process starts and is running in the background. It took some coding to make it start and stop blinking continuously, but I now have a
notify function in my Rakefile that takes RGB color codes and a start/stop argument to blink in any color for different tasks.
If it notices that I’m at my machine when it completes a task, it takes over my audio momentarily, unmutes it as needed and announces the status using the Zarvox voice (try it:
say -v Zarvox "boom, generated" or
say -v Zarvox "deee ploid"). If not, it sends me a push notification on my phone. I gotta stop with this stuff.
It currently only finds characters in the order they are in the search (with whatever in-between each one), but I’d eventually like to account for transposed words. That might be a little heavy for a 404 page, though. ↩