Entwicklung - Sonstiges - Der gute alte Zurück-Link - Ein Resumée und Alternativen

Der "gute" alte Zurück-Link - Ein Resumée und Alternativen

Wer kennt ihn nicht, den "Zurück"-Link?
Viele benutzen ihn, manche verzichten darauf - notwendig ist er nicht, aber sinnvoll kann er sicherlich sein. Ich möchte mir die Freiheit nehmen, ein wenig über den Stand der Dinge zu reflektieren.


Der steinzeitliche Standard

<a href="javascript:history.back()"> Zurück </a>

Tausend mal woanders gesehen, dran gewöhnt, quasi mit der Muttermilch aufgesogen. Aber gibt es deswegen keinen Grund, es einfach mal in Frage zu stellen? Ich denke nicht - und ich hoffe, ich werde den geneigten Leser von meinen Ansichten überzeugen können.

Hier wird JavaScript benutzt, um eine denkbar simple Funktionalität zu implementieren. Die JavaScript-Diskussion ist alt, und ich möchte sie hier auch nicht neu aufrollen, aber Tatsache ist, dass euer Zurück-Link (welch Errungenschaft der Technik) so bei deaktiviertem JavaScript nicht mehr funktioniert - Zudem tut der Link dummerweise garnichts, falls in der Browser-History keine Vorgängerseite existiert. Und das ist nicht nur schade, sondern auch absolut unnötig (so wie die Benutzung von JavaScript im Allgemeinen, einzige legitime Ausnahme ist in meinen Augen das Einbinden externer Statistik-Tools). Kurioserweise entspricht die Zukunftsträchtigkeit des hier aufgerufenen JavaScript-Objektes / der Methode auch noch exakt der Namensgebung.

Denn schliesslich gibt es Alternativen, die absolut ausfallsicher sind und nicht clientseitig torpediert werden können. Dafür notwendig ist nicht mehr und nicht weniger als ein Webhoster, der SSI, PHP oder eine beliebige andere serverseitige Scriptsprache/Funktionalität zur Verfügung stellt. Auf die Umsetzung in SSI und PHP möchte ich im Folgenden eingehen.


Zurück-Link mit SSI (Server Side Includes)

<a href="<!--#echo var="HTTP_REFERER" -->"> Zurück </a>

SSI stellt mittlerweile selbst der billigste Webhoster zur Verfügung. Standardmässig veranlasst man den Webserver, die Seite nach SSI-Tags zu parsen, indem man der Seite die Endung ".shtml" oder ".shtm" verleiht.

Aber was passiert hier genau? Die Umgebungsvariable HTTP_REFERER steht bei jedem Seitenaufruf serverseitig zur Verfügung - das HTTP-Protokoll sorgt automatisch dafür. Die Variable enthält immer die vollständige URL der während einer Browser-Session zuvor aufgerufenen Seite (also die gleiche Information, die auch von history.back() zurückgeliefert wird). Alles was wir tun, ist den Server veranlassen, uns diesen Wert auszugeben, sodass wir ihn als URL für den Zurück-Link nutzen können.

Ausnahmefälle abfangen:
Nun kann es natürlich sein, dass die Variable HTTP_REFERER nicht (sinnvoll) gesetzt ist, entweder wenn die aktuelle Seite die erste aufgerufene Seite der Browser-Session ist oder direkt durch Eingabe in die Adresszeile des Browsers aufgerufen wurde (der Output wäre in diesem Fall "(none)" und der Link tot), oder aber eine externe URL enthält (von der der Besucher kam), sodass ein Klick auf den Link den Besucher wieder von unseren Inhalten wegführen würde.

Mit dem folgenden, alternativen Code lassen sich diese Probleme zum eigenen Vorteil nutzen:

<!--#if expr="$HTTP_REFERER = /deine-domain.de/" -->
<a href="<!--#echo var="HTTP_REFERER" -->"> Zurück </a>
<!--#else -->
<a href="homepage.html"> Zur Startseite </a>
<!--#endif -->

Diese Lösung ist für jeden Fall gewappnet und stellt keine übermässige Belastung des Servers da. Es wird geprüft, ob die Variable HTTP_REFERER den Begriff "deine-domain.de" enthält. Wenn ja, dann wird der Zurück-Link angezeigt, sonst ein Link zur Startseite (natürlich wäre es auch möglich, hier alternativ einfach garnichts auszugeben).


Zurück-Link mit PHP

<a href="<?php echo getenv("HTTP_REFERER"); ?>"> Zurück </a>

In PHP läuft der Vorgang ähnlich ab - Der Server muss dazu PHP unterstützen, und die Datei muss eine entsprechende Endungwie beispielsweise ".php" tragen. Wir rufen mittels der Funktion getenv() den Wert der Server-Variablen HTTP_REFERER ab. Hier ist die Ausnahmebehandlung ähnlich einfach, HTTP_REFERER ist entweder mit einer gültigen URL gesetzt, oder aber ein leerer String. Die makellose Version des Zurück-Links in PHP sähe also folgendermassen aus:

<?php
$referer = getenv("HTTP_REFERER");
$domain = "deine-domain.de";
$internal = eregi($domain,$referer);
if ($internal) {
echo "<a href=\"".$referer."\"> Zurück </a>";
} else {
echo "<a href=\"homepage.html\"> Zur Startseite </a>";
}
?>

Auch diese Variante reagiert in den Sonderfällen mit einem Link zur Homepage, sowohl wenn HTTP_REFERER leer ist (die Funktion eregi() liefert dann false zurück), als auch wenn der Wert eine externe Adresse zu sein scheint (gesucht wird in $referer nach dem String $domain).


Fazit

Ich denke es ist deutlich geworden, dass niemand auf JavaScript angewiesen ist, um einen Zurück-Link zu plazieren. Im Gegenteil, die oben beschriebenen Lösungen haben sogar den Vorteil, dass Besucher möglichst auf der eigenen Seite gehalten werden, und sie funktionieren auch dann, wenn der Besucher ein Sicherheitsfanatiker ist, der JavaScript in seinem Browser deaktiviert hat. Scriptsprachen wie PHP (und alte Pseudo-Ansätze wie SSI) ermöglichen eine Vielzahl von Funktionen, die immer noch häufig mit JavaScript umgesetzt werden. Code-Fragmente können problemlos aus Artikeln wie diesem herauskopiert und benutzt werden, wirklich Programmieren Lernen muss man dazu nicht notwendigerweise, aber auch was das betrifft kommt die Lust ja bekanntlich beim Machen, und wenn man erkennt, was für Möglichkeiten sich daraus ergeben können.


Wer meine doch recht umfangreichen Ausführungen nun belächelt, und mich des Mit-Kanonen-Auf-Spatzen-Schiessens bezichtigt, dem möchte ich trotzdem danken, dass er bis zum Ende durchgehalten hat. Ein Erlebnis heute Mittag hat mich dazu bewogen, mal etwas zum Thema zu schreiben - auch wenn ich nicht gedacht hätte, dass es mich 3 Stunden kostet. Nunja, ich betrachte das als spassige Übung, und ich behalte mir die erneute Wiedergabe an anderer Stelle vor.

Ich hoffe, ich konnte jemandem Anregungen liefern -
So long, viel Spass im Web!

Geil geschrieben und - Oh ja - da hast du uns eiskalt erwischt

Es macht schon Sinn, bei solchen Kleinigkeiten einfach auf JS zu verzichten...unsere verbleibenden JavaScript-Zurück-Schaltflächen werde ich jedenfalls beizeiten ändern...

HTTP_REFERER ist ne feine Sache - aber liefert auch nicht unbedingt immer die Funktion, die gebraucht wird. Der Referer wird immer vom Browser des Users an den Server geschickt - und wie das Schicksal nunmal so spielt, gibt es auch Browser, die dies nicht unterstützen - und wenn man in einem LAN hinter einem Proxy sitzt kann es ebenfalls sein, daß das ganze nicht richtig funzt.

Als Alternativlösung würde ich das Speichern der jeweils aufgerufenen Seiten (erhätlich über die Umgebungsvariable $_SERVER[], z.B. $_SERVER['PHP_SELF']) in einer Session vorschlagen. So lassen sich - für den Webmaster interessant - Klickpfade und Besucherverhalten direkt mitprotokollieren.

Jau, da hast du sicher Recht - ausfallsicher kann das Ganze nicht sein.

Da lassen sich sicher ne Menge tolle und abgefahrene Sachen machen (natürlich auch, was User-Tracking angeht), aber das Ziel waren einfache Lösungen, die halt auch ohne PHP funktionieren können (->SSI), und wenn schon mit, dann ohne grosse Frickeleien.

Ich denke, dass man mit Session-Management kaum einen HTML-Anfänger (selbst einen Fortgeschrittenen) vom JavaScript-Link weglocken kann - der resigniert wohl eher nach 4 Zeilen und packt sich an den Kopf, eventuell sogar mit einem dieser Gesichtsausdrücke:

Angenommen in einem Kontaktformular soll der User u.a. seine Mail-Adresse angeben, die HTML-Datei mit dem Formular ruft mein externes PHP-Script auf und meine Kontrolle stellt fest das die Mail-Adresse ungültig ist. Dann bekommt der User eine Mitteilung, dass er bitte eine gültige Mail-Adresse eintragen soll. Soweit alles klar, jetzt steht unten noch ein Link mit dem der User zurück zum Kontaktformular gelangen kann. Das Problem ist wenn ich den Link per PHP realisiere ist das komplette Kontaktformular mit allen Feldern, Checkboxen, Radiobuttons usw. nach dem klick auf den Link wieder leer und resettet; das suxx maßlos! Nutze ich hier hingegen:

<A href="#" Onclick="window.history.back();">Zurück</A>

bleibt das Formular so gefüllt wie vor der Hinweismeldung, das weiss zu gefallen! Und ich persönlich zwinge lieber die 5% Anti-JS-Neerds dazu den browsereigenen Zurückbutton zu nutzen wenn sie mal einen Fehler beim Ausfüllen des Formulars machen, als 100% aller die mal einen Fehler beim Ausfüllen des Formulars machen dazu wieder alles neu zu tippen!