In vielen unserer Artikel kommen Code-Beispiele vor. Damit diese Code-Schnipsel auch richtig dargestellt werden, muss man WordPress ein paar Anweisungen mitgeben. Sonst werden die Code-Beispiele nämlich gnadenlos entfernt. Wo gestern noch ein PHP-Beispiel stand, gähnt morgen ein Loch im Artikel.

Aber was passiert da eigentlich? WordPress bewertet alles, was ganz bestimmte Sonderzeichen enthält – wie z.B. die spitzen Klammern – als „ausführbaren“ Code. Und der hat in einem Text nichts zu suchen. Potenziell ist so ein Code nämlich gefährlich, könnte er doch Malware und ähnlich finstere Dinge enthalten. WordPress reagiert jedenfalls damit, dass es solche Code-Zeilen ganz oder in Teilen löscht.

Das code-Tag

Nun gibt es zwar ein HTML-Tag, um Code darzustellen, das Tag code. Das funktioniert aber nur innerhalb einer Textzeile. Es hat damit dieselbe Funktionalität wie ein code-Tag.
Will man einen ganzen Block mit einem Code-Beispiel darstellen, kommt man mit code nicht weiter.

Um das Problem zu lösen, haben wir hier im Blog mit verschiedenen PlugIns gearbeitet, die unter dem Stichwort Syntax Highlighting zu finden sind. Die PlugIns stellen Code-Beispiele in bunten Farben dar – was der Übersichtlichkeit dienen soll. Ein Nebeneffekt ist, dass der Inhalt von WordPress nicht glattgebügelt wird.

Zumindest theoretisch ist das so. In der Praxis ist es uns regelmäßig passiert, dass plötzlich ein Code-Schnipsel einfach verschwunden ist. Weil WordPress wieder mal heimlich aufgeräumt.

Kommt dazu, dass man leicht mit den Notations-Konventionen durcheinander kommt, wenn man verschiedene Syntax Highlighter ausprobiert. Jedes Codebeispiel muss in die richtigen Tags eingebettet werden und dafür erfindet jedes PlugIn seine eigenen Regeln.
Bringt man die durcheinander oder übersieht einen Artikel beim Wechsel auf ein anderes PlugIn, sieht man früher oder später wieder Fehler und Löcher.

Brauchen wir bunte Farben?

Nachdem eine Kontrolle älterer Artikel wieder alle möglichen Lücken zu Tage gebracht hatte und wir die PlugIns (fast) alle durchprobiert hatten, haben wir eine Alternative gesucht.

Die lag näher als gedacht. Zunächst mussten wir uns aber klar werden, wo das Problem eigentlich lag. Wir brauchten eine Lösung für das Glattbügeln von Sonderzeichen – die farbige Darstellung des Codes ist dabei völlig nebensächlich. Es ging uns folglich gar nicht um das „Syntax Highlighting“!

Die Lösung: Das gute, alte pre-Tag

Das pre-Tag bezeichnet eigentlich einen preformatted text. Das heißt, dass der Text innerhalb der Tags in einer monospaced Schrift (z.B. Courier) dargestellt wird. In solchen Schriften haben alle Buchstaben dieselben Abstände und sie sehen aus wie mit Schreibmaschine geschrieben.

Dieses Tag braucht man beim Texteschreiben kaum bis gar nicht, deshalb eignet es sich sehr gut als Hilfsmittel zur Code-Darstellung. Allerdings würde es nicht ausreichen, einen Code-Schnipsel einfach zwischen pre-Tags zu setzen. Sonder- und Steuerzeichen würden weiterhin umgeschrieben.

Wir brauchen noch eine Anweisung für WordPress, wie es mit Sonderzeichen innerhalb von pre-Tags umgehen soll.
Den passenden PHP-Schnipsel dafür habe ich bei Sergej Müller’s Playground gefunden. In die functions.php kopiert, stellt das pre-Tag jetzt brav alle Bestandteile des Codes dar.

function pre_esc_html($content) {
  return preg_replace_callback(
    '#()(.*?)(;
)#imsu',
create_function(
'$i',
'return $i[1].esc_html($i[2]).$i[3];'
),
$content
);
}

add_filter(
'the_content',
'pre_esc_html'
);

Bis jetzt funktioniert’s.

pre-Tag per CSS stylen

Damit die Code-Beispiele ein passendes Aussehen bekommen, kann man sie mit CSS in Form bringen. Hier im Blog sieht die CSS-Anweisung so aus:

pre {
padding: 15px 15px 15px 20px;
border: 2px solid #d7ebf1;
border-top: 20px solid #d7ebf1;
overflow: auto;
margin: 5px 0 10px 0;
width: 90%;
color: #337198;
font: 90% Courier, Monospace;
background-color: #edf6f9;
display: block;
-moz-border-radius: 10px;
-webkit-border-radius: 10px;
border-radius: 10px;
-khtml-border-radius: 10px;
}

Ein kleiner Nachteil dieser Methode ist, dass man in den HTML-Modus des Editors wechseln muss, wenn man die pre-Tags einbauen möchte.
Mich persönlich stört das aber nicht.