Seite neu und nicht aus dem Cache laden beim Betätigen des Zurück-Buttons

Unter bestimmten Umständen will man erreichen, dass eine dynamisch erzeugte Seite nicht gecacht, sondern bei jedem Aufruf neu geladen wird. Insbesondere, wenn man sich mit den Vor- und Zurück-Buttons in der Browser-History hin- und herbewegt.

Ein Anwendungsbeispiel wäre etwa eine Anmeldemaske, die mit AJAX funktioniert. Man meldet sich auf einer Seite per AJAX an und klickt dann auf den Zurück-Button. Wenn der Browser die Seite nun aus dem Cache zieht, dann sieht es für den User aus, als wäre er doch noch nicht eingeloggt. Erst ein manuelles Neuladen würde hier helfen.

Ein weiteres Beispiel wäre etwa die Warenkorbanzeige in einem Shop. Wir legen auf der Produktdetailseite ein Produkt in den Warenkorb und klicken anschließend auf den Zurückbutton, um auf die Übersichtsseite mit den anderen Produkten zurückzukehren. Lädt der Browser die gecachte Version, so bekommen wir hier den alten Warenkorb angezeigt. Das ist zwar nicht falsch, aber Usability-technisch unschön.

Wie kann man das Neuladen also erzwingen? Die Frage stellte sich mir kürzlich bei Usability-Tests eines größeren Projekts. Bei der Suche nach einer Antwort bin ich zunächst auf einige HTML-Tags für den HEAD-Bereich gestoßen:

<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="expires" content="-1">

Interessanterweise hat das meinen IE8 nicht davon abgehalten, die Seite trotzdem aus dem Cache zu laden. Also mussten schwerere Geschütze aufgefahren werden. Fündig wurde ich in einem Munitionsbunker auf php.net, genauer gesagt auf der Doku-Seite der header()-Funktion:

<?php
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Datum in der Vergangenheit
?>

Vereinfacht betrachtet bewirken diese zwei Codezeilen das Gleiche, was die Meta-Tags von oben auch hätten tun sollten, nämlich dem Browser mitzuteilen, dass ein Caching nicht erwünscht ist. Dies erfolgt durch HTTP-Header, die dem Browser durch die explizite Anweisung "no-cache, must revalidate" und einem Verfallsdatum in der Vergangenheit klarmachen, dass die Seite neu geladen werden muss. So klappt es auch mit dem Internet Explorer.

Nichts hält länger als ein Provisorium

Also wenn ich die letzten 3 Wochen in meinem neuen Job so Revue passieren lasse, dann muss ich immer an die Weisheit "nichts hält länger als ein Provisorium" denken. Was hier so hinter den Kulissen abgeht ist ja eine Sache. Aber was den Kunden dann verkauft wird ist teilweise doch etwas haarsträubend. Wir müssen offenbar einen sehr fähigen Vertrieb haben, wenn der es schafft, unser Produkt an diese namhaften Kunden zu verkaufen, die bei uns auf der Referenzliste stehen. Vermutlich haben wir aufgrund genau dieser Referenzliste gute Chancen, dass weitere namhafte Firmen sich den Mist aufschwatzen lassen.

Ich will nicht sagen, dass das System nicht funktioniert. Bin ja quasi mit dafür verantwortlich, dass es das tut, was es soll. Irgendwie funktioniert alles recht gut. Aber das "wie" ist dann doch etwas komisch. Die Leute, die das Teil irgendwann mal programmiert haben, sind längst weg. Nichts ist dokumentiert, und alle Anpassungen, die seither implementiert wurden, sind eher sowas wie Hotfixes der Marke "quick&dirty". Hauptsache, es funktioniert. Bin mal gespannt, wann es knallt und keiner mehr eine Lösung weiß.

Ich will ja auch nicht sagen, dass das woanders anders wäre. Aber ich würde es mir wünschen, dass die Entscheider in Firmen doch auch öfters mal auf Leute hören, die sich mit ihrer Materie auskennen...
Aber das ist eine andere Welt.

My software never has bugs...

...it just develops random features.

TYPO3 News tt_news Probleme mit Sortierung

Gestern bin ich durch Zufall auf einen ganz blöden Effekt bei Mysql gestoßen, der sich im Speziellen bei der Sortierung bzw. Sortierreihenfolge der News in der beliebten TYPO3-Extension "tt_news" auswirkt. Ich hatte gerade einen neuen Beitrag geschrieben und musste feststellen, dass der nicht wie gewünscht oben in der Listenansicht erscheint, sondern unten. Auch nach diversem Experimentieren mit Typoscript und den Flexforms ließ sich das Problem nicht beheben.

Also habe ich erst einmal gegoogelt und bin dabei auf einen interessanten Forenbeitrag gestoßen. Dem zufolge handelt es sich hier scheinbar nicht direkt um ein Problem mit der Extension oder TYPO3 selbst, sondern um einen Bug im MySQL-Serversystem. Wie es der Zufall so wollte, setzen auch wir in dem betroffenen System MySQL in der Version 5.0.51 ein, wo das Problem noch auftritt. Da der Bug aber bekannt ist, sollte er in der nächsten Version (5.0.52) wieder behoben sein.

Bis dahin kann man sich damit behelfen, bei tt_news eine kleine Code-Passage auszukommentieren. Diese befindet sich im Installations-Verzeichnis der tt_news-Extension und dort dann in der Datei "pi/class.tx_ttnews.php"
Fast ganz am Ende findet sich ein Abschnitt, der mit "// GROUP BY" eingeläutet wird. Diese Zeilen kommentiert man dann folgendermaßen aus:

// GROUP BY
/*if (trim($conf['groupBy'])) {
$queryParts['GROUPBY'] = trim($conf['groupBy']);
$query.=' GROUP BY '.$queryParts['GROUPBY'];
}*/

Das wars. Jetzt müsste die Sortierung wieder ordnungsgemäß funktionieren. Aber man sollte dabei bedenken, dass beim Update von tt_news diese Änderungen wieder überschrieben werden. Wenn die neue Version nicht eh schon diesen Hotfix enthält, muss man die Änderungen wiederholen.

Änderungen in PHP6

PHP5 ist noch nicht einmal flächendeckend auf allen Servern verfügbar, da kommen schon die ersten Vorboten der 6er Version. Auf einer Seite der IBM DeveloperWorks finden sich schon einmal ein paar Änderungen und Features in PHP6 aufgelistet. Dazu gehören eine verbesserte Unicode-Unterstützung sowie Namespaces, ein Feature zur Vermeidung von Namenskollisionen bei Funktionen und Klassen (soll übrigens evtl. auch schon in 5.3 integriert werden).

Davon abgesehen werden auch ein paar Sachen entfernt. Als da wären:

• magic_quotes
• register_globals
• register_long_arrays
• safe_mode
• PHP-Tags (ASP-Style)
• FreeType 1 and GD 1
• ereg()

Meine Meinung zu den entfernten Features: das geht in Ordnung. Es handelte sich hierbei eh nur noch um Altlasten aus vergangenen Zeiten. Applikationen, die darauf angewiesen sind, könnten pauschal mal eine Erneuerung vertragen.

Man darf also gespannt sein. Bis PHP6 aktuell wird, wird noch viel Wasser den Rhein runterfließen.