nicht angemeldet
Typo3 (überschreiben der css_styled_content Konfigurationsdatei)
Hallo,
hatte jetzt fast drei Monate keine Zeit mich mit Typo3 zu beschäftigen. Vor drei Monaten habe ich folgende Typo-Script Textzeilen erstellt. Kann leider nicht mehr ganz nachvollziehen was sie bedeuten und noch viel weniger wie ich auf die Zeilen gekommen bin:
lib.parseFunc_RTE.nonTypoTagStdWrap
encapsLines.encapsTagList := addToList(address, a)
HTMLparser = 1
HTMLparser {
tags.b.remap = strong
tags.i.remap = em
}
}
deshalb ein paar Fragen dazu:
1.)
Welchen Sinn hat die zweite Zeile? Trotz testen komme ich leider nichtmehr drauf.
2.)
Welchen Sinn hat die Zeile 3 bzw. woher warum muß ich HTMLparser auf 1 setzen. Wie kommt man überhaupt darauf?
3.)
Die grobe Bedeutung von den Zeilen 4-6 ist mir klar. Die Schalftflächen B bzw. I des RTE werden auf strong bzw. em gemappt, so dass semantisch einwandfreier Code von der Extension css_styled_content erstellt wird. Ich kann allerdings leider nichtmehr nachvollziehen wie ich auf diese Zeilen gekommen bin. der ganze Kram ist ja leider nicht in der TScript-Referenz zu finden. Könnt ihr mir hier nochmal auf die Sprünge helfen?
-
1.)
Welchen Sinn hat die zweite Zeile? Trotz testen komme ich leider nichtmehr drauf.encapsLines sind Elemente die "Zeilen" einschließen können. Üblicherweise <p />-Elemente
In der Standardkonfiguration sorgt TYPO3 dafür (bzw die RTE-Erweiterung), dass <address /> von <p />-Elementen eingeschlossen wird - was natürlich nicht sein darf.
Mit dieser Zeile fügst du das <address />-Element der Liste der "ich kann eine Zeile einschließen"-Elemente hinzu. Irgendwo gibts noch einen Switch der besagt, dass bereits eingeschlossene "Zeilen" nicht mehr erneut umschlossen werden.
2.)
Welchen Sinn hat die Zeile 3 bzw. woher warum muß ich HTMLparser auf 1 setzen. Wie kommt man überhaupt darauf?das wird üblicherweise nur gebraucht wenn du den HTMLparser einschalten willst, wo er normalerweise nicht läuft - z.B. wenn du ihn auf die stdWrap-Eigenschaft anwendest
3.)
Die grobe Bedeutung von den Zeilen 4-6 ist mir klar. Die Schalftflächen B bzw. I des RTE werden auf strong bzw. em gemappt, so dass semantisch einwandfreier Code von der Extension css_styled_content erstellt wird. Ich kann allerdings leider nichtmehr nachvollziehen wie ich auf diese Zeilen gekommen bin. der ganze Kram ist ja leider nicht in der TScript-Referenz zu finden. Könnt ihr mir hier nochmal auf die Sprünge helfen?Folgendes ins TypoScript-Setup:
class="bodytext" in den <p />-Elementen entfernen
lib.parseFunc_RTE.nonTypoTagStdWrap.encapsLines.addAttributes.P.class >
<p />-Elemente aus Tabellen entfernen
lib.parseFunc_RTE.externalBlocks.table.HTMLtableCells.default >
lib.parseFunc_RTE.externalBlocks.table.HTMLtableCells.default.stdWrap.parseFunc =< lib.parseFuncVerhindern, dass Block-Elemente in <p />-Elemente gewrappt werden
lib.parseFunc_RTE.externalBlocks = hr,ul,ol,table,address
lib.parseFunc_RTE {
externalBlocks.address {
stripNL = 1
stdWrap.parseFunc = < lib.parseFunc
}
}Und das hier ins TSConfig der Wurzelseite
Das stellt das eigentliche remapping von i -> em bzw b -> strong dar. Wichtig ist dass man für sowas nur den Exit-Parser verwendet, die Daten in der Datenbank sollen brav so bleiben wie sie der RTE schreibt.
RTE.default {
proc {
exitHTMLparser_db = 1
exitHTMLparser_db {
tags.b.remap = strong
tags.i.remap = em
}
}
}Prinzipiell hab' ich nicht viel mehr zur Codebereinigung im einsatz - ausser natürlich ein etwas modifiziertes css_styled_content damit nicht so viel Schrott-Code (aka div-Suppe) daherkommt, den keiner braucht.
-
das wird üblicherweise nur gebraucht wenn du den HTMLparser einschalten willst, wo er normalerweise nicht läuft - z.B. wenn du ihn auf die stdWrap-Eigenschaft anwendest
Nachtrag:
xhtml_cleaning = all läuft z.B. auch über den HTMLparser, oder htmlspecialchars - das ist natürlich schon sinnvoll.
Der parser läuft aber über die fertiggerenderte Seite - nicht nur über den Inhalt.
Zu finden ist das Zeug unter class.t3lib_parsehtml.php - aber ich trau dem nicht, die hälfte der Funktionen ist experimentell oder noch nicht fertig bzw. schlichtweg fehlerhaft :)
-
zu 1.)
Ok, verstanden habe ich die zweite Zeile jetzt. Das Problem ist, ich weiß nicht was das Vorgehen ist um auf diese Zeile zu kommen. Mal angenommen mich würde stören, dass das <adress>irgendwas</adress> von p-Tags umschlossen wird. Ich will nun irgendwie erreichen, dass dies zukünftig nichtmehr der Fall ist.
lib.parseFunc_RTE.nonTypoTagStdWrap
{
encapsLines.encapsTagList := addToList(address, a)
}fällt mir ja nicht einfach so ein. Was wäre denn das systematische Vorgehen umd diese Zeile herauszufinden. Muß ich dazu im Quellcode irgendwelcher Konfigurationsdateien rumwühlen?
zu 2.)
Ohje, dass verwirrt mich jetzt vollends. Aus irgendeinem Grund ist ja die Zeile „HTMLparser = 1“ notwendig. Die Frage ist was würde falsch laufen, wenn ich diese Zeile weglassen würde bzw. wie komme ich überhaupt darauf das ich das syntaktisch genauso schreiben muss.
zu 3.)
Hierzu habe ich dann auch wieder ein paar Fragen. Zunächst zu diesen Zeilen:
<p />-Elemente aus Tabellen entfernen
lib.parseFunc_RTE.externalBlocks.table.HTMLtableCells.default >
lib.parseFunc_RTE.externalBlocks.table.HTMLtableCells.default.stdWrap.parseFunc =< lib.parseFuncZunächstmal habe ich in meinem RTE dafür gesorgt, dass der Redakteur keine Tabellen einfügen kann, demnach sind diese Zeilen für meine RTE-Konfiguration doch eigentlich überflüssig oder?
Die erste Zeile
lib.parseFunc_RTE.externalBlocks.table.HTMLtableCells.default >
und wie du darauf gekommen bist ist mir noch halbwegs klar. Mit der zweiten Zeile hab ich allerdings so meine Probleme. Was genau bewirkt die zweite Zeile
lib.parseFunc_RTE.externalBlocks.table.HTMLtableCells.default.stdWrap.parseFunc =< lib.parseFunc
und wie bist du darauf bekommen? Wäre super wenn du das kurz beschreiben kannst. Ich will ja zukünftig auch selbst dazu in der Lage sein Lösungen für solche Probleme zu finden.
Die Zeilen
Verhindern, dass Block-Elemente in <p />-Elemente gewrappt werden
lib.parseFunc_RTE.externalBlocks = hr,ul,ol,table,address
lib.parseFunc_RTE {
externalBlocks.address {
stripNL = 1
stdWrap.parseFunc = < lib.parseFunc
}sagen mir wieder garnichts. Du schreibst mit diesen Zeilen verhindere ich, dass Block-Elemente in <p/>-Elemente gewrappt werden. Ich hab diese Zeilen nicht in meinem Typo-Script Setup und trotzdem wird da nix gewrappt. Wenn ich z.B. eine Zeile als Adresse auszeichne, dann wird die so im Quellcode angezeigt:
<address>ich bin eine Adress</address>
Das ist doch auch ohne die Zeilen oben richtig. Kann leidern nicht nachvollziehen was diese Zeilen bewirken.
Zu dem Mappen auch wieder eine Frage. Das mappen hab ich nicht über das TSConfig der Wurzelseite sondern über das TypoScript-Setup umgesetzt. Dazu habe ich diese Zeilen verwendet:
lib.parseFunc_RTE.nonTypoTagStdWrap {
HTMLparser = 1
HTMLparser {
tags.b.remap = strong
tags.i.remap = em
}
}Warum ist denn Deine Lösung meiner vorzuziehen (warum über TSConfig und nicht über TypoScript-Setup), und was ist überhaupt ein EXIT-Parser. Schlussendlich wieder die Frage, wie kommt du auf diese Zeilen, war das ein göttliche Eingebung oder hast du in irgendwelchen Referenzen bzw. Konfigurationsdateien nachgeschaut. Wäre super wenn du mir das auch noch erklären könntest, dann schaffe ich es vielleicht in Zukunft selbst dahinter zu kommen.
-
Was wäre denn das systematische Vorgehen umd diese Zeile herauszufinden.
Der TypoScript Obkect Browser ist eine gute Wahl, die statischen Templates (setup und constants) der ggf. betroffenen Extensions - oder simpel Google.
Das ist einfach in-deep - wenn du in einem Dokument verhindern willst, dass die Schriftfarbe blau ist, können auch verschiedene stellen dafür verantwortlich sein. Ein font-Tag im HTML, ein style-Attribut, ein ausgelagertes Stylesheet ...
Die herangehensweise lässt sich daher nicht so schlüssig beschreiben.
Ohje, dass verwirrt mich jetzt vollends. Aus irgendeinem Grund ist ja die Zeile „HTMLparser = 1“ notwendig. Die Frage ist was würde falsch laufen, wenn ich diese Zeile weglassen würde bzw. wie komme ich überhaupt darauf das ich das syntaktisch genauso schreiben muss.
afaik nichts, da der HTML-Parser dokumentenweit ohnehin eingeschaltet ist - imho ist das aber die "falsche" stelle weil man das system mit etwas belastet, was nicht sein müsste. Der Code des HTML-Templates ist vorgegeben, diesen nochmal durch den HTML-Parser zu jagen ist unsinnig - es reicht den vom Benutzer wartbaren Text zu parsen.
Zunächstmal habe ich in meinem RTE dafür gesorgt, dass der Redakteur keine Tabellen einfügen kann, demnach sind diese Zeilen für meine RTE-Konfiguration doch eigentlich überflüssig oder?
Ja - aber es schadet nicht, wenn sie drinbehältst - selbstredend kommentiert, damit du auch später weißt warum.
lib.parseFunc_RTE.externalBlocks.table.HTMLtableCells.default.stdWrap.parseFunc =< lib.parseFunc
sie Referenziert lib.parseFunc in genau diesen wrap hinein.
und wie bist du darauf bekommen?
Google um "in die nähe zu kommen", ums vernünftig hinzubekommen: herumgraben im TypoScript bzw. im Quellcode bzw. durch trial & error oder anpassener ähnlicher Beispiele oder Codeschnipsel.
In diesem speziellen Fall (Tabellenzellen ohne P) ein Bugnote im TYPO3-Bugtracker.
Das ist doch auch ohne die Zeilen oben richtig. Kann leidern nicht nachvollziehen was diese Zeilen bewirken.
Kommt auf die TYPO3-Version an - in älteren Versionen ist es nicht selbstverständlich :)
Warum ist denn Deine Lösung meiner vorzuziehen (warum über TSConfig und nicht über TypoScript-Setup), und was ist überhaupt ein EXIT-Parser.
Der HTML-Parser geht über das komplette Dokument welches von TYPO3 generiert wurde. Der Exit-Parser behandelt nur die Dinge die durch ein CONTENT-Objekt aus der Datenbank geholt wurden (und den Parser verwenden - man kann auch ein renderObj ohne Parser erstellen und den "Quelltext" ausgeben lassen - sprich 1:1 den Inhalt des bodytext-Feldes aus der tt_content-Tabelle).
Wenn du also genötigt bist, irgendwo in deinem Template <b>foo</b> stehen zu haben, wird der HTML-Parser das ersetzen, der Parser des RTE aber nicht.
Im Falle von b und i spielt das aber keine Rolle.
-
Kurz noch ne Frage zu dem Mappen von <i> und <b>. Ich hab leider immernoch nicht verstanden warum ich das besser so wie du über TSConfig als so wie ich über das TypocScript-Setup machen.
-
Kurz noch ne Frage zu dem Mappen von <i> und <b>. Ich hab leider immernoch nicht verstanden warum ich das besser so wie du über TSConfig als so wie ich über das TypocScript-Setup machen.
Prinzipiell ist es egal wo du es machst - nur solltest du dabei nicht unnötig viel Zeug parsen :)
Der TSConfig-Schnipsel parst NUR die Ausgabe des RTE (oder Dinge die dessen Parser nutzen), der HTML-Parser (page.config.HTMLparser = 1) wird über das komplette Dokument gejagt.
-
Der TSConfig-Schnipsel parst NUR die Ausgabe des RTE (oder Dinge die dessen Parser nutzen), der HTML-Parser (page.config.HTMLparser = 1) wird über das komplette Dokument gejagt.
Ist das so tragisch, wenn das komplette Dokument geparst wird? Wo liegen denn da die Nachteile?
-
Ist das so tragisch, wenn das komplette Dokument geparst wird? Wo liegen denn da die Nachteile?
Es kostet mehr Rechenleistung als nur einen Teil zu parsen - bei einer kleinen Seite spielt das aber keine Rolle.
-
-
-
-
-
-