Das Problem

Bei Tabellen, die mit dem RTE erzeugt werden, erscheint im Frontend innerhalb eines jeden <td>-Elements ein <p>-Element, ohne dass dieses im Backend eingegeben wurde. Beispiel: Der Redakteur möchte <td>Zelleninhalt</td>, erhält aber <td><p>Zelleninhalt</p></td>.

Die Transformation wird auch diesmal wieder im Rahmen von lib.parseFunc_RTE  getätigt (siehe css_styled_content/static/setup.txt). Dort heißt es innerhalb des Objektpfads lib.parseFunc_RTE.externalBlocks:

table.HTMLtableCells=1
table.HTMLtableCells {
    default.callRecursive=1
    addChr10BetweenParagraphs=1
}

Das default.callRecursive=1 bewirkt, dass der gesamte Inhalt eines <td>-Elements seinerseits durch lib.parseFunc_RTE geschleust wird. Damit kommt dann aber auch der folgende Objektpfad zum Tragen, der für das unerwünschte <p>-Element verantwortlich ist:

lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines.nonWrappedTag = P

In den einschlägigen Newsgroups und Foren kursieren verschiedene Lösungsansätze, die leider unerwünschte Nebenwirkungen haben. So ist es zum Beispiel fatal, den Inhalt von Tabellenzellen gar nicht zu parsen.

lib.parseFunc_RTE.externalBlocks.table.HTMLtableCells.default.callRecursive = 0

Dieser Eintrag führt unter anderem dazu, dass Links, die Redakteure in die Tabellenzellen eingegeben haben, im Frontend nicht erscheinen.

Eine zweite Variante entfernt radikal alle <p>-Elemente aus Tabellenzellen, also ein Weg, der nur gangbar ist, wenn in keiner Tabelle eines Projekts Absätze benötigt werden.

lib.parseFunc_RTE.externalBlocks.table.stdWrap.HTMLparser.removeTags = p

Eine gute Lösung sollte also den folgenden Anforderungen genügen:

1. Der Inhalt von Tabellenzellen soll durch den Parser laufen.
2. Absätze in Tabellenzellen sollen erlaubt sein.
3. Zeichenketten ohne umgebendes HTML-Element sollen als solche erhalten bleiben.

Die Lösung

Ein Blick in die TSref (Kapitel parseFunc) zeigt, dass HTMLtableCells.default mit stdWrap-Eigenschaften ausgestattet ist. Das gibt uns die Möglichkeit, dem Parser eine speziell auf Tabellenzellen zugeschnittene Konfiguration im Setup-Bereich des Seitentemplates (Info/Modify -> Setup) mitzugeben:

lib.parseFunc_RTE.externalBlocks.table.HTMLtableCells.default >
lib.parseFunc_RTE.externalBlocks.table.HTMLtableCells.default.stdWrap.parseFunc =< lib.parseFunc

Getestet auf TYPO3 4.2.6, htmlArea RTE 1.7.9 Quelle:Datenwolken

Das Problem

Standardmäßig wird jede im RTE erstellte Tabelle auf dem Weg von der Datenbank zum Frontend mit dem Attribut class="contenttable" versehen, und zwar auch dann, wenn im Editor keine oder, schlimmer noch, eine andere Klasse gewählt wurde.

Verantwortlich dafür ist die System Extension css_styled_content, genauer genommen einige Zeilen Code in lib.parseFunc_RTE (Datei css_styled_content/static/setup.txt):

table.stdWrap.HTMLparser.tags.table.fixAttrib.class {
    default = contenttable
    always = 1
    list = contenttable
}

Bei der Interpretation der fraglichen Zeilen hilft das Kapitel HTMLparser_tags aus der TSref weiter.

default = contenttable: Wenn für die Tabelle kein class-Attribut gesetzt ist, fügt der Parser es hinzu und setzt es auf den hier angegebenen Wert. Ergebnis: class="contenttable".

always = 1: Normalerweise würde der Parser das class-Attribut nur auswerten, wenn er es im Code vorfindet. Diese Einstellung sorgt dafür, dass er prüft, ob das class-Attribut überhaupt gesetzt wird; wenn nicht, tritt default = contenttable in Kraft.

list = contenttable: Wenn das Attribut class durch den Author gesetzt wurde, prüft der Parser, ob der Wert contenttable in der Liste der zugewiesenen Klassen enthalten ist. Wenn nicht, setzt er es an erster Stelle ein. Beispiel: Der Autor wollte class="tableStyle1 colorSet2" und erhält am Ende class="contenttable tableStyle1 colorSet2".

Die Lösung

Abhilfe schafft ein TypoScript-Einzeiler im Setup-Bereich des Seitentemplates (Info/Modify -> Setup), der die oben zitierten Standardeinstellungen aus der Parserkonfiguration löscht:

lib.parseFunc_RTE.externalBlocks.table.stdWrap.HTMLparser.tags.table.fixAttrib.class.list >

Getestet auf TYPO3 4.2.6, htmlArea RTE 1.7.9