Speicherhunger von Wordpress zähmen

Jeder, der sich schon mal mit mir über das Thema Weblogs unterhalten hat, kennt meinen Erzfeind: Wordpress.

Ich kann diese Software nicht ausstehen, denn der absolut größte Teil der Probleme im Support dreht sich um diese Software. In letzter Zeit wesentlich mehr als früher. Da ich mich Kunden gegenüber aber mindestens neutral verhalten muss und ein "Läuft bei uns halt nicht" für mich selten in die Tüte kommt, so muss ich diesen ganzen Frust in mich rein fressen.

Mir musste auffallen, dass sich Speicherprobleme bei Wordpress sehr oft im Package "pomo" ereignen. Der Name hat mich gleich an das GNU gettext-Projekt erinnert, da dort mit .po-Dateien in .mo-Dateien kompiliert werden um Anwendungen quasi eine Datenbank zur Lokalisierung (bzw. Übersetzung) von Texten bereit zu stellen. Bei Wordpress verhält es sich genau so: "pomo" ist dazu da um Wordpress vom Englischen her in andere Sprachen zu übersetzen.

Auf wordpress.org kann man ebenfalls nachlesen, dass man sich für die Lokalisierung mittels gettext entschieden hat. Sehr schön bis hier hin! Auch wir setzen in unseren Projekten auf diese quasi als Standard etablierte Technik ein - auch wenn ich zugegebener Maßen selbst oft das Rad neu erfinden will. Nur eifert Wordpress mir in dieser Sache etwas hinterher: "pomo" ist eine komplett eigenständige Implementierung, die .mo-Dateien auf dem Server parsed und entsprechend übersetzt - in PHP geschrieben. Ich habe es nun nicht geprüft, aber ich wette nahezu, dass der Code etwas ineffizient ist (warum? Mehr dazu später)

Heute morgen hatte ich irgendwie die Faxen dicke. Es kann doch nicht sein, dass so schöne Grundlagen geschaffen werden aber zum Schluss hin dann nur halbherzig umgesetzt werden. Also habe ich mir ein deutsches Wordpress heruntergeladen und auf einem normalen 64-Bit-System mit PHP (5.3.3) über FastCGI und mit einem Speicherlimit von 28 MB installiert - ein ganz normaler Kundenaccount der Größe "Starter" also - und ich hatte von vorne herein Probleme. Als "jemand vom Fach" für mich eigentlich nur kaum nachvollziehbar und als ich den "pomo"-Teil von Wordpress deaktiviert habe auch sofort weg.

Nun ist das Abschalten sämtlicher Übersetzungsfunktionen keine Lösung. Deswegen habe ich einen kleinen Patch für die Datei wp-include/l10n.php geschrieben und die .mo-Dateien von Wordpress in einer mit gettext kompatiblen Verzeichnis-Struktur abgelegt (Siehe Skript).

Mit dem Patch nutzt Wordpress nun (sofern Verfügbar) die native gettext-Erweiterung von PHP. Und siehe da: Mein Test-Blog ist in deutscher Sprache verfügbar und ich konnte das Speicher-Limit von PHP sogar testweise auf 6 MB herabsetzen (mehr habe ich mich nicht getraut).

Das muss man sich mal vorstellen: Mit einer kleinen Änderung von ca. 30 Minuten habe ich den Speicherbedarf von Wordpress um weit mehr als 75% gesenkt. Wobei man hier zugegeben muss: Ich habe nur auf einem Test-Blog gearbeitet. Folglich funktioniert der Patch nachweislich für eine Standard-Installation - mit einem anderen Theme oder einer Reihe von Plugins habe ich es nicht getestet. Wenn diese aber den etablierten gettext-Richtlinien folgen, sollte das eigentlich kein Problem sein.

Alle Dateien meiner kleinen Wordpress-Exkursion gibt es hier: http://oss.tiggerswelt.net/wordpress/
Ich für meinen Teil bleibe bei Serendipity - damit gab es noch nie Probleme

Nachtrag (17:57):
Habe den Patch etwas angepasst. "build-lang.php" wird nun nicht mehr benötigt, die von mir gepatchte "l10n.php" installiert sich die .mo-files nun nach Bedarf unterhalb der richtigen Text-Domain (sofern die entsprechenden Berechtigungen bestehen, mit unserem Webhosting tut es in der Regel recht gut )