Dies sieht sehr verdächtig nach einem Speicher-Problem aus. Doch wo genau tritt der Fehler auf und was kann man dagegen unternehmen? Ein kleiner Suchtrip durch den Quellcode von WordPress (zum Zeitpunkt dieses Artikels in der Version 2.7 ) zeigte bald, dass der Inhalt einer meiner langen Artikel in der Funktion wpautop() in der Datei ./wp-includes/formatting.php verloren ging. Und zwar genau in der vorletzte Zeile der Funktion:

$pee = preg_replace('/<p>\s*?(' . get_shortcode_regex() . ')\s*<\/p>/s', '$1', $pee); // don't auto-p wrap shortcodes that stand alone

(WordPress 2.7, Datei formatting.php, Funktion wpautop(), Zeile 153)

Diese Funktion sorgt dafür, dass vor der Ausgabe der Beiträge Zeilenumbrüche in HTML-Zeilenumbrüche (<br />) und HTML-Paragraphen (<p />) umgewandelt werden. Sie wird vor der Ersetzung der ShortCodes aufgerufen. Die letzte Ersetzung sucht nun allein stehende ShortCodes und entfernt mögliche (automatisch hinzugefügte) Paragraphen um diese. Die hier aufgerufene Methode get_shortcode_regex() liefert dabei das Suchmuster für die definierten ShortCodes zurück. Diese befindet sich in der Datei ./wp-includes/shortcodes.php ab der Zeile 165. Der hier zurück gelieferte reguläre Ausdruck sucht nach einem Muster in der folgenden Form:
In diesem Ausdruck werden zwei nicht-gierige (non-greedy, lazy) Quantoren eingesetzt. Dies bedeutet, es wird sehr viel Backtracking betrieben: die RegEx-Engine überspringt im ersten Schritt die Zeichen, welche auf solche nicht-gierigen Quantoren passen, da ja an dieser Stelle versucht wird, so wenig wie möglich einzufangen. Trotzdem merkt sich die Engine, wo sie notfalls nachschauen muss, falls der ganze restliche Text so erstmal nicht in das Suchmuster passt. Der “ganze Rest” bei großen Beiträgen mit mehreren nicht-gierigen Quantoren kann ganz schön viel sein, was die Historie gerne anwachsen lässt. Wir dürfen nicht vergessen: die RegEx-Engine geht am Ende nach und nach wieder ein Schritt zurück und prüft erneut nach, ob sie ein Ergebnis findet (Backtracking). Um den Aufwand zu minimieren, bietet es sich an, den zu überprüfenden “Rest” lokal einzuschränken. In unserem Fall wird der Zeichenbereich der Parameterpaare mit dem Endzeichen “]” eines Tags begrenzt. Ändern wir nun den roten Abschnitt (.*?) zu ([^\]]*?), trennen wir somit die Non-Greedy-Bereiche (Parameterpaare und mögliche Zwischeninhalte) und minimieren den Aufwand und somit den Speicherverbrauch. Unser überlanger Artikel müsste wieder erscheinen.

Mit einer kleine Schönheitsoperation können wir noch die (in meinen Augen) unnütze grüne, nicht-einfangende Klammerung um den eingefangenen optionale Schrägstrich entfernen: (?:(\/))? zu (\/)?. Die modifizierte Methode get_shortcode_regex() sieht nun wie folgt aus:

function get_shortcode_regex() {
    global $shortcode_tags;
    $tagnames = array_keys($shortcode_tags);
    $tagregexp = join( '|', array_map('preg_quote', $tagnames) );

    return '\[('.$tagregexp.')\b([^\]]*?)(\/)?\](?:(.+?)\[\/\1\])?';
}

(WordPress 2.7, Datei shortcodes.php, Funktion get_shortcode_regex(), Zeile 165)

(Problems in Wordpress with long posts and plugins like NextGEN Gallery)

Das Problem wird durch bestimmte Metadaten in der Extensible Metadata Platform von Adobe verursacht. XMP ist eins von vielen Metadaten-Formaten welche in Grafikdateien eingesetzt werden und bietet den Vorteil, dass beliebige Informationen darin abgelegt werden können. Konkret handelt es sich dabei um ein Format zum Einbetten von RDF-Daten (Resource Description Framework) in Binärdateien. Das Format wird bereits von allen aktuellen Adobe-Produkten und einigen CMS-Anbietern unterstützt. Auch Lightroom speichert so zusätzliche Informationen ab, welche anscheinend von der Core Graphics Bibliothek des OS X 10.5.1 Betriebssystems nicht verstanden werden. Leider führt dies in den meisten Fällen zum Absturz einiger Anwendungen, welche diese Bibliothek einsetzen. In dem hier beschriebenen Fall verabschiedet sich der Finder.

Eine mögliche Lösung des Problems besteht nun darin, dass alle XMP-Metadaten wieder komplett aus den Bildern entfernt werden. Wenn die digitale Kamera ihre Informationen in einem anderen Metadatenformat ablegt (z.B. EXIF, GPS, IPTC…) und man nicht auf die XMP-Angaben in den Dateien angewiesen ist, stellt dieser Vorgang auch kein Problem da. Allerdings sollte man vor der Bearbeitung logischerweise ein Backup seiner Medien anlegen.

Ein sehr hilfreiches Tool nennt sich ExifTool und kommt von Phil Harvey. Hiermit lassen sich unterschiedliche Metadaten-Formate in Medien ausgeben und bearbeiten. In den Manpages von ExifTool findet man auch schnell alle nötigen Parameter sowie einige Beispiele für den Umgang mit diesem Tool. Mit folgendem Befehl in der Konsole können nun die XMP-Metadaten rekursiv aus allen Dateien in einem Verzeichnis und dessen Unterverzeichnissen gelöscht werden:

exiftool ./ -xmp:All= -r -overwrite_original

Hierbei haben die übergebenen Parameter folgende Bedeutung:

1. -xmp:All=
   XMP-Tag aus der Datei komplett löschen.
2. -r
   Rekursiv durch alle Unterverzeichnisse durchgehen. Dies setzt voraus, dass die Übergebene Datei-Angabe ein Verzeichnis ist (hier “./” für das aktuelle Verzeichnis in der Konsole).
3. -overwrite
   Überschreibt die originale Datei (Backup nicht vergessen!). Wird dieser Parameter weggelassen, benennt das ExifTool die originale Datei um, indem dem vorhandenen Dateiname der String “_original” angehängt wird.

Leider brachte das Update auf Lightroom 1.3 hier keine Lösung, was auch verständlich ist. XMP soll ja weiterhin beliebige Metadaten speichern können ohne dass Programme oder Bibliotheken, welche nicht alle Angaben verstehen, sich verabschieden. Bleibt nun nur noch die Hoffnung, dass Apple hier bald eine Lösung in einem weiteren Update liefert, nachdem die OS X Version 10.5.1 dieses Problem ausließ.

Hier bekommt die ForEach-Schleife ein ungültiges Array von der Funktion glob() geliefert, wenn diese auf einen Fehler trifft. Damit in solch einem Fehlerfall die nervige Fehlermeldung nicht mehr auftaucht, muss der Code in bb-settings.php angepasst werden.

Die Funktion glob() liefert alle Verzeichnisnamen in einem Array zurück, die zu dem übergebenen Such-Pattern passen. Hierbei wird die glob() Funktion aus libc eingesetzt. Werden keine Dateien bzw. Verzeichnisse gefunden, die auf das Suchkriterium passen, liefert die Funktion ein leeres Array zurück. Tritt ein Fehler bei der Ausführung auf, ist das Ergebnis FALSE. Und genau dieser Fehlerfall führt zu der oben beschriebenen Fehlermeldung.

FALSE ist ein Wahrheitswert (boolean) und kein Array und darf somit nicht dem ForEach-Kommando in bb-settings.php in der Zeile 173 (bzw. in der Version 0.8.3.1 in Zeile 169) übergeben werden. Um dies zu verhindern, muss dieser Fehlerfall vorher überprüft werden. Dies kann mit der folgenden Code-Anpassung erreicht werden:

Originaler Code in bb-settings.php der Version 0.8.3 ab Zeile 172 / 168:

if ( is_callable( 'glob' ) )
    foreach ( glob(BBPLUGINDIR . '_*.php') as $_plugin )
        require($_plugin);

Anpassung:

if ( is_callable( 'glob' ) ) {
    $pluginarray = glob(BBPLUGINDIR . '_*.php');
    if ($pluginarray)
        foreach ( $pluginarray as $_plugin )
            require($_plugin);
}

Es sei hier noch erwähnt, dass mit dieser Änderung nicht gleich auffällt, ob PlugIns, welche mit einem Unterstrich anfangen, auch wirklich geladen werden oder ob hier ein Fehler auftritt. Man merkt dies aber dann, wenn eben die gewünschte Erweiterung nicht vorhanden ist.

(Gelöst mit WordPress 2.6.1 – Details weiter unten…)
PHP könnte direkt mit gettext-Support kompiliert werden. Dadurch stünden entsprechende Funktionen direkt zur Verfügung. Doch würde solch ein Programm nicht auf einem Rechner ohne entsprechende Unterstützung laufen. Aus diesem Grund wurde in WordPress das Projekt PHP gettext integriert. Die Implementierung liegt in den Dateien “gettext.php” und “streams.php” im “wp-includes”-Verzeichnis. WordPress erhält dadurch die Fähigkeit diese MO-Dateien einzulesen. Doch genau hier entstanden ab und zu Probleme.

Betrachtung des Problems

Die oben dargestellte Fehlermeldung kam bei mir sporadisch. Und ich kenne die Fehlerstelle genau. Sie befindet sich in der Datei “streams.php” in der Klasse StringReader. Und dort in der Funktion read($bytes). Hier lieferte die Zeile $data = substr($this->_str, $this->_pos, $bytes); nicht immer den richtigen Teilstring zurück. Manchmal war der Inhalt genau um ein Byte verschoben. Dadurch wurden in der Datei “gettext.php” in der Funktion gettext_reader(…) Strukturinformationen einer MO-Datei falsch interpretiert, was wiederum dazu führte, dass Mengenangaben komplett falsch eingelesen wurden. In solch einem Fehlerfall wurde die seekto() Funktion mit einem großen negativen Wert aufgerufen, was dazu führte, dass der Stream-Positionszeiger an das Ende der Daten gesetzt wurde. Dadurch lieferte jeder weitere Aufruf der Lesemethode einen Leerstring zurück. Und genau solch ein Leerstring wurde der Methode unpack() in der Datei “gettext.php” in der Zeile 85 übergeben, was zu der oben besagten Meldung führte.

Es ist zwar nicht wirklich eine Lösung, doch hatte ich die oben benannte Codezeile temporär mit folgenden Kommandos ausgetauscht:

Alter Code:

$data = substr($this->_str, $this->_pos, $bytes);

Neuer Code, der immer den richtigen Teilstring ermittelt:

$data = "";
for ($i=0; $i<$bytes; $i++) {
    $data .= $this->_str[$this->_pos+$i];
};

Gibt man hier noch eine Meldung aus, sobald die beiden ermittelten Teilstrings unterschiedlich sind, dann merkte man, dass diese gleichzeitig mit dem hier beschriebenen Fehler auftauchte. Verglich man die Inhalte, sah man, dass bei einer Startposition > 0 der Teilstring aus substr() um ein Zeichen/Byte verschoben war. Statt z.B. den Inhalt von Index 4-7 zu ermitteln, lieferte diese Methode dann die Zeichen 5-8. Wohl bemerkt, dies aber nur sehr sporadisch!

Eigentlich eine fatale Sache, wenn ein regulärer PHP-Befehl Probleme verursacht. Dieser Befehl, der Teile aus gegebenen Texten extrahiert, kommt in WordPress häufiger zum Einsatz. Am sichtbarsten ist er in Kombination mit der Datei “gettext.php”, da hier ein Fehler geworfen wird. Aber mir ist ebenfalls aufgefallen, dass es auch Probleme mit dem Abspeichern geschriebener Inhalte gab. Hier kam es vor, dass an Stellen eingebundener Steuercodes (Links, Code-Tags) Teile des Inhaltes verschwanden. Man bemerkte die Fehlersituation, da der berühmte gettext-Fehler auftrat. Aus diesem Grund ließ ich die oben beschriebenen neuen Codezeilen auch nicht in meiner Installation. Mir sind mit diesem Code schon Inhalte verschwunden, ohne dass ich dies sofort bemerkte.

Lösungswege

Auf jeden Fall musste die Problemursache an einer Server-Konfiguration oder –Komponente liegen. Ich verwalte noch eine weitere WordPress-Webseite und dort bekam ich noch keine Fehler. Zu erwähnen ist auch, das beide Seiten beim gleichen Provider gehostet werden, die gleiche PHP-Version installiert war und inzwischen bei beiden WordPress in der Version 2.3 vorlag.

Meine temporäre Lösung bestand darin, dass ich auf meiner Seite die originale englische Version von WordPress installierte. Somit trat der Fehler seltener auf, da eine Sprachdatei weniger eingelesen werden musste. Er verschwand aber nicht komplett, weil noch PlugIns mit Sprachdateien installiert waren. Dies machte sich dann aber eher im Admin-Bereich, vor allem beim Speichern der Beiträge bemerkbar.

Dank dem schnellen und motivierten Support meines Providers All-Inkl.de dachten wir zuerst, dass wir den Fehler eindämmen konnten. Der erste Versuch bestand darin, den ZEND-Optimizer zu installieren und weitere PHP-Parameter an den Parametern des Servers meiner anderen WordPress-Präsenz anzupassen. Leider ohne dem gewünschten Ergebnis. Ein Update der PHP-Installation von der Version 5.2.3 auf 5.2.4, sowie die Aktualisierung der Apache-Installation von der Version 2.2.4 auf 2.2.6 ließen den nervigen Fehler dann kurzzeitig doch verschwinden. Vermutlich besitzt substr() in PHP 5.2.3 nicht die erhoffte Stabilität.

Update 24.10.07:
Das Problem tritt seit heute leider wieder auf! Womöglich lag es doch nicht an der alten PHP-Version. Ich verfolge das weiter…

Update 30.10.07:
Das ist schade, aber auch das Update auf Wordpress 2.3.1 DE brachte nicht den erhofften Erfolg. Wir sind leider so langsam am Ende mit dem Suchen, auch mit der Geduld. Der nächste Schritt besteht wohl darin, meinen Webspace innerhalb meines Providers auf einen anderen Server zu verschieben. Zur Zeit habe ich die Datei “/wp-includes/languages/de_DE.mo” entfernt, damit der Fehler nicht mehr so häufig auftritt.

Update 03.11.07:
Mein Provider All-Inkl hat nun meine Webseite auf einen anderen Server installiert. Seit dem scheint die Webseite ohne Probleme zu funktionieren. Schade ist nur, dass wir nun nicht genau wissen, welche Server-Einstellung / Hardware-Kombination hier wohl Probleme mit der Funktion substr() aus PHP 5 verursacht.

Update:
Der Fehler taucht wieder auf…

Update 15.11.07:
Heute wurde PHP 5.2.5 auf dem Webserver installiert. Laut All-Inkl bin ich der Erste, der diese Installation testen darf. Ich laufe nun auch wieder auf der originalen deutschen Version. Bis jetzt sind mir noch keine Probleme begegnet. Die Zeit wird zeigen, ob das die Lösung war…

Update 26.02.08:
Im Kommentar Nr. 48 berichtet Niko_K, dass das Problem wohl durch nicht übereinstimmende Spracheinstellungen zwischen der WordPress-Configuration und dem Linux-System (Variable LANG) auftritt. Danke!

Ich vermute stark, dass PHP-String-Funktionen wie das substr() wohl abhängig von den Systemeinstellungen sind und somit mit den richtigen Daten befüttert werden müssen.

Update 25.04.08:
Im Kommentar Nr. 60 berichtet Kretzschmar darüber, dass der Fehler unter PHP 4 nicht mehr auftaucht. Die Umstellung von PHP 5 auf PHP 4 kann beim Provider All-Inkl wohl selbst vorgenommen werden.

Ubdate 24.06.08:
Der Bug ist inzwischen schon bei Wordpress registriert (Bug 5599 – danke an Codestyler für den Hinweis). Hier wird aktuell eine Alternative zu substr() eingesetzt. Diese Lösung ist eleganter als die oben beschriebene. Leider ist die korrigierte Stelle nicht die einzige mit dem Befehl substr(), weswegen man trotzdem ein Fehlverhalten bzw. Datenverlust in der Anwendung erwarten kann.

Update 15.08.08:
Endlich! Wordpress 2.6.1 liefert nun ein Bugfix zu diesem Problem. Der Fehler tritt auf, sobald man in der php.ini den Eintrag mbstring.func_overload auf einen anderen Wert als 0 stellt. Meist erlauben die Provider es, diesen Wert für die eigene Web-Präsenz zu ändern. Ein Bug im Apache-Modul mod_php sorgt allerdings bei dieser Art der Umstellung dafür, dass sie für alle V-Hosts des Servers gilt! Sobald also ein User des gleichen V-Hosts an dieser Einstellung dreht, erscheinen bei den anderen WordPress-Präsenzen auf dem Server wohl diese Fehler, zumindes bis eine andere Präsenz diesen Wert wieder auf 0 stellt. Näheres hierzu unter code-styling.de.

Native Lösung

Es lief einige Tage gut, nun sind seit heute (06.11.2007) alle WordPress-Seiten auf dem neuen Server wohl auch betroffen…

Im deutschsprachigen WordPress-Forum bin ich nun auf eine weitere Lösung gestoßen: Einsatz des originalen gettext() Kommandos. Diese Lösung kann leider nur dann angewendet werden, wenn gettext auf dem entsprechenden Server installiert ist. Ein Blick in die PHP-Info liefert hierzu Informationen:
GetText Support enabled

Worin besteht die Lösung? In der WordPress-Datei /wp-includes/l10n.php wird die WordPress-Version von gettext() aufgerufen. Der Code wird nun so geändert, dass die installierte Funktion gettext() anstelle der problematischen gettext-Vertretung aufgerufen wird. Dazu muss die Sprachdatei /wp-includes/languages/de_DE.mo zu wordpress.mo umbenannt und in ein neues Verzeichnis kopiert werden. Der Name des Verzeichnisses ist abhängig von der eingestellten Codierung in der Datei wp-config.php:

Eine Sprachdefinition define (’WPLANG’, ‘de_DE.UTF-8′); benötigt das Verzeichnis wp-includes/locale/de_DE.UTF-8/LC_MESSAGES/.

Lautet die Sprachdefinition define (’WPLANG’, ‘de_DE’); muss das Verzeichnis den Namen wp-includes/locale/de_DE/LC_MESSAGES/ tragen.

Wenn man will, kann man in der Datei wp-settings.php die Zeilen
include_once(ABSPATH . WPINC . ‘/gettext.php’);
include_once(ABSPATH . WPINC . '/streams.php');
auskommentieren und die Dateien gettext.php und streams.php löschen.

Damit die Umstellung schnell vollzogen werden kann, hab ich für WordPress 2.3.1 Deutsch ein kleines ZIP-File mit allen nötigen Änderungen erstellt:

Native_gettext_WordPress_2.3.1.zip

ACHTUNG:
hier bitte auf die richtige Codierung achten, damit beim Posten keine Inhalte verloren gehen. Am Besten vorher ein Backup der Datenbank anlegen. Wenn eine andere Wordpress-Version unterstützt werden soll, dann einfach die Sprachdateien aus dem ZIP-File entsprechend der obigen Anleitung selbst generieren.

Und nicht vergessen: somit ist das Anzeige-Problem gelöst, der Fehler taucht nicht mehr auf, aber es gibt noch viele andere substr()-Aufrufe, welche schief laufen können. Auffällig ist dabei Datenverlust an den Steuer-Tags aus der Code-Ansicht.

Versteckte Optionen

Nicht alle Optionen, die der Firefox versteht, sind über normale Konfigurations-Dialoge erreichbar. Dies hat auch seinen Grund. Manche Optionen sollten nur verändert werden, wenn man sich seiner Tat sicher ist. Mittels der Eingabe von “about:config” in der Adressleiste erreicht man die Übersicht aller eingestellten Optionen. Gibt man in dem nun sichtbaren Suchfeld einen (Teil-)Text ein, werden die Optionen entsprechend gefiltert. Einzelne Optionen können hier verändert werden. Wird ein neuer Eintrag mittels der rechten Maustaste angelegt, hat man die Typ-Auswahl zwischen Zahl (Integer), Wahrheitswert (Boolean) oder Text (String). Die hier beschriebenen Einstellungen müssen also genau auf dieser Seite vorgenommen werden, notfalls müssen die einzelnen Parameter neu erstellt werden. (Anmerkung: das Plugin About:About von MrTech bietet einen einfachen Zugriff auf alle about:*-Seiten des Firefox)

Speicherverbrauch reduzieren

Seine Stärke kann gleichzeitig auch seine Schwäche werden. Einige Erweiterungen benötigen unnötig viel Speicher und CPU-Kapazität. Auf der Webseite von MozillaZine.org findet man eine Liste der gängigsten PlugIns mit bekanten Problemen.

Ein weiteres “Feature”, wie es Firefox Lead Engineer Ben Goodger in seinem Blog-Beitrag bezeichnet, besteht in dem Zwischenspeichern der zuletzt besuchten Seiten. Die Intention dieser Vorgehensweise rührt von der Erkenntnis, dass viele Seiten mittels dem “Zurück-Button” wieder verlassen werden. Somit können die vorherigen Webseiten schnell wieder dargestellt werden, ohne dass die Daten vom Server noch einmal angefragt werden müssen. Verfügt man allerdings über eine nicht allzu schmale Bandbreite, kann man diese Option zu Gunsten des Speicherverbrauches abschalten. Hierzu muss lediglich die Option browser.sessionhistory.max_total_viewers = 0 eingetragen werden.

Die Cache-Größen an sich können ebenfalls definiert werden. Dabei muss darauf geachtet werden, dass die angegebenen Werte ein Vielfaches von 8 sind, ansonsten werden sie ignoriert. Der Parameter browser.cache.disk.capacity (mit browser.cache.disk.enable) definiert die Größe des Zwischenspeichers auf der Festplatte, während der Parameter browser.cache.memory.capacity (mit browser.cache.memory.enable) den reservierten Platz im Hauptspeicher bestimmt. Setzt man den Firefox unter Windows ein, kann einem die Option config.trim_on_minimize = true behilflich sein. Sie veranlasst den Firefox seine Caches zu leeren, sobald das Fenster in die Taskleiste minimiert wird.

Übertragungsgeschwindigkeit

Die meisten Webseiten im Internet werden mittels des HTTP-Protokolls übertragen. In der Version 1.1 können mehrere Anfragen an einen Server gestellt werden, ohne dass zuvor auf eine Antwort gewartet werden muss. Dieses Verfahren nennt sich Pipelining. Dadurch wird die Ladezeit der einzelnen Seiten verkürzt, da mehrere Inhalte gleichzeitig empfangen werden. Dies macht natürlich nur Sinn, wenn man über eine vernünftige Bandbreite verfügt. Nicht alle Web-Server unterstützen das HTTP-Protokoll in der Version 1.1 bzw. Pipelining. Im ungünstigsten Fall bekommt man Probleme bei der Anzeige gewünschter Seiten.

Folgende Einstellungen können in der Firefox-Konfiguration vorgenommen werden und sind nach einem Neustart aktiv:

network.http.keep-alive  = true
network.http.version = 1.1
network.http.pipelining = true
network.http.pipelining.firstrequest = true
network.http.pipelining.maxrequests = 10

PlugIn

Man kann sich nun die Mühe machen und all diese Einstellungen von Hand in die Konfiguration des Browsers eintippen, oder aber einfach ein entsprechendes PlugIn wie z.B. Fasterfox bzw. CacheStatus installieren. Hier können unter anderem die hier beschriebenen Einstellungen einfach vorgenommen werden.