Right now I use kl.am, a free service from Raven SEO Tools, for all my URL shortening needs. It's awesome and 99.5% perfect. But I've really wanted to host my own for three reasons:

1. I want bulk uploads with custom short URLs so I can have predictable, product SKU short URLs.
2. I want to be able to repoint a short URL if it's old URL changes or 404s.
3. I don't want to compete with other users for custom URLs.

Unfortunately, rolling my own will mean I miss out on all the amazing coolness of kl.am. Mine wouldn't be as slick or easy to use. However, Lessn is slick and easy to use. But it doesn't do custom URLs and it doesn't track how often people visit a short URL. So I added those features.

Tracking clicks

In the file /-/db.php, add this statement to create a second table:

mysql_query('CREATE TABLE IF NOT EXISTS `'.DB_PREFIX.'stats` ( '.
'`id` int(11) unsigned NOT NULL auto_increment, '.
'`url_id` int(11) unsigned NOT NULL, '.
'`ts` datetime NOT NULL, '.
'`ua` text character set utf8 collate utf8_unicode_ci NOT NULL, '.
'`ref` text character set utf8 collate utf8_unicode_ci NOT NULL, '.
'`ip` int(4) unsigned NOT NULL, '.
'PRIMARY KEY (`id`), '.
'KEY `url_id` (`url_id`) '.
') ENGINE=MyISAM DEFAULT CHARSET=utf8;');

Then, in the /index.php file, add this line right after the header('Location:'); line:

mysql_query("INSERT INTO `".DB_PREFIX."stats` SET `url_id`='".$row['id']."', `ts`='".date("Y-m-d H:i:s")."', `ua`='".mysql_real_escape_string($_SERVER['HTTP_USER_AGENT'])."', `ref`='".mysql_real_escape_string($_SERVER['HTTP_REFERER'])."', `ip`='".sprintf("%u", ip2long($_SERVER['REMOTE_ADDR']))."' ");

To test, go visit one of your short URLs, and then go check the stats table. You should see a new entry in the table.

Now, how you choose to display the data from this table is up to you. :)

• Tells you the "real" URL of any shortened URL (regardless of what service provides it).
• Gives technical types the redirect codes involved in all the redirects for any particular link.
• Discovers both canonical and shorturl data for the final expanded URL.
• Offers a fast API for quickly finding the expanded URL (and a less fast API for getting the same detailed data that is available from the web interface).

Heard enough? Go check it out:

The expandUrl™ site was built to fix a specific problem I recently discovered on one of my other sites, so you can be confident that expandUrl™ has been tested on a sample set of a couple thousand real-life URLs. However, the total number of hours I've spent building expandUrl™ can still be counted on one hand so you are bound to discover some edge cases which I haven't encountered.

I appreciate all bug reports to be posted below. Security concerns should also be posted here, but I will pre-moderate those until they are fixed. (Not to hide them, but to give me the opportunity to fix them before they are exploited.)

Eating my own dog food

I run a site which aggregates RSS feeds from a few dozen different sources. One of the included sites accidentally let their domain name expire and had to move to a new domain name. This particular site also hosted their RSS feed with Feedburner.

When the site changed domain all the URLs were broken. You may be thinking, "Well, duh. There's nothing you can do to fix that." In this scenario however, the original site owner simply changed domain names. All of the old URLs would map perfectly to the new domain name:

Old: http://example.com/blog/2007/04/post.html

New: http://example.org/blog/2007/04/post.html

If I had stored the actual URLs, I could simply do a REPLACE in the database. However, since I stored the Feedburner URLs in my database, it would be impossible for me to do so. That's because Feedburner obfuscates the actual URL data:

Actual URL: http://example.com/blog/2007/04/post.html

Feedburner URL: http://feeds.feedburner.com/~r/exampleblog/epRL/~3/745213668/post.html

I quickly built expandUrl so that I could resolve any URL (be it a short url, tracking script, or feed redirect) to the actual URL. I then ran an automated script to determine the relative link on the old domain, replaced the old domain with the new domain, and updated the database accordingly. An hour or so later, and all those posts are now fixed.

I ran this script against the entire database of URLs to go ahead and resolve any other redirects found. I made an interesting discovery. Many of the RSS feed services will generate multiple redirect URLs for the same blog post permalink. My database had a UNIQUE index on the URL field as a means of preventing the same post from showing up multiple times, but it turned out the feed services were inadvertently circumventing that "protection."

In the end, integrating expandUrl has cleaned over 300 duplicate URLs from my database and helped improve the future maintainability of the link data the site has collected.

If you find expandUrl™ helpful, I'd love to hear about it! :)

Four methods tested with the sequence used to successfully guess the number "1."

Random Starts with a random number and draws a random guess from the range implied by the results of each round.
Guessing: 65, 41, 32, 18, 14, 9, 3, 1

Equal Division Starts with 50 and each time guesses the median value from the range implied by the results of each round.
Guessing: 50, 25, 13, 7, 4, 2, 1

Fibonacci Division Starts with 50 and each time guesses the golden ratio value from the range implied by the results of each round. In other words, divides by 1.618033989 instead of by 2. So either 32 or 81 will be it's second round guess.
Guessing: 50, 32, 21, 14, 10, 7, 5, 4, 3, 2, 1

Fibonacci Offset Division Starts with 50 and each time guesses the golden ratio value based on whether they were too high or too low. So a guess of 50 that was "Too Low" would then choose 81. A guess of 50 that was "Too High" would choose 19.
Guessing: 50, 19, 7, 3, 1

I expected that Equal Division would be the winner but wanted to play around with some other options just to see. Here's the distribution of how many tries it took to guess the correct number over 500 iterations using each of the different methods.

The condition for a win is guessing in fewer tries than the base-2 logarithm of the range (in this case the range is 100 and the base-2 logarithm of 100 is 6).

When drawing a text string that has multiple text borders like, for example, the family reunion t-shirt design here, you have unique issues building the multiple layers of borders.

Depending on how you draw multiple borders you can get many different effects:

What's the difference between these different approaches?

Answers

In option C, each letter is individually drawn starting at the largest border then working inwards to the fill. When drawing arced text, each letter is drawn in a different position so you have to draw each letter separately.

In option B, each border is drawn with a transparent fill then the separate layers are flattened.

In option A, the entire string is drawn starting at the largest border then working inwards to the fill.

If you read most work on "How To Set Up a 301 Redirect" it involves delving into Apache .htaccess files or waving a dead rat over a .NET server while clucking like a chicken. In those odd shared hosting cases where you have no access to modify .htaccess files you may be further screwed into learning about meta redirects and determing just how Yahoo! is going to interpret a 2 second delay versus a 3 second delay.

Here's a method for handling redirects in a way that is simple to manage, requires only PHP and the ability to define a custom error page, and allows you to prepare your redirects before you move the page with a seamless redirect once you have. Even with the ability to control every aspect of my Apache server, I still prefer this method.

How it works

When you move a page to a new location the most important thing is to ensure a user or search engine spider does not receive a "File Not Found" error (hereafter referred to as a "404"). It's important to understand how a request for a non-existant page is handled by the server. Here's a diagram I put together:

If you didn't realize already, it's a simplified diagram of the process. Where in this process do you intercede to prevent a 404 error? Because everything a server must do takes up processing power, it is logical to conserve server resources and intercede as soon as possible. For example, if you could go out and fix all your visitor's bookmarks and search engine listings to point to the new page, you should. Then, no one even would have to worry about 404 pages or dealing with redirects! :)

So, logically, to conserve server resources, the next step in which we can intercede is the checking of the .htaccess file. (For simplicities sake, I won't discuss editing the httpd.conf to place the redirects in the VirtualHost section.) For example, we could put something like this in our .htaccess file:

RedirectMatch 301 /olddirectory/([^.]+)\.html$ http://www.example.com/newdirectory/$1.html

And, that code would work, just as expected! But, once you and your boss and clients learn about the wonder of the 301 redirect, some of the arguments against changing page locations willy nilly will go away and you'll find yourself with .htaccess directives that are dozens of lines long. Which reminds us that Apache parses all the directives it finds for every page request it receives in every directory in which that page may be found. Suddenly our performance savings by using Apache to handle redirects are being whittled away by an excess number of directives.

The solution lies downstream

Scroll back up and bit and take a look at that diagram. When a page isn't found, the web server will serve up an error page. It will even serve a custom error page if configured to do so. How do you configure it do so? It's easy and I'm going to skip ahead a bit and reveal that our custom error page will be a PHP script so I can provide all the .htaccess code you'll need in this one bit of code:

ErrorDocument 404 /404.php

That line added to the main .htaccess file for your entire script is the only and last time you'll need to edit .htaccess to deal with your 301 redirects. All the work occurs in that PHP script.

PHP headers overrule Apache headers

Even though Apache will normally serve a 404 header along with your custom 404 page, you can easily overrule that with a PHP header. So, why note send a 301 header? Once we make this cognitive leap, it's dead simple to put all your redirect code into your custom 404 page and check the request against your URL patterns.

Using a database structure like so:

CREATE TABLE `redirects` ( `primary` bigint(20) unsigned NOT NULL auto_increment, `old_uri` varchar(254) NOT NULL default '', `new_uri` varchar(254) default NULL, `action_type` mediumint(9) default NULL, `domain_match` varchar(254) NOT NULL default '', PRIMARY KEY (`primary`), KEY `old_uri` (`old_uri`,`new_uri`,`action_type`,`domain_match`), FULLTEXT KEY `old_uri_2` (`old_uri`) ) ENGINE=MyISAM;

You can use the following PHP code at the beginning of your custom 404 page:

<?php // include your own DB connection info here $link = mysql_connect('localhost', 'mysql_user', 'mysql_password'); // build a complete URL from server variables $complete_request = 'http'.(($_SERVER['HTTPS']=='on')?'s':'').'://'.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']; // Parse out the URI $parsed_request = parse_url($complete_request); // Especially badly formed URLs will throw a false from the parse_url function, we only continue if that is not the case if($parsed_request !== false){ // Check the DB for a specific entry $query = sprintf("SELECT * FROM `redirects` WHERE `domain_match` LIKE '%s' AND `old_uri` LIKE '%s' LIMIT 1", ''.mysql_real_escape_string($_SERVER['SERVER_NAME']).'', ''.mysql_real_escape_string($parsed_request['path']).'%' ); //print($query); // for debugging $result = mysql_query($query); while ($row = mysql_fetch_array($result, MYSQL_ASSOC)) { $redirects_found[] = $row; } // print_r($redirects_found); // for debugging // If there is a match, redirect the user if(count($redirects_found)==1){ // send the right type of redirect if($redirects_found[0]['action_type'] == '302') { header('HTTP/1.1 302 Moved Temporarily'); header('Location: http'.$s.'://'.$_SERVER['HTTP_HOST'].$redirects_found[0]['new_uri'].''); $headers_sent = true; } else { header('HTTP/1.1 301 Moved Permanently'); header('Location: http'.$s.'://'.$_SERVER['HTTP_HOST'].$redirects_found[0]['new_uri'].''); $headers_sent = true; } // You can add additional behaviors for other header codes here } // if(count($redirects_found)==1){ } // if($parsed_request !== false){ // Exit if we have sent headers if ($headers_sent) { die; } // Otherwise, include friendly 404 HTML below :) ?>

With this code in place, you can add entries to the redirects table ahead of removing/moving pages. As soon as your new pages are in place, just rename or delete the old files and all incoming requests (from both users and spiders) will automagically be redirected to the new location.

/blog/?p=123

The "quick fix" for this is a few lines of code added to the top of the "single.php" file in your wordpress template:

<?php if(preg_match("/p=[0-9]+/", $_SERVER['QUERY_STRING'])){ header("HTTP/1.1 301 Moved Permanently"); header("Location: ".get_permalink()); } ?>

I will be writing up a plugin to add this functionality in a more Wordpress friendly way, but for now a quick code change will work. :)