(Wow, this turned out longer than I anticipated. tl;dr version: This module would create ancillary short paths for your nodes which will make life easier when linking to them with Twitter and the like, without the hassle of external services.)
The rise of Twitter and other such character-limited methods of communication has caused a rise in the use of URL shortener services such as is.gd, bit.ly, and so on. Site editors who use Drupal may feel compelled to use such services to link to their content when posting about it. However, there are a few flaws with using an external service to shorten URLs like this.
- If the service goes down temporarily or permanently, the links won't work. Since many URL shortening services are heavily used but don't seem to have any realistic income stream, there's a good possibility that at least some of them are going to go down before this fad is over. This nearly came to pass when the service tr.im announced its imminent death (only to rescind the announcement days later). Had this happened, all links to your content which used tr.im would simply not work.
- Server logs will count the "hit" as coming from the service's web site instead of where the link was actually posted to (eg, it will appear to come from is.gd instead of twitter.com), skewing statistics.
- Similar to #2, links to your site's content going through URL shortening services may not provide you with proper backlink "juice" in the eyes of search engines when they're tallying up your score.
- If you want a short URL created for content on your site, you either
- have to visit the shortening site or use a bookmarklet and create it manually, or
- chat with the service via an API, which may change or experience downtime.
What this is all getting around to is, wouldn't it would be better if you could create and host your own short URLs? You have a web server, after all. And maybe you don't have a sweet five- or six-character domain name available to you, but just getting a shorter path for your nodes might be enough.
So you have the Path module, right? Why not go at it? Maybe you don't want the short path to be canonical - you want the canonical URL to your post to be http://example.com/foo_bar_baz_qux but you'd like to use the short URL http://example.com/foo. So on the node creation screen, you give it a path of "foo_bar_baz_qux", then you go into your admin section and create another path of "foo" for your node. Okay, so you just did the same thing manually twice (unless you're using Pathauto or such), and (AFAIK) Drupal really has no way of knowing which path you really wanted to be canonical. What a pain.
So I propose a module I'm tentatively calling Shortening (as in Crisco). When a node is created, it will let you create a second short path for it similar to how the Path module lets you do now, and will also take care that any queries for that short path are redirected to the longer, canonical path for the node as created by the Path module or Pathauto (or just the node/X path if that's not available). Or, on the node editing screen, you can leave the short path creation field blank, and Shortening will create a short path automatically for you. How does that happen?
An RFC I can't be bothered to look up right now states that the unreserved characters for URLs are the ten digits, A through Z both uppercase and lowercase, and the tilde, hyphen, underscore and period characters. That's sixty-six characters (or sixty-two if we omit the punctuation characters, which should be an option). By counting sequentially for each shortened URL created, we can convert the index for the short URL we're creating to base 66, then specifying it using those characters, we can theoretically create short paths for 291,918 pages by using short paths of only three characters or less:
66^1 + 66^2 + 66^3
66 + 4356 + 287496 = 291918I say "theoretically" because we'll obviously want to check that we're not colliding with pre-existing paths before we create one, but it gives you an idea of what's possible. If we just stick to the sixty-two alphanumeric possibilities, we can do 242,234 paths with three characters. Either way, I think it's enough to last the average blogger a while.
Once we've auto-created the path, we can add a link to the bottom of nodes which says something like "Short URL" which links to the shortened URL, so both the site editor and any readers who want to "tweet" the URL have easy access to a short URL for it. If the admin has registered a shorter domain name for the site which they want to use for shortened URLs - for example, example.com is the canonical domain name, but xmpl.xy is an alias - that shorter domain can be specified in the Shortening admin page to be used for these links for even more character savings.
Some potential flaws:
- Automatically created paths may be unintentionally inappropriate. I'm not really sure how to handle this. Okay, I create a blacklist to stop a path named "arse" from being created, but what about "Arse" or "ar5e" or 4r53" or all the other various permutations? And that's only accounting for one dialect of English…
- What if Shortening creates a path of "foo", and then the admin comes along and installs a module which tries to use "foo" for itself in its hook_menu()? I think (too lazy to look it up right now) that paths defined in the menu system take precedence over other paths, right? So all of a sudden, the "foo" path will start pointing to whatever the module wants to do with it (possibly showing a "permission denied" page to most users if it's something adminny). We can avoid this by "namespacing" these paths by prefixing them with, for example, "s/" (so "s/foo" instead of "foo"), but then we've just added at least two characters to the minimum possible character count.
- I don't really use Twitter or similar services all that much, and I've also kind of fallen out of the habit of blogging recently. So though I think this module would be fun to write, I myself probably wouldn't use it much - and personally, I'm most fond of the modules I've written which I actually use often (namely Pathologic).
- Doing this properly might require more experience with multi-lingual sites than I really have, since the URL alias table stores language codes.
There already exists a Short URL module for Drupal which shortens URLs. The main differences between that one and what I'm proposing are that Shortening would work only for paths on the Drupal installation on which it is installed, whereas Short URL lets you create short URLs for anywhere on the interwebs similar to full URL shortener sites; and Shortening would create short URLs for new nodes as they are created (possibly with a bulk create feature for pre-existing nodes). Also, I would try to accomplish this using Drupal's standard url_alias table and mechanisms instead of using my own table and a hook_init() hook as Short URL does.
Anticipating your thoughts.

Comments
kind of already done
I think most of what you're talking about is integration for path redirect into the node edit screen. Note, however, that your assumption about the menu system is wrong - aliases and redirects take precendent over menu paths :/
Also, I wrote about this a while ago at http://growvs.com/node/243 (note how relatively short that URL is...). Someone in the comments points out that you can use .htaccess rules to forward from n/NID to node/NID which makes it even shorter.
--
http://growingventuresolutions.com | http://drupaldashboard.com | http://drupal.org/books
knaddison blog | Morris Animal Foundation
Note, however, that your
Really? That's surprising. Seems like there's lots of potential for headaches there…
Come to think of it, I don't know if it's possible with .htaccess alone (though Lighty ought to be able to do it with its sweet config file syntax), but I bet you could make it so all paths which match
/^\d+$/(consist entirely of digits) are redirected tonode/$1for even more character savings. You're still working in base 10… but I bet that would be enough for some people, and there's pretty much no chance of a path collision. Interesting.Modules are easier for most people to handle than config file tomfoolery, though…
The Boise Drupal Guy!
sure - simple module as well
Definitely, people like modules more than .htaccess rules for a variety of reasons. Building that as a module should be fairly simple as well.
--
http://growingventuresolutions.com | http://drupaldashboard.com | http://drupal.org/books
knaddison blog | Morris Animal Foundation
Hmm, this turned out to be
Hmm, this turned out to be easier to do in .htaccess than I thought - just add:
RewriteRule ^(\d+)$ node/$1 [L,R=301]…to the
<IfModule mod_rewrite.c>section of .htaccess.For Lighty, assuming you're using my Lua script to do clean URLs, you can just add something like this before the clean URL part:
if (lighty.env['request.uri']:match('^/%d+$') ~= nil) thenlighty.header['Location'] = lighty.env['uri.scheme'] .. '://' .. lighty.env['uri.authority'] .. '/node' .. lighty.env['request.orig-uri']
return 301
end
If you're not using the Lua script, it ought to still be possible using Lighty's standard rewrite module, but if you're going to use a Lua script anyway, you might as well do this in Lua as well for more flexibility and to avoid enabling another module when not necessary.
They'll need a bit of tweaking if you want them to redirect requests from xmpl.xy to example.com, but either way it's clear that something like this is possible without too much effort - and all before we even get close to bootstrapping Drupal! Schweet!
Alas, it can only redirect to node/X paths… if someone wants to use custom paths, I think the module approach may be the only sane way.
The Boise Drupal Guy!