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)

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.

Mit mehr als 90.000 Accounts und 4,5 Milliarden ausgelieferten Bildchen zum letzten Jahr wird deutlich, dass die kleinen Hingucker sich großer Beliebtheit erfreuen. Im Februar 2007 gab es das Rollout der neuen Version “Gravatar 2″. Man erhoffte sich hier in erster Linie ein Geschwindigkeitsanstieg, doch zeigte sich bald, dass der Service teilweise immer noch sehr langsam ist. Also was tun?

Die Lösung liegt auf der Hand: die Bildchen müssen auf dem eigenen Server zwischengespeichert werden. Diese Aufgabe übernimmt das WordPress-Plugin Gravatars2 von ZenPax. Die Admin-Oberfläche erlaubt es einem unterschiedliche Timeout-Werte zu definieren, sowie den lokalen Cache zu verwalten. Zusätzlich können lokale Avatare als Quelle definiert werden. Ein Cache hat natürlich den Nachteil, dass Änderungen an Inhalten verzögert sichtbar werden, dafür werden die Bildchen aber schnell dargestellt.

Update Jan 2009:
Inzwischen wird Gravatar von den neueren WordPress Versionen native unterstützt.

CSS-Default-Werte

Die einzelnen Browser zeigen einen Inhalt mit unterschiedlichen Vorgabewerten an. Abstände zwischen Absätze und Überschriften, sowie Schriftgrößen weichen leicht voneinander ab, zumindest wenn diese nicht explizit in einem Style-Sheet definiert werden. Um zu vermeiden, dass eine CSS-Definition zur Hälfte mit Normierungswerten bestückt ist, empfiehlt es sich, eine extra Definitionsdatei für das Zurücksetzen aller Werte anzulegen und einzubinden. Hier bieten sich die YUI-CSS-Definitionen von Yahoo (BSD License) zum Zurücksetzen der Abstände (Reset) und Normieren der Schriftgrößen (Font) an. Leider werden hier sogenannte CSS-Browserweichen eingesetzt, was dazu führt, dass das CSS nicht valide ist.

Wem kleine Abweichungen in der Font-Normierung nichts ausmachen, kann von mir das Reset-Style-Sheet “style_reset.css” herunterladen und in seine Projekte einsetzten (BSD License). Der Vorteil dieser Definition besteht darin, dass sie die W3C-CSS-Prüfung besteht (siehe Icon im Fußbereich)! Dieses CSS kann dann mittels @import url('style_reset.css'); am Anfang des jeweiligen Haupt-Style-Sheets eingebunden werden. Danach sollte allerdings darauf geachtet werden, dass alle Schriftgrößen nur noch prozentual angegeben werden. Welche Prozentwerte für welche Größenpixel stehen wird in der CSS-Datei als Kommentar aufgelistet.

CSS-Box-Modell

Leider interpretiert der Microsoft Internet-Explorer 5 / 6 das CSS-Box-Modell eines HTML-Elements mit fester Breitenangabe etwas anders, als es ursprünglich gedacht war. Innerhalb seiner Breite liegen der sichtbare Rahmen (Border), sowie der innere Abstand (Padding) eines Elementes. Dies bedeutet (und dies auch nur sicher, wenn die Breite angegeben wurde), je größer diese beide Parameter sind, um so weniger Platz bleibt für den Inhalt eines Elementes. Der CSS-Standard definiert die Interpretation der Breitenangabe hier anders. Die Breitenangabe gilt dem Inhalt. Rahmen, sowie innerer und äußerer Abstand (Margin) liegen außerhalb dieser Breitenangabe. Man muß sie also zu dieser Angabe addieren, um die komplette Breite zu ermitteln. Welches der beiden Vorgehen intuitiver ist, vor allem auch mit dem Wissen, das die Hintergrundfarbe bzw. das Hintergrundbild auch noch im Padding-Bereich sichtbar ist, sei mal dahingestellt. Die unterschiedlichen Interpretationen des CSS-Box-Modells erschweren das Gestalten einer Webseite bzw. das Erstellen von Wordpress-Themes, welche in der Regel aus einer Kombination mehrerer DIV-Elemente besteht.

Es gibt unterschiedliche Herangehensweisen, um dieses Problem in den Griff zu bekommen. Eine besteht in der Definition unterschiedlicher Breitenangaben, eine für den Internet Explorer und eine für die restlichen Browser. Dies kann mit so genannten CSS-Browserweichen (CSS-Hacks) in einer globalen Style-Sheet-Definition erreicht werden. Da solche CSS-Dateien aber nicht Standardkonform sind und auf Interpretations-Schwächen der einzelnen Browser basieren, ist davon abzuraten. Eine weitere Möglichkeit besteht im Einsatz von Kommentar- bzw. PHP-Browserweichen. Beispiele hierfür findet man in dem Artikel “PNG im Internet Explorer“.

Will man allerdings nicht zwei CSS-Dateien pflegen, gibt es noch eine weitere Herangehensweise. Beide Interpretationen des CSS-Box-Modells haben eins gemeinsam: der äußere Abstand (Margin) liegt wirklich außerhalb der Breitendefinition. Verzichtet man nun auf den Rand (Border) und den inneren Abstand (Padding) komplett (Wert = 0px, oder Einsatz von style_reset.css, s.o.) werden die Angaben von allen Browsern gleich interpretiert. Um nun auch einen inneren Abstand in einem DIV-Element zu realisieren, muss ein weiteres DIV-Element, welches den eigentlichen Inhalt trägt, in dieses gelegt werden. Der Margin-Wert des inneren DIVs entspricht dann dem ursprünglichen Padding-Wert. Jetzt muss noch eine Eigenart der vertikalen Margin-Werte behandelt werden. Wie im CSS 2.1 Standard beschrieben schlägt hier das so genannte Collapsing-Margins zu, was dazu führt, dass der “margin-top” Wert des inneren DIVs gerne komplett ignoriert wird. (Der Internet-Explorer 5/6 hält sich hier nicht an den Standard und ordnet die Elemente wie erwartet an. Er addiert vertikale Margin-Werte grundsätzlich auf, was meist zu unerwünscht größeren Abständen zwischen Elementen führt.) Hier hilft ein Trick, welcher auch aus dem Standard herausgelesen werden kann: Die einzelnen DIVs bekommen eine Overflow-Definition mit einem Wert ungleich “visible”. Da in der Regel kein Text über die DIV-Content-Grenzen hinweg angezeigt werden soll, kann hier die Definition overflow: hidden; eingebunden werden. Auf diese Art und Weise können einheitliche WordPress-Themes mit validen CSS-Definitionen erstellt werden.

BluePrintCSS

Eine schöne Sammlung nutzbarer CSS-Definitionen liefert auch Google mit ihrem BluePrintCSS. Der Schwerpunkt dieses CSS-Frameworks liegt in der Typographie. So wird auch ein Stylesheet für den Druck geliefert. Auch zieht die Idee eines Grid-Layouts aus dem Print-Design-Umfeld in die Stylesheets ein. Dadurch stellt ein Mehrspalten-Layout kein Problem mehr dar. Die Eigenarten des Internet-Explorers wurden hier in einem eigenen Stylesheet sauber getrennt abgelegt.

Damit solche Metadaten für einzelne WordPress-Beiträge individuell angegeben werden können, wird ein sogenanntes WordPress-Plugin benötigt. Ich will hier meine kleine Erweiterung “Easy-HTML-Metadata” vorstellen. Sie reagiert auf zuvor definierte “Benutzerdefinierte Felder” eines Beitrags bzw. einer Seite und gibt dessen Inhalte als Metadaten aus.

Installation

Nach dem Herunterladen der aktuellsten Version dieses Plugins (siehe unten) muss die PHP-Datei aus dem Zip-File in das WordPress-Plugin-Verzeichnis (dies ist meist /wp-content/plugins/) kopiert werden. Hier kann man ggf. auch ein Unterverzeichnis anlegen, um so mehr Überblick über alle Plugins in seiner WordPress-Installation zu erlangen. Danach muss dieses Plugin in der Adminkonsole aktiviert werden.

Einsatz

Jetzt steht dem User unter den Einstellungen ein neuer Menüpunkt “HTML-Metadata” zur Verfügung,  in dem die Standard-Sprache sowie die Namen der benutzerdefinierten Felder definiert werden können (siehe Bild oben rechts). In der Regel bleiben die Feldnamen unverändert. Nun kann man zu jedem Beitrag solche benutzerdefinierten Felder mit angeben. Als Schlüssel werden die zuvor definierten Namen eingesetzt, der Wert ist dann der Inhalt des zugeordneten Meta-Data-Elementes. Im Beispiel links sind die Meta-Angaben dieses Artikels (zum Zeitpunkt der Erstellung) sichtbar. Das Ergebnis der Version 1.2 im HTML-Kopf dieser hier sichtbaren Seite sieht dazu folgendermaßen aus:

<meta name="MBEasyHTMLMetadata" content="1.0" />
<meta name="language" content="de" />
<meta name="content-language" content="de" />
<meta name="description" content="Wordpress-Plugin für inhaltliche HTML-Metaangaben." />
<meta name="keywords" content="Wordpress, Plugin, Metadata, Metadaten, Description, Beschreibung, Keywords, Schlüsselwörter" />
<meta name="author" content="Matthias Brusdeylins" />
<meta name="copyright" content="Copyright by Matthias Brusdeylins. Creative Commons 3.0 license - Some rights reserved." />

Hier ist auch erkennbar, dass automatisch der volle Name des registrierten Autors mit ausgegeben wird. Das Plugin benötigt keine Änderungen an dem installierten WordPress-Theme.

Download

Easy-HTML-Metadata, Version 1.2

Change-Log

Diese Software fällt unter den Lizenzvertrag CC-GNU GPL.