Syntaxhighlighting im RTE
Ich habe mich heute etwas mit der Extension tp_syntaxhighlighting und deren Verwendung im RTE beschäftigt. Zweck der Extension ist die formatierte Darstellung von Programmcode im Frontend.
Dafür verwendet die Extension das neu eingeführte Tag code, mit dem der Programmcode im Text eingeschlossen wird. Im Gegensatz zu ähnlichen Erweiterungen, die dafür spezielle Inhaltselemente verwenden, kann man mit tp_syntaxhighlighting also Quellcode auch im normalen Fließtext einbauen.
Der Einsatz ist dabei recht unkompliziert, wenn man den RTE abschaltet. Falls man allerdings wie ich den RTE verwenden möchte, gerät man in die Mühlen der HTML-Transformation. Zunächst habe ich den RTE so eingestellt, daß er das neue Tag code überhaupt erstmal akzeptiert. Das macht man am besten im TS-Config der Rootseite:
RTE.default.proc.allowTags := addToList(code)
Nun hat aber der RTE die Angewohnheit alle Zeilen, mit einem p-Tag zu umrahmen. Um dies zu verhindern, kann man das code-Tag noch als Outside-Tag eintragen:
RTE.default.proc.allowTagsOutside := addToList(div, code)
Soweit so schlecht, es funktioniert nämlich immer noch nicht. Die Outside-Tags gelten nämlich immer nur für ein Zeile.
<code>class Test { function foo(){ echo \'Hello world!\';}}</code>
ergibt also
class Test { function foo(){ echo \'Hello world!\';}}
Sobald man den Code auf mehrere Zeilen verteilt (und das ist für eine sinnvolle Darstellung von Quelltext ja notwendig), schließt der RTE das code-Tag automatisch am Ende der ersten Zeile.
Sehr nervig, aber natürlich noch kein Grund aufzugeben. Beim Studium von allen mögliche RTE-Konfigurationen, die ich im Netz finden konnte, bin ich auf das Tag blockquote aufmerksam geworden. Dieses erfüllt nämlich genau meine Anforderungen, weil es auch bei Zeilenumbrüchen im Inhalt korrekt erhalten bleibt. Dieses Verhalten wird aber leider nicht durch die Konfiguration des RTE erreicht, sondern durch eine Sonderbehandlung des Tags im Quelltext.
Da ich blockquote aber normalerweise nicht benötige, wollte ich es einfach als code-Ersatz verwenden. tp_syntaxhighlighting konnte ich ja schnell per TypoScript so umbiegen, daß es in Zukunft bei blockquote aufgerufen wurde:
tt_content.text.20.parseFunc.tags.blockquote = < plugin.tx_tpsyntaxhighlighting_pi1
# Blockquote normal behandeln
lib.parseFunc_RTE.externalBlocks.blockquote >
lib.parseFunc_RTE.externalBlocks = table, ol,ul
Die beiden letzten Anweisungen sind notwendig, damit blockquote beim FE-Rendering nicht mehr als external Block behandelt wird.
Nun musste ich nur noch dafür sorgen, daß blockquote in Zukunft auch das Attribut tag akzeptiert. Dafür sollte eigentlich folgende Anweisung in der Page-TS ausreichen:
RTE.default.proc.HTMLparser_db.noAttrib = br
Mit dieser Anweisung wird festgelegt, daß lediglich dem br-Tag keine Attribute mehr zugewiesen werden dürfen. Es ist sehr wichtig diese Anweisung einzubauen, da ansonsten die folgende Standard-Liste verwendet wird: b,i,u,br,center,hr,sub,sup,strong,em,li,ul,ol,blockquote,strike
Aber trotzdem hat der RTE mein Attribut nicht in der Datenbank abgelegt. Also habe ich mit die HTML-Transformation in der Richtung RTE > Datenbank mal im Quelltext von TYPO3 angesehen. Und schließlich wurde ich in der Funktion TS_transform_db der Klasse t3lib_parsehtml_proc fündig:
switch($tagName) {
case \'blockquote\':
// Keep blockquotes, but clean the inside recursively in the same manner as the main code
$blockSplit[$k]=\'<\'.$tagName.\'>\'.$this->TS_transform_db(
$this->removeFirstAndLastTag($blockSplit[$k]),$css).\'\'.$lastBR;
break;
Toll! Da kann man sich zu Tode konfigurieren, wenn hier die Attribute einfach ignoriert werden. Um dieses Verhalten zu korrigieren, hatte ich generell drei Möglichkeiten:
1. direkte Korrektur der Klasse t3lib_parsehtml_proc
2. Überschreiben der Klasse mit dem XCLASS-Mechanismus
3. Korrektur der Transformation css_transform
Die erste Möglichkeit ist natürlich unsinnig, da sie beim nächsten Update von TYPO3 im Nirvana landet. XCLASS wäre eine Möglichkeit gewesen, da allerdings in der doc_core_api von TYPO3 der dritte Weg recht ausführlich beschrieben ist, habe ich mich dafür entschieden.
Also schnell ein neue Extension angelegt und die Funktion TS_transform_db neu implementiert.
Wie man sehen kann, war diese Änderung dann von Erfolg gekrönt. Zwar kann ich Quellcode im RTE auch jetzt nur in der HTML-Quelltext-Ansicht sinnvoll editieren, aber das ist für mich durchaus akzeptabel. Den restlichen Text kann ich ja weiterhin normal bearbeiten.