spackblog

Vor einiger Zeit habe ich gefordert, dass größere und oft bei Twitter verlinkte Seiten eigene kurze URLs für ihren Content anbieten. Neulich erst habe ich mir dann Gedanken gemacht, wie man Short-URLs uns so verüberflüssigen kann. Auf diese große Lösung mag ich nicht warten, aber zumindest bei der kleinen Lösung kann ich mit gutem Beispiel voran gehen. Also habe ich gerade schnell ein kurzes Script geschrieben, das kurze URLs für mein Blog in die vollen URLs umsetzt. Zum Beispiel lautet für diesen Eintrag die kurze URL http://spackblog.de/668, was mit 23 Zeichen deutlich kürzer ist als die verdammt lange volle URL und vor allem kürzer als 30 Zeichen, ab denen Twitter ungefragt mit bit.ly verkürzt.

Ich hatte eine Weile überlegt, diese Funktionalität als Serendipity-PlugIn zu veröffentlichen, aber das habe ich aus verschiedenen Gründen nicht gemacht. Ein Grund ist, dass mich ein undankbarer Vollspacko im S9Y-Forum angesaugt und als Schnösel bezeichnet hat, als ich mein letztes PlugIn dort vorgestellt habe. Ich will da gar nicht genauer drauf eingehen, Folge ist jedenfalls, dass meine Lust auf die extra Arbeit für ein S9Y-PlugIn dadurch doch sehr gesunken ist. Ein weiterer Grund ist, dass der generierte Link irgendwo im Template und noch mal im Header positioniert werden muss, damit es Sinn macht. Das kann ein PlugIn nicht flexibel alleine regeln. Man könnte den Link allenfalls dort hinpacken, wo momentan auch die Tags sind, aber das gefällt sicher nicht jedem. An die .htaccess des Blogs, oder wenn dieses in einem Unterverzeichnis steckt auch an die .htaccess der Domain muss man auch noch ran. Spricht alles gegen ein PlugIn. Sowas gehört in meinen Augen sowieso in den S9Y-Core.

Das Script funktioniert super simpel. Alles fängt mit einer Anweisung in der .htaccess an, die alles, was nach kurz-URL aussieht an das Script weiterreicht:

RewriteEngine On
RewriteBase /
RewriteRule ^(e|a|c)?([0-9]+)/?$ s9y_shorturl.php?type=$1&id=$2 [NC,L]

Man kann schon sehen, dass das Script auch kurze URLs für Kategorien und Autoren unterstützt. Der spannende Teil im Script selber ist die Datenbankabfrage, die die kurze URL aus der Datenbank ausliest:

// open a database-connection
$dbh = new PDO('mysql:host=' . $db_server . ';dbname=' . $db_database, $db_user, $db_pass);

// prepare the statement
$stmt = $dbh->prepare('SELECT permalink
  FROM s9y_permalinks
  WHERE type = :type
    AND entry_id = :entry_id
  LIMIT 1');

// execute the statement
$stmt->execute(array(':type' => $type, ':entry_id' => $entry_id));
  
// read the returned urlpart
$urlpart = $stmt->fetchColumn();

// close the database-connection
$dbh = null;

// redirect the user with a 301 status code (moved permanently)
header('Location: ' $blog_base_url . $urlpart, true, 301);
exit;

Der Rest vom Script besteht aus Fehlerbehandlung und Variablen-Vorbereitung, die ich hier mal weg lasse. Wer den ganzen Code haben will, kann sich gerne bei mir melden. Damit ist der erste Teil schon fertig, der die kurzen URLs auflöst. Für die kurzen URLs werden einfach die von Serendipity vergebenen IDs genutzt, der Parameter type kann übrigens 'entry', 'category' oder 'author' sein. S9Y führt eine eigene Tabelle für die Zuordnung von IDs und URLs, die man nur abfragen muss.

Der zweite Teil ist leider Handarbeit im Template. Man muss dazu an der Stelle, wo der Link auftauchen soll folgenden Code in der entries.tpl platzieren: <a href="http://SHORTURL_DOMAIN/{$entry.id}">http://SHORTURL_DOMAIN/{$entry.id}</a>. SHORTURL_DOMAIN muss natürlich durch die jeweilige URL ersetzt werden, in meinem Fall ist das tatsächlich eine andere Domain als die, auf der das Blog läuft. Ich habe zusätzlich noch in der index.tpl im Headerbereich im {if $entry.id} Block einen Short-URl Autodiscovery Link eingefügt, wie er hier beschrieben ist.

Das ganze arbeitet extrem simpel und macht genau das, was es soll: Wenn jemand meinen Blog bei Twitter und Co. verlinken will, kann jetzt meine 23 stellige Kurz-URL hernehmen und sich so den Scheiß mit den verkürzten URLs sparen, bei denen man nicht weiß, wohin sie eigentlich linken. Alle Seiten sollten solche eigenen Kurz-URLs haben, dann wäre das mit Twitter nur noch halb so schlimm.

Ich habe heute den ganzen Tag Vista plus etliche Programme auf einem iMac 24" installiert. Entgegen landläufiger Meinungen hatte ich nur bei einem Programm Probleme, die auf Vista zurückzuführen waren. Oder anders herum: Vista entlarvt die miese Programmierung dieses Programms derart schonungslos, dass sein Entwickler (der inzwischen aufgegeben hat) zum Start von Vista einen Jammerbrief über dieses böse Vista an seine Kunden mit Wartungsauftrag geschickt hat. Dieses Gejammer ist unfassbar peinlich, weil das Programm seit etlichen Jahren schon nicht sauber funktioniert. Unter anderem arbeitet es schon immer ohne sinnvollen Grund nur mit Administratorrechten. Ich kenne den genauen Grund zwar nicht, aber das ist auch völlig egal, denn offensichtlich bestünde dieses Problem bei halbwegs sauberer Programmierung nicht. Aber das ist nicht der einzige Fehler. Das Programm ist ein Musterbeispiel, wie man etwas nicht machen sollte; ergonomisch und programmiertechnisch einfach nur katastrophal.

Ich hätte glatt Lust, mal einen Screencast zu machen, wo ich dieses Stück Software-Dreck en Detail zeige. Was mein Kunde mir über die Jahre schon an Geld bezahlt hat, damit ich die Probleme so gut es geht behebe, ist wirklich immens. Übrigens habe ich auch für die mehrfache Neuinstallation eines HP-Druckertreibers schon so viel Geld in Rechnung gestellt, dass man gleich zwei der problemlosen Brother Geräte hätte kaufen können, mit dem wir diesen HP OfficeJet dann endlich ersetzt haben. Was soll ich sagen: Inzwischen gibt es dort neben dem uralten HP LaserJet 4L nur noch drei Brother-Geräte und keins davon hat jemals für unnötigen Supportaufwand gesorgt. Ein Traum, kann ich nur sagen: Drucker ans Netz, CD rein, ein paar Minuten lang den Installationsassistent laufen lassen (der fragt, ob man nur Drucker- und Scannertreiber oder die ganze Software haben will), fertig. Sogar der "Scannen an" Knopf am Gerät funktioniert sofort wie er soll und im Gegensatz zur Höllen HP-Software sogar dauerhaft. Danach kann man die Geräte schlicht vergessen, so wie es sein soll. Den kleinen Monochrom-Laserdrucker habe ich tatsächlich seit seiner Installation vor einigen Jahren nur zum woanders hinstellen mal anfassen müssen. Ich frag schon gelegentlich nach, ob der überhaupt noch benutzt wird, weil ich nichts davon höre. Ja wird er, täglich.

Ich liege gerade im Bett und wollte schnell noch etwas mit dem Handy im Netz nachschlagen. Aber Pustekuchen! Die Seite mit der gesuchten Information nervt mit Layer-Ads (in dem Fall 1&1). soweit kein Problem, aber das Drecksteil kommt via JavaScript beim Scrollen einfach mit. Auch das wäre noch kein Hindernis (der Webstandards-Befütworter spricht hier von Barriere), wenn damit auf kleinen Bildschirmen der Schließen-Knopf nicht niemals sichtbar werden würde. So eine Scheiße, echt mal!

Das ist allemal noch nerviger als die Layer-Ads, deren Schließen-Knopf noch mal eben ein Popup öffnet, statt die Werbung zu schließen. Oder die Layer-Ads, deren Schließen-Knopf erst nach einigen Sekunden überhaupt mal erscheint. Eigentlich ist jeder Layer-Ad nicht nur ein bisschen störend, sondern ein guter Grund, andere Seiten zu nutzen. Ich hasse die Dinger.

Vor einigen Wochen habe ich meine robots.txt angepasst und Suchmaschinen verboten, meine Tagübersichten zu indizieren. Warum? Viele Besucher kamen mit Suchwort-Kombinationen auf meine Seite, die in diesem Kontext in keinem meiner Artikel vorkommen. Teilweise waren da ganz abgespacte Sachen bei, wo mir nicht mal zu den einzelnen Begriffen ein Beitrag eingefallen ist, den ich mal geschrieben haben soll. Der Grund für dieses von allen Seiten ungewollte Ergebnis – immerhin hat niemand etwas von solchen Treffern, ich binde ja keine Werbung ein – waren stets meine Tags-Übersichts-Seiten, die verschiedene Beiträge mit gleichem Tag hintereinander ausgeben, auch wenn sie sonst inhaltlich nichts miteinander zu tun haben. Also habe ich diese Seiten kurzerhand für Suchmaschinen verboten und bin damit bei vielen Suchbegiffen von der ersten Google-Seite verschwunden. Bin ich traurig darum? Eigentlich nicht, weil ich das Gefühl habe, die Welt ein kleines Stück besser gemacht zu haben. Meinen Besucherzahlen hat das nur bedingt geschadet. Ich habe zwar etwas weniger uniqe visitors, aber dafür deutlich mehr page impressions. Eine Folge qualitativerer Suchtreffer? Vorher hatte ich nämlich eine große Zahl von enttäuschten Besuchern, die bei mir nichts zum Suchtreffer passendes gefunden und sich gleich wieder verpisst haben. Jetzt, kann ich mir zumindest vorstellen, regen quantitativ weniger, aber tendenziell qualitativ hochwertigere Treffer mehr Leute zum stöbern in meinen anderen Artikeln an. Ob das wirklich so ist, werde ich allerdings nicht erfahren, dafür kann ich mir das gemütlich einbilden.

Wegen dieser guten Erfahrungen habe ich ab sofort auch die Kategorienseiten verboten. Möglicherweise werde ich das ganze aber umstellen: Momentan verbiete ich Suchmaschinen ja das Betreten der betreffenden Seiten. Besser wäre da natürlich die Meta-Angabe <meta name="robots" content="noindex,follow">, aber die muss ich erst bei Gelegenheit in die passenden Templates hacken. Damit würden Suchmaschinen die Seiten betreten und den Links folgen, aber eben nur die Inhalte nicht in den Index aufnehmen. Die optimale Lösung eigentlich. Wenn ich mal ein eigenes Template baue oder gar die Blogsoftware wechsel, mach ich das. Vielleicht auch vorher mal.

P.S. es ist bei diesem Blog nicht im geringsten meine Absicht, nur möglichst viele PIs zu generieren. Für Websites mit diesem Ziel ist die hier beschriebene Maßnahme natürlich fast immer pures SEO-Gift. Möglicherweise steigert es aber das Google-Karma und kommt einem irgendwann zu Gute, wer weiß.

Lightboxen, also diese Dinger, die Bilder und anderes schön anzeigen, ohne ein echtes Popup zu sein, sind ja eine feine Sache. Einige Lightboxen erkennen nämlich die Bildschirmauflösung des Benutzers und skalieren die Bilder entsprechend, so dass sie so breit wie möglich sind, aber noch in den Browser passen. Eine kluge Idee an sich, wenn sie nicht von Zeit zu Zeit etwas hirnlos implementiert wäre. Ich habe eine Auflösung von 1920x1200 auf meinem 24"-Bildschirm. Diese hohe Auflösung nutze ich dazu, neben normalbreiten Fenstern noch Chatfenster, Audioplayer und solchen Kram sichtbar zu halten. Vor allem aber sehen die meisten Websites in so breiten Browsern völlig dämlich aus, weil sie nicht mal die Hälfte der Bildschirmbreite füllen. Jetzt kommt das Problem mit den kurzsichtig programmierten Lightboxen ins Spiel: Besucht mal diese moderne Seite eines Wohnwagenherstellers (via Alex) und öffnet eines der Bilder. Surft ihr mit maximiertem Browserfenster ist alles OK, tut ihr das nicht, ist das Bild breiter als das Browserfenster und ist nicht mehr sinnvoll zu erkennen.

Das dort eingesetzte Lightbox-Script ist Lightview und das macht den kapitalen Fehler, hier die Bildschirmausflösung abzufragen und nicht die Größe des Viewports (der im Browser sichtbare Bereich). Update: Das Problem tritt nur in Opera auf. Warum? Denken die Entwickler, jeder surft immer maximiert? Was ist mit Leuten, die einen erweiterten Desktop haben (mehrere Bildschirme)? Und was ist mit Leuten, die ihre Websites gezoomt anschauen? Und wie dämlich ist der gesamte Ansatz, wenn nur die Breite beachtet wird und nicht die Höhe? Die Bilder auf der verlinkten Seite haben ein 4:3-Format, so dass es auf einem Widescreen-Monitor mit hoher Auflösung zwangsläufig oben und unten abgeschnitten wird. Scrollen ist aber nicht, weil das Bild leider mitscrollt. Nett gemeint, aber völlig unzureichend umgesetzt.

Lightview ist aber nicht das einzige Script, das diesen Fehler macht, der gleiche Effekt kommt mir immer wieder unter. Meistens fällt das nicht auf, weil die Bilder nicht größer als mein Viewport sind. Aber wenn das der Fall ist zeigt sich sehr imposant, dass der Entwickler des Scripts nicht zu ende gedacht hat und so die Usability am Ende sinkt statt steigt. Das Bild wird man übrigens mit einem beherzten Druck auf Esc wieder los, oder indem man die Seite weit genug heraus zoomt.

Nachtrag 16.09.2008: Wie ich gerade feststellen musste, tritt das Problem bei Lightview nur in Opera (getestet in 9.52) auf, im Firefox orientiert sich die Bildgröße in Höhe und Breite korrekt am Viewport. Nach etwas Recherche weiß ich jetzt auch, wieso: Die von Lightview eingesetzte JavaScript-Bibliothek Prototype hat ein Problem mit der von Opera seit Version 9.5 veränderten Handabung des Viewports. Klingt kompliziert? Ist es auch. Also kurz gesagt: Lightview arbeitet korrekt, nur gibt es eine Inkompatibilität der benutzen Prototype-Version mit Opera 9.5. Das Ergebnis ist das gleiche: Usability-mäßig gut gemeint, am Ende steht aber ein dickes Minus. Ein generelles Problem mit solchen JavaScript-Spielereien, mit denen man stets vorsichtig umgehen sollte.