Das kann man machen, indem man sich große Tabellen anlegt und weitläufiges Suchen & Ersetzen durchführt. Ein “ä” wird da zu “ae”, ein “ß” zu “ss” und so fort. Will man das richtig machen, kann man da herrlich lange Zeit mit dem Tippen von Vorher/Nachher-Zuordnungen verbringen. Super. Muss man das nun unbedingt selber durchexerzieren?

Kann PHP das vielleicht ab Werk selber erledigen? Ja, doch! Das iconv-Modul bringt so einiges mit, um Zeichenketten zwischen Kodierungen hin- und herzuwandeln. Vor allem beherrscht die Funktion iconv() die Fähigkeit zur Transliteration. Das bedeutet, dass ein Zeichen welches im Ziel-Zeichensatz nicht zur Verfügung steht, durch ähnliche Zeichen ersetzt wird. Durch Anhängen von “//TRANSLIT” an den Zielzeichensatz bringt man die Funktion dazu, die speziellen Zeichen nicht zu verwerfen, sondern umzuwandeln:

<?php
$satz = "Olé Garçon! Diese Süßspeise schmeckt gar nicht übel! *börp*";
print (iconv("UTF-8", "ASCII//TRANSLIT", $satz));
?>

Das ergibt diese Zeichenfolge (wohlgemerkt wenn die PHP-Datei in UTF-8 kodiert ist):
Ole Garcon! Diese Suessspeise schmeckt gar nicht uebel! *boerp*

Na bitte!

iconv()-Dokumentation

Da wird nach der Parole “Security through obscurity” auch empfohlen, die Versionsnummer der Installation nicht laut herauszuposaunen, damit es die bösen Cracker in der Zeit zwischen Bekanntwerden einer Lücke und der Installation einer gefixten Version nicht so leicht damit haben, “willige” Opfer zu finden. Na gut, gar nicht so doof!

Leider reicht es dazu nicht aus, einfach das “Generator”-Metatag aus dem Header zu schnipsen. Das System plakatiert seine Versionsnummer an allen Ecken und Enden: in den HMTL-Seiten, in den Feeds und so fort. Das Entfernen des Metatags allein ist bei den letzten Versionswechseln noch ein Stück weit schwieriger geworden – das Tag wird inzwischen von der builtin-Funktion wp_head() erzeugt. Die macht auch noch andere Dinge und ist nicht so leicht verzichtbar.

Abhilfe: der “Generator”-Funktion per Filter einen Riegel vorschieben. Am schnellsten geht das durch Einfügen folgender Zeilen in die function.php des eigenen WordPress-Templates unter /wp-content/themes/THEME-NAME:

function nichts() {
    return "";
}
add_filter('the_generator','nichts');

Das behebt das Problem direkt an der Wurzel, da WordPress auf die Funktion the_generator() an allerlei Stellen zurückgreift. Wer diesen “Schalldämper” lieber als PlugIn mag (zum ein- und ausknipsen), kann sich natürlich auch mit wenigen Handgriffen selber eines daraus basteln – das macht den Webmaster natürlich auch nicht doofer

Gott sei Dank.

Google Finally Removes Comic Sans Font From AdSense Ads

So schaut das Ding übrigens aus, wer’s noch nicht kennt:

Wer’s mal probieren möchte: hier gehts zur Klartext-Uhr

Zutaten:

• Ein willfähriger, leicht zu automatisierender FTP-Client für die Kommandozeile, zum Beispiel nctftp
• eine Shell, wie z.B. die “bash” (auf besseren Systemen zu finden unter /bin/sh)
• die Zugangsdaten der aktuell zu haltenden Blogs
• wenige Minuten Tippen
• Für Neulinge: Internetbrowser und Suchmaschine zum Aufsuchen von Hilfe-Seiten

Das Rezept:

• Editor öffnen
• Ein Script für den Upload schreiben
• Vorsichtige Naturen führen natürlich zuvor auch ein FTP-Backup durch – in entgegengesetzter Richtung
• Script mit “ausführbar”-Flag versehen, ggf. Verknüpfung anlegen

… und fertig ist der Lack. Schon macht der Rechenknecht das, wozu er gedacht ist: dem Menschen Arbeit abnehmen. Dieser kann jetzt anstatt Dateien mit der Maus im FTP-Client durch die Gegend zu bugsieren den sonntäglichen Tatort anschauen (nur so zum Beispiel).

wenn Sie Benutzer eines populären Bookmarking-Services sind, sehen Sie auf dieser Seite (hoffentlich) einen entsprechenden, prominent platzierten Link.

Und wenn nicht (jetzt kommts!), sehen Sie hoffentlich keinen Link.

Deswegen auch “unaufdringlich”, nicht wahr …

Dann schlägt beim Apache-Webserver eigentlich die Stunde für Module wie mod_gzip oder mod_deflate, die für Kompression bei der Übertragung zuständig sind. Gerade diese Helferlein stehen beim Billighoster aber höchst selten zur Verfügung. Der Hoster muss in der Regel mit seiner Prozessorkraft haushalten – und wo käme man da hin, wenn jeder so mirnichts–dirnichts Rechenpower für das Komprimieren von Daten abzweigen kann (um Traffic zu sparen, den man genausogut teuer verkaufen kann)?

Scripte & Stylesheets komprimieren
Scripte und Stylesheets schreien dabei geradezu nach komprimierter Übertragung, bestehen sie doch aus Kompressions-freundlichem ASCII-Gebräu. Wie kriegt man diese Dateien also klein, ohne mod_gzip / mod_deflate zu bemühen?

Kompression mit PHP
Nun gut – dann muss der PHP-Interpreter herhalten: Kompression anschalten, Dateiinhalt ausgeben ausgeben (natürlich mit dem entsprechenden Header), fertig.

Als Beispiel soll mal die Datei "prototype.js" des Prototype-Frameworks herhalten, die unkomprimiert immerhin an die 72KByte auf die Waage bringt.

Und siehe da: der Firefox weist ca. 15KByte übertragene Daten aus – "mal eben" 80% Ladezeit gespart …

Schönheitsfehler Dateiendung
Abzüge in der B-Note gibt es für die falsche Dateiendung: damit die umgepolte Javascript-Datei vom PHP-Parser verarbeitet wird, muss die Endung .php sein. Da weisen wir den Apache per .htaccess-Datei doch lieber gleich darauf hin, dass .js-Dateien ab jetzt PHP-Code enthalten:

(Obacht: die Art, wie dies eingestellt wird kann schonmal von Hoster zu Hoster verschieden sein.)

Kompression ohne Caching ist Quatsch
Indem ich alle .js-Dateien zu dynamische Seiten "befördere", kann die Datei nicht mehr gecached werden und wird bei jedem Seitenaufruf neu geladen. Oopsie! In meinem Beispiel habe ich also schlimmstenfalls nach 5 Seitenimpressionen a 15KByte den gewonnenen Vorteil wieder verspielt. Wer "A" sagt, muss also auch …

… den Browser zum Cachen ermuntern
Header-Informationen über den Zeitpunkt der letzten Änderung an der Datei kann der Webserver nicht an den Browser senden, weil wir PHP benutzen – dynamische Seiten ändern sich eben ständig!
Das erledigen wir also von Hand, indem wir den entsprechenden "Last-Modified" Header selbst erzeugen.

Und damit das auch den gewünschten Effekt zeigt, müssen wir vor der Ausgabe des Dateiinhalts prüfen, ob der Browser noch eine aktuelle Version besitzt ("If-modified-since"-Header). Ist das der Fall, senden wir eine "304 Not Modified"-Antwort – die Datei muss nicht übertragen werden, Zeit und Traffic werden gespart. Hurrah!

Es kommt noch besser: mit der HTTP::Header::Cache() Klasse aus dem PEAR-Repository bringt man seinen dynamischen Dateien im Handumdrehen statische Verhaltensweisen bei und muss nicht das Rad neu erfinden:

Das "Haltbarkeitsdatum" der Datei setze ich einfach mal auf 24 Stunden an. Die Cache-Klasse prüft nun, ob der Browser noch eine gültige Version der Datei besitzt – ist das der Fall, wird der besagte 304-Header abgesendet und das Script beendet.

Plug & Play
Alle seine Scripte und Stylesheets mit PHP-Code vollzustopfen macht auch nicht grade viel Spaß. Darum weise ich den Server per .htaccess-Datei an, in meinem Script-Ordner allen PHP-Dateien automatisch die Datei prepend.php voranzustellen.

Da sich alle zum Einleiten der Kompression nötigen Schritte vor der Ausgabe abspielen (logisch), brauche ich die zu komprimierenden Dateien auf diese Art gar nicht ändern. Einen bitteren Nachgeschmack hinterlässt, dass der PHP-Interpreter die nachfolgende Script/Stylesheet-Datei vergeblich nach PHP-Code durchwühlt. Da bleibt noch Raum für spannende Verbesserungen, aber das soll uns erstmal nicht interessieren.

Diese Lösung gewinnt vielleicht keine Benchmarks, trägt aber vielleicht ein wenig zur verbesserten Benutzererfahrung bei.

Also wieder saugen, Backup machen, hochladen, beten.
Diesmal bin ich immerhin vorbereitet: dank DSL2 (hähähä) geht der Kram diesmal deutlich schneller vonstatten.

Zum Debuggen des geänderten WordPress-Templates – evtl. ist es ja bereits jemandem aufgefallen – fehlt mir die olle Möhre allerdings dann doch gewaltig und der Emulator muss herhalten. Scheiss Internet Explorer halt, aber das ist ja auch nix neues.

Meine Herangehensweise an die Cross-Browser-Problemchen sieht übrigens wie folgt aus:

• Sorgenfreies CSS-Basteln mit dem Firefox, gleichzeitiges Kontrollieren des Outputs im Safari, Opera usw. – kurzum: in Browsern, die nicht so lächerlich sind wie der IE.
• Danach: anpassen der bisher schönen und validen Seite an die buckelige, zurückgebliebene Browser-Verwandschaft. Den Internet Explorer.

In der Regel kann ich so mein Feierabend-Bier wesentlich früher aufmachen, als wenn ich vorwiegend auf die Darstellung im IE schauen würde. Trotz vieler noch vorhandener Bugs werde ich mir genau das jetzt gestatten