WordPress Syntax Highlighting Plugin – Vergleich

Für das Syntax Highlighting in WordPress gibt es eine ganze Reihe Plugins. Etliche Projekte sind allerdings seit geraumer Zeit eingestellt und erfahren keine Weiterentwicklung mehr. Ein Syntax Highlighting Plugin das noch betreut wird, ist „WP-Syntax„. Dieses bietet Highlighting per GeSHi (Generic Syntax Highlighter) und somit für ca. 200 Sprachen. Darunter natürlich auch die typischen Websprachen wie PHP, MySQL, HTML, CSS & Javascript.

WordPress Syntax Highlighting mit „WP-Syntax“

Nach dem Aktivieren des Plugins werden <pre>-Blöcke mit einem lang-Attribut und einem optionalen line-Attribut mit dem Syntax Highlighter farbig gekennzeichnet.

Dazu ein kleines PHP-Beispiel:

84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
/**
 * Builds an array containing the supported actions.
 * @return array
 */
function getSupportedActions() {
  $actions = array();
  $dirHandler = opendir('examples');
  while ($actionFile = readdir($dirHandler)) {
    if (preg_match('/.php$/', $actionFile)) {
      $action = preg_replace('/.php$/', '', $actionFile);
      $actions[] = $action;
    }
  }
  closedir($dirHandler);
  return $actions;
}

Wie zu sehen muss die Zeilennummern nicht bei 1 beginnen, sondern können angepasst werden. Die zur obigen Einbindung notwendige Code sieht so aus:

<pre lang="PHP" line="84">
...CODE...
</pre>

Die Angabe von line=“84″ lässt also die Zählung erst bei 84 losgehen. Ein kleiner Zusatztipp noch: wenn es sich um bereits mit escapeten HTML Entities versehenen Code handelt, dann hilft die Option escaped=“true“ weiter:

<pre lang="xml" escaped="true">
&lt;xml&gt;Hello&lt;/xml&gt;
</pre>

Damit erfüllt das Plugin (für mich) alle an einen Syntax Highlighter für WordPress gestellten Anforderungen und ermöglicht komfortables Syntax-Highlighting unter Benutzung des visuellen Editors im Backend (lediglich zur Eingabe der Attribut-Parameter muss kurz auf den HTML-Modus umgeschaltet werden. Aber wer im eigenen Blog Syntax-Hilighting benötigt, der wird damit auch kein Problem haben… ;-)

SyntaxHighlighter Evolve

Ein weiteres Plugin zum Syntax-Hilighting (das auch auf WordPress.com verwendet wird) ist „SyntaxHighlighter Evolve“ (Infos – gefunden hier). Der Plugin-Macher weist jedoch in der Beschreibung des Plugins in der Plugin-Übersicht darauf hin, dass der Code unter Umständen vom vistuellen Editor (TinyMCE) verunstaltet bzw. „gefressen“ wird:

TIP: Don’t use the Visual editor if you don’t want your code mangled. TinyMCE will „clean up“ your HTML.

Hier trotzdem ein Versuch mit dem Plugin:

[sourcecode lang=“php“ firstline=“84″]/**
* Builds an array containing the supported actions.
* @return array
*/
function getSupportedActions() {
$actions = array();
$dirHandler = opendir(‚examples‘);
while ($actionFile = readdir($dirHandler)) {
if (preg_match(‚/.php$/‘, $actionFile)) {
$action = preg_replace(‚/.php$/‘, “, $actionFile);
$actions[] = $action;
}
}
closedir($dirHandler);
return $actions;
}[/sourcecode]

Hier nochmal als Bild, falls ich das Plugin später deaktiviere:

SyntaxHighlighter Evolve - PHP-Code
SyntaxHighlighter Evolve – PHP-Code

Das scheint auch ganz ordentlich zu funktionierten – und noch eins mit HTML:

[sourcecode lang=“html“]<pre lang=“PHP“ line=“84″>
…CODE…
</pre>[/sourcecode]

Hier auch nochmal als Bild, falls das Plugin später abgeschaltet wird:

SyntaxHighlighter Evolve - HTML-Code
SyntaxHighlighter Evolve – HTML-Code

Es funktioniert also offenbar auch reibungslos und zumindest bei meinen Tests wurde der HTML-Code nicht von TinyMCE durcheinandergebracht. Das soll ein TinyMCE-Plugin erledigen, das auch im Backend eine Art Code-Ansicht für die in eckigen Klammern stehenden Code-Snippets verursacht. Möglicherweise ist der Hinweis noch ein Überbleibsel aus einer älteren Version und die Funktionalität wurde mittlerweile optimiert.

Performance-Unterschiede

Eine weiteres Entscheidungs-Kriterium könnte die Performance sein. Beim „SyntaxHighligher Evolve“ werden externe JavaScript-Dateien nachgeladen (insgesamt ca. 32 kByte) und JavaScript-Code direkt in den Quelltext der Seite eingebunden. Dies geschieht jedoch nur dann, wenn auch Syntax-Highlighting im Artikel verwendet wird (soweit schon mal vorbildlich).

Beim „WP-Syntax“ wird lediglich eine externe CSS-Datei von ca. 2.1 kByte eingebunden. Das passiert jedoch unabhängig davon, ob auch Code-Beispiele im Artikel verwendet werden. Die verwendeten CSS-Regeln könnten jedoch auch in das Haupt-CSS-File übernommen werden, um so einen zusätzlichen Request zu vermeiden. Das eigentliche Syntax-Highlighting wird mit PHP-Bibliotheken erledigt. Das erzeugt zwar mehr Last auf dem Server, was sich jedoch durch Server-Caching weitgehend vermeiden lässt.

Favorit: WP-Syntax

Auch wenn das quasi „offizielle“ Plugin für diese Zwecke der „SyntaxHighligher Evolve“ ist (wird auch von Automattic auf wordpress.com verwendet), gefällt mir das Plugin „WP-Syntax“ besser, da es dank der Escaped-Option mit so ziemlich allem klarkommen sollte und auch nach Deaktivieren des Plugins keine Probleme mit dem Code beim Bearbeiten im visuellen Editor zu erwarten sind (nur das Syntax-Highlighting im Frontend würde fehlen).

Beim „SyntaxHighligher Evolve“ sind nach dem Deaktivieren durchaus Veränderungen an den Code-Beispielen wahrscheinlich, sollte der Artikel erneut bearbeitet werden, weil dann das Plugin fehlt, das dies verhindert.

Zur WP-Syntax Plugin-Seite »

Schreibe einen Kommentar