Feb 02

Statische Dateien (z.B. CSS, JS, Bilder) verfügen in der Standardkonfiguration von diversen Webservern über keine Expires-Header. Dies führt dazu, dass Dateien i.d.R. vom Browser nicht im Cache zwischengespeichert werden und stets eine Anfrage an den Server gesendet wird. Neben einer größeren Belastung für den Server führt es außerdem zu langsameren Ladezeiten der Webseite. Mit dem Apache-Modul mod_exprires – bei Debian z.B. standardmäßig mit Apache installiert – kann der Expires-Header gesetzt und dem Browser mitgeteilt werden, wie lange sich dieses Element nicht ändern wird. Hierfür fügt man der .htaccess-Datei folgende Zeilen hinzu:

<IfModule mod_expires.c>
	ExpiresActive On
	#ExpiresDefault "access plus 7 days"
	ExpiresByType image/bmp "access plus 7 days"
	ExpiresByType image/gif "access plus 7 days"
	ExpiresByType image/jpeg "access plus 7 days"
	ExpiresByType image/jpg "access plus 7 days"
	ExpiresByType image/png "access plus 7 days"
	ExpiresByType image/x-icon "access plus 7 days"
	ExpiresByType text/css "access plus 7 days"
	ExpiresByType text/javascript "access plus 7 days"
	ExpiresByType text/x-js "access plus 7 days"
	ExpiresByType application/javascript "access plus 7 days"
	ExpiresByType application/x-javascript "access plus 7 days"
</IfModule>

Die Verwendung von ExpiresDefault (hier nicht aktiviert) würde dazu führen, dass für jede ausgelieferte Datei ein Expires-Header gesetzt werden würde. Dies sollte bei dynamisch generierten Webseiten vermieden, da diese aus dem Browser-Cache und nicht vom Server geladen werden und somit nicht den aktuellen Stand widerspiegeln würden. Header für JPG-Bilder und JavaScript werden in diesem Beispiel mehrfach gesetzt, damit unterschiedliche Mime-Types aufgrund verschiedener Konfigurationen von Servern und Ausgaben von Skripts abgedeckt sind.

Alternativ ist es auch möglich, den Expires-Header anhand der Dateiendung zu setzen:

<FilesMatch "\.(bmp|gif|jpg|jpeg|png|ico|css|js)">
	<IfModule mod_expires.c>
		ExpiresActive On
		ExpiresDefault "access plus 7 days"
	</IfModule>
</FilesMatch>

Diese Methode zeigt allerdings nur bei statischen Dateien Wirkung, weshalb bei z.B. dynamisch generierten Bildern die Mime-Type-Lösung gewählt werden muss.

Nov 18

PHP-Caches sind nicht immer nur für massive Performance-Gewinne, sondern manchmal auch für unerklärliche Fehler verantwortlich. So vertragen sich z.B. Horde und eAccelerator nicht. Die generierte Fehlermeldung lässt andere Fehlerquellen vermuten, an eAccelerator denkt man dabei aber vorerst nicht:

Warning: IMAP_Tree::require_once() [function.IMAP-Tree-require-once]: open_basedir restriction in effect. File(Horde/SessionObjects.php) is not within the allowed path(s): (/usr/share/php:/usr/share/pear:/usr/share/horde3:/etc/horde:/usr/lib:/usr/sbin:/var/log) in /usr/share/horde3/lib/Horde/IMAP/Tree.php on line 311

Fatal error: Can’t load Horde/SessionObjects.php, open_basedir restriction. in /usr/share/horde3/lib/Horde/IMAP/Tree.php on line 311

Man erhält also eine “open_basedir restriction”-Fehlermeldung, wie man sie schon häufig gesehen hat. Erste Vermutung ist natürlich, dass die in der php.ini konfigurierten Pfade für open_basedir nicht korrekt sind. Also sucht man zuerst nach der Datei “Horde/SessionObjects.php” und erkennt, dass sich diese an “/usr/share/horde3/lib/Horde/SessionObjects.php” befindet – dieser Pfad ist lt. open_basedir-Einstellung “…:/usr/share/horde3:…” aber eindeutig erlaubt. Die Suche geht weiter und weiter und… bis man auf die Idee kommt, dass man vor ein paar Tagen einen PHP-Cache installiert hat. Sofort nach der Deaktivierung desselbigen funktioniert wieder alles problemlos. Wie meine weiteren Recherchen herausgestellt haben, tritt dieses Problem nicht nur mit eAccelerator auf, sondern auch mit APC, usw.

Oct 02

Üblicherweise werden Templates (“Constants” und “Setup”) mit TypoScript direkt im Backend von TYPO3 geschrieben. Das hat allerdings den Nachteil, dass diese während der Entwicklung nur schwer in Versionsverwaltungen (z.B. SVN oder GIT) zu bringen sind und somit eine Versionierung nur über die History-Funktion von TYPO3 gegeben ist. Allerdings kann man in Templates auch externe Dateien laden:

<INCLUDE_TYPOSCRIPT:source="file:fileadmin/templates/ts/main.ts">

D.h. es ist nur notwendig diese eine Zeile in das Template von TYPO3 einzufügen, damit der TypoScript-Code in einer externen Datei (in diesem Fall unter “fileadmin/templates/ts/main.ts”) gewartet werden kann.

Während der Entwicklung sollte man die Extension abz_developer installieren, da andernfalls externe Dateien immer im Cache zwischengespeichert werden (auch wenn “config.no_cache = 1″ gesetzt wurde) und somit dieser, nach jeder Änderung in der externen Datei, geleert werden müsste. Wenn die Entwicklung fertiggestellt wurde und die Seite in den Live-Betrieb geht, sollte das Plugin aus Performance-Gründen unbedingt wieder deaktiviert werden. Selbstverständlich kann nicht nur das “Setup” des Templates ausgelagert werden, sondern auch die “Constants” auf die selbe Art und Weise.

Alternativ ist es auch möglich im TSconfig-Feld des Benutzers unter “Admin tools > User Admin” die folgende Zeile zusätzlich zu “config.no_cache = 1″ im Template einzufügen, damit externe Dateien immer geladen und nicht im Cache zwischengespeichert werden:

admPanel.override.tsdebug.forceTemplateParsing = 1
Aug 08

Die Web Developer Toolbar von Chris Pederick ist unverzichtbar für jeden Webentwickler. Sie ist kostenlos erhältlich und lässt sich in die Browser Firefox, Flock und Seamonkey integrieren. Bei der Web Developer Toolbar handelt es sich um eine umfangreiche Sammlung von nützlichen Werkzeugen, für die zuvor einige Plug-Ins installiert werden mussten, um die selben Ergebnisse erreichen zu können. So ist es damit möglich einige Einstellungen (Cache, Java, JavaScript,…) auf die Schnelle zu (de-)aktivieren. Weiters nützlich bei der Verwaltung von Cookies, Entwicklung von CSS, Erstellung/Änderung von Formularen und Einbindung von Grafiken. Mit einigen Einstellungen lässt sich die Seite so darstellen, wie sie eine Suchmaschine, oder auf Text-Browser angewiesene Menschen sehen würden. Sonstige Funktionen sind die Darstellungen mit unterschiedlichen Bildschirmauflösungen, hervorheben von Elementen, Benutzung von Lupe und Lineal. Leider konnte ich nur einen kurzen Überblick geben, denn die Möglichkeiten sind praktisch unendlich.

Jul 26

Bei der Entwicklung von Webseiten werden (logischerweise) sehr oft Änderungen an HTML, CSS, JS, etc. durchgeführt. Dabei kann es passieren, dass Änderungen nach dem erneuten Laden der Seite (Refresh/Reload) nicht angezeigt werden, da die Seite bzw. die eingebundenen Dateien aus dem Cache des Browsers und nicht wie gewünscht erneut vom Server geladen werden. D.h. es sieht so aus, als ob die durchgeführten Änderungen (auch) nicht den gewünschten Effekt hervorrufen, obwohl sie das (wenn die komplette Seite vom Server geladen werden würde) vielleicht machen.

Abhilfe schafft es, wenn man den lokalen Cache im Browser deaktiviert. Dafür kann man entweder in den Einstellungen des Browsers die gewünschte Einstellung vornehmen, was aber beim Besuch von anderen Webseiten (beim “normalen” Surfen) nicht unbedingt erwünscht ist.

Für auf der Gecko-Engine basierende Mozilla-Browser gibt es die Web Developer Toolbar von Chris Pederick. Diese erlaubt es den Cache sehr einfach zu deaktivieren bzw. auch wieder zu aktivieren:

Eine weitere und wohl die bequemste Möglichkeit ist es, die Tastenkürzel der einzelnen Browser zu verwenden, die nicht nur die Seite neu laden, sondern auch den lokalen Cache der aktuellen Seite löschen:

  • Internet Explorer: Strg + F5 (Windows)
  • Firefox: Strg + F5 oder Strg + Umschalt + R (Windows) bzw. Cmd + Umschalt + R (Mac)
  • Safari: Cmd + Umschalt + R (Mac)