Vor gut einem Monat hat Google angekündigt, seinen hauseigenen URL-Shortener goo.gl einzustellen. Schade, denn ich habe den Dienst sehr gerne genutzt, um z.B. Artikel auf Twitter zu verteilen. URL-Shortener ermöglichen es, aus einer langen URL eine kurze zu erstellen, welche dann auf die ursprüngliche weiterleitet.
Darin steckt auch einer der Gründe und vormals Notwendigkeiten solcher Dienste, denn bevor Twitter eigene Maßnahmen zur Verbesserung von Links in Tweets ergriff (z.B. Einführung von t.co), waren die Services der einzige Weg, um halbwegs einen Link in den 140 Zeichen unterzubringen. Es wurde dafür in Kauf genommen, dass die entstandenen URLs alles andere als lesbar waren - sie sollten einfach nur funktionieren. 26 Groß- und Kleinbuchstaben und die zehn Ziffern bilden schon bei einer Zeichenlänge von konstant 5 Zeichen über 900 Millionen Möglichkeiten. ((26 + 26 + 10)5) Bitly ging als einer der bekanntesten Dienste hervor.
Auch nach der Anpassung seitens Twitter blieben die URLs trotz einiger Sicherheitsbedenken, denn man weiß auf den ersten Blick nicht, wohin man geleitet wird, weiter beliebt. Unternehmen wie Google nutzen für Firmeninhalte eigene URL-Shortener (z.B. g.co), um kürzere URLs zu erstellen - mit dem Unterschied, dass diese URLs klanghaft (Stichwort Vanity URLs) sind, man sich diese auch merken kann. So führt g.co/recover zum Wiederherstellungsprozess eines Google-Kontos.
Vorteil einer solchen Variante ist es, dass kürzere und merkfähigere URLs erstellt werden können, ohne die URL-Struktur einer Seite in ihrer Beständigkeit einzuschränken, denn Cool URIs don't change. (zumindest die Canonical-URLs)
Warum also nicht einen Linkshortener auch auf der eigenen Seite einsetzen? Ziel sollte es sein, die Funktionalität für die eigenen Seite bereitzustellen und auch die komplette Kontrolle über den Shortener-Service zu behalten.
Und es gab für mein Einsatzszenario noch eine Besonderheit: das zugrunde liegende System bzw. Script sollte so klein und einfach wie möglich sein. One file. KISS eben. Deswegen fiel leider Yourls raus, weil es aus meiner Sicht für diesen Zweck etwas zu anspruchsvoll ist. Wer eine leistungsfähigere Lösung braucht, ist mit Yourls gut bedient, ich will aber z.B. nur v-gar.de/-mysql-1698 zu meinem MySQL-Artikel weiterleiten.
So entstand Atajlio. Die Installation ist denkbar einfach: index.php herunterladen, u.U. umbenennen, auf den Webspace packen, sicherstellen, dass PHP sowie der PHP PDO-SQLite-Support laufen (ist i.d.R. der Fall) und das Script in dem Verzeichnis schreiben kann und die File über den Webserver aufrufen. Nach erfolgreicher Initialisierung (d.h. ./atajlio.db wird angelegt, Pfad lässt sich aber vorher umkonfigurieren) wird eine Admin-URL einmalig angezeigt. Diese merken bzw. sichern, sie ist der Zugang für die Verwaltungskonsole. Jetzt ein URL-Rewriting konfigurieren und z.B. example.com/-XXX auf example.com/atajlio/?l=XXX mappen.
Abschließend example.com/-adminurl entsprechend aufrufen, UNBEDINGT den Zugriff auf die DB-File (in .htaccess bzw. Webserver-Configfile) sperren - fertig.
Der Source Code liegt bei GitHub und steht unter der MIT-Lizenz.
Das Projekt soll weiterentwickelt sowie dokumentiert werden und ich überlege momentan, doch noch einige Einstellungsmöglichkeiten für z.B. MySQL einzubauen, bin aber mit dem aktuellen Ergebnis in der Funktionsweise schon ganz zufrieden.
Selbstverständlich freue ich mich über jedes Feedback!
