CSS Tabellen - Frage zum Template Bulettproff

[B.E.A.]

Ich verstehe einfach nicht, warum bei dem Einsatz einer Tabelle plötzlich automatisch Zeilenumbrüche entstehen, die ich nicht gemacht habe. Kann mir einer das bitte für einen CSS-Laien erklären, woran sich das ausrichtet?

Hier zwei Beispiele:

1. Startseite: Tabelle sollte weiter oben stehen http://www.bea-anders.de/alias-beate-eierle/ Warum plötzlich 9x <br> eingefügt werden, versteh ich nicht, denn im Originalcode sind die nicht vorhanden. Wenn ich mir das mit Firebug ansehe, sehr wohl. Warum passiert das?

2. Unterseite: Ganz am Schluss passiert auch hier, das die Tabelle am Seitenende viel zu weit von der darüber liegenden Grafik abwärts steht. Auch hier werden <br> gesetzt, die ich nicht im Originalcode habe. http://www.bea-anders.de/alias-beate-ei ... rafie.html

Ich bin gespannt woran das liegt und danke euch für sachdienliche Hinweise

[bernd_d]

Du benutzt vermutlich das Plugin NL2BR, oder?

[Timbalu]

...und möchtest wissen wie man damit umgeht? Dann lese bitte
'NL2BR - "Eine kleine Geschichte des Umbruches" - mit Lösungsansätzen'.
http://board.s9y.org/viewtopic.php?f=10 ... #p10432048

[B.E.A.]

Danke für eure Antworten!

@ bernd_d

Ja ich benutzte das Plugin NL2BR, nun nicht mehr und der ganze Spuk ist vorbei Da ich den WYSIWYG Editor ebenfalls nutze konnte ich nie im Editorfenster, wenn ich auf HTML klickte, diese vielen <Br> sehen.

@ Timbalu

Danke für deine Antwort und den Link. Habe ich gelesen und so ungefähr verstanden, warum das Problem auftritt. Ich hab jetzt einfach mal Plugin NL2BR auf inaktiv gesetzt und alles ist zunächst gut. Habe aber noch Fragen.

1. Kann das Plugin NL2BR inaktiv bleiben, oder hat es evtl. Konsequenzen bei anderen Browsern?
2. Wieso passieren diese Verschiebung nur bei Tabellen und Bildern und nicht im Fließtext?
3. Wenn ich das richtig verstanden habe, sind der WYSIWYG-Editor und das Plugin NL2BR nicht kompatibel?
4. Die kleine Geschichte zum Umbruch habe ich gelesen und stolpere gerade über das Entryproperties Plugin. Muss ich das installieren, wenn Plugin NL2BR inaktiv ist?

[Timbalu]

Habe ich gelesen und so ungefähr verstanden, warum das Problem auftritt. Ich hab jetzt einfach mal Plugin NL2BR auf inaktiv gesetzt und alles ist zunächst gut.

D.A.S ist grundsätzlich nicht die Absicht des Verfassers!!!!!! Er ist nun der Ansicht, dass du ihn eventuell doch nicht recht verstanden hast, denn deine Reaktion entspricht so ungefähr dem genauen Gegenteil seiner Absicht! (Und zwingt ihn fast noch einmal so viel zu schreiben!)

1. Kann das Plugin NL2BR inaktiv bleiben, oder hat es evtl. Konsequenzen bei anderen Browsern?
2. Wieso passieren diese Verschiebung nur bei Tabellen und Bildern und nicht im Fließtext?
3. Wenn ich das richtig verstanden habe, sind der WYSIWYG-Editor und das Plugin NL2BR nicht kompatibel?
4. Die kleine Geschichte zum Umbruch habe ich gelesen und stolpere gerade über das Entryproperties Plugin. Muss ich das installieren, wenn Plugin NL2BR inaktiv ist?

• 1. Nein und Nein. Es hat aber Konsequenzen zB für Kommentare oder andere Eingabefelder!
• 2. Das stimmt so nicht. Sie passieren immer wenn ein verstecktes \n im Text steht, weil irgend jemand die ENTER-Taste drückte. Egal wo du den Text oder das HTML-Markup geschrieben oder her kopiert hast, ENTER-Zeilenumbrüche sind als verstecktes "Steuerzeichen" \n (linux) oder \r\n (win) immer enthalten. (Die Ausnahmen dieser Regel sind in diesem Zusammenhang nicht wichtig.)
• 3. Nein, das stimmt so auch nicht. Sie gehen sich einfach aus dem Weg. Es gibt seit längerem keinen Grund mehr, das NL2BR Plugin für einen eingesetzten WYSIWYG-Editor zu deaktivieren. Jedenfalls nicht für ein aktuell abzuspeicherndes Entry (s.u.).
• 4. Nein, im Zusammenhang mit NL2BR nur, wenn du, wie beschrieben, einen ganzen Blogeintrag (bequem) für das NL2BR parsing deaktivieren willst. Für Teilbereiche gibt es ja den schönen NoBR-Knopf (oder die NL2P Einstellung).

Wenn du eine Tabelle so schreibst:

Code: Select all

Hallo ich bin ein Text
<table>
    <tr>
        <td>eine Zelle</td>
        <td>zweite Zelle</td>
    </tr>
</table>
und ich berge manche Geheimnisse...
in meinem Innern

hast du mindestens acht ENTER-Teilenumbrüche per \n eingebaut. Serendipity speichert das genau so in der Datenbank (bei cache auch schon umgewandelt) und setzt es bei der Ausgabe für das Frontend so um, dass alle \n zu <br /> konvertiert werden. Daher kommen deine Treppen. Ich meine mich zu erinnern, drei mögliche Lösungsansätze aufgezeigt zu haben.

Das sähe für NoBR dann zB so aus:

Code: Select all

Hallo ich bin ein Text
<nl><table>
    <tr>
        <td>eine Zelle</td>
        <td>zweite Zelle</td>
    </tr>
</table></nl>
und ich berge manche Geheimnisse...
in meinem Innern

Ab jetzt hätte nur noch der Text Zeilenumbrüche (hinter Text<br> und hinter Geheimnisse...<br>). Die PREVIEW zeigt dir auch immer schon die bereits geparsten Ergebnisse.

Andere Lösung:

Code: Select all

Hallo ich bin ein Text<table><tr><td>eine Zelle</td><td>zweite Zelle</td></tr></table>und ich berge manche Geheimnisse...
in meinem Innern

Hier wirst du nur noch ein einziges <br /> finden, obwohl die Tabelle in einer eigenen Reihe dargestellt wird. Wie genau sich das nun bei jedem Einzelnen darstellt, hängt auch immer vom verwendeten Template ab, zb., ob es das table Element als Block-Element definiert, oder nicht, und welche Abstände es am oberen und unteren Rand für dasselbige per Definition enthält.

Setzt du nun einen WYSIWYG Editor ein, so werden alle Einträge in Eingabefelder grundsätzlich nicht mehr von NL2BR durchlaufen! [Für Kommentare ist das blöd!] (*)

Setzt du ein anderes Markup Plugin wie markdown oder textile ein, müssen du und alle Einträgler, also auch Kommentatoren, sowieso eine ganz neue Syntax zur Auszeichnung lernen.

• Wir haben also den PLAIN-TEXT-EDITOR, mit den BBCode Buttons und NL2BR mit all seinen Funktionen.
• Oder wir haben einen WYSIWYG-EDITOR, mit der automatischen Auslassung von NL2BR.
• Oder wir haben andere Markup Plugins, die - ebenso von NL2BR ausgelassen - sich von nun an um die Auszeichnung kümmern. Hier machen eventuelle Verschiebungen bzw Deaktivierungen anderer aktiver Markup Plugins (wie emoticate, 29ymarkup etc) durchaus Sinn. Wie genau, ist eine Frage der individuellen Situation.

Es kommt also immer darauf an. Auch auf die (künftige) Häufigkeit der Verwendung von HTML Markup in Einträgen. Sicher ist dies:

• Ein beliebiges Hin- und Herwechseln der internen Markup-Umwandlung, macht für einen bestehenden Blog keinen Sinn , da es unweigerlich zu Problemen bei der Augabe (mit alten Einträgen und zB auch dem Cache) führen kann. Wenn nicht sofort, dann irgendwann später. Je später man solches merkt, desto größer wird der Korrekturbedarf!

Das ist, wie ich nun verstehe, dein Problem. Oder irre ich mich da? Eine Lösung mit der Deaktivierung von NL2BR vielleicht nur eine vorläufige Notlösung für deine alten Einträge. Besser ware eine klare Konsistenz.

(*) Hat das eigentlich schon mal jemand gemerkt?
Ich werde mir mal Gedanken machen, wie man (wenigstens) den CKEDITOR für Kommentar Textareas eingeschränkt nutzbar macht, oder für Kommentare eine Ausnahme des gegenseitigen "In-Ruhe-Lassens" bewirken kann. Ideas welcome.

[B.E.A.]

@ Timbalu

Ok... OK... ich sollte etwas anderes machen als das Plugin NL2BR abschalten. Kannst du dich neben mich setzen und mir das noch einmal liebevoll beibringen???
Für den Moment hab ich es jetzt einfach mal abgeschaltet, denn es wird als Portfolio keine künftigen neuen Beiträge geben, da ich die gerade alle neu geschrieben habe. Und da es kein Blog vorher war, gibt es auch keine alten Beiträge. Ich muss mich mit diesem Kram erst einmal in Ruhe auseinandersetzen. Noch hab ich das alles nicht so gepeilt.

Formularfelder gibt es auch nicht. Nur ein Kontaktformular. Ich hoffe das es dort keinen Absatzsalat gibt.

Passiert eigentlich was, wenn ich das Plugin NL2BR wieder zuschalte (Datenbank-Salat)??
Der Befehl <nl> was macht der?

Gibbet zufällig einen Serendipityaner im Raum Essen-Düsseldorf mit Ahnung der Lust hat auf Austausch War ja nur eine Frage. Wir könnten ja Serendipity-Stammtische ins Leben rufen...

Jedenfalls danke ich dir Timbalu für deine sehr ausführliche Erklärung... ehrlich... ich weiß es zu schätzen!!

LG Bea

[Timbalu]

Kannst du dich neben mich setzen und mir das noch einmal liebevoll beibringen???

Na, wenn ich das gestern nicht bereits getan habe, was dann?! Hausbesuche kosten extra!

Formularfelder gibt es auch nicht. Nur ein Kontaktformular. Ich hoffe das es dort keinen Absatzsalat gibt.

Ausprobieren! Mit viel ENTER!

Passiert eigentlich was, wenn ich das Plugin NL2BR wieder zuschalte (Datenbank-Salat)??

Wenn du inzwischen keine Einträge geschrieben oder verändert, oder den Cache neu erstellt hast, sollte es keinen Salat geben! Dann bist du einfach am vorherigen Stand. Wenn du nun mit alten Texten einen Blog neu erstellst, solltest du von Anfang an mit dem Editor, entsprechenden Ausnahmen im Text wie bei <nl> etc und Plugin-Markup-Verwandlern arbeiten, die du später auch weiter verwendest.

Der Befehl <nl> was macht der?

Diesen Tag gibt es in HTML nicht. Also wird er von Browsern ignoriert. Aber das NL2BR Plugin erkennt daran, welchen Teil es vom angelieferten Text von der Umwandlung in <br> ausnehmen soll.

[B.E.A.]

So, den Test mit dem Kontaktformular habe ich gemacht. In der erhaltenen Mail ist alles korrekt zu sehen. Absätze sind da wo sie hingehören.

Nun zu meiner Überlegung. Sag mir bitte, ob ich das so machen kann. Ich schalte das NL2BR Plugin wieder zu, weil es ja eigentlich Sinn macht. Da ich immer mit dem WYSIWYG-Editor arbeite, müsste ich nun von Hand, wann immer ich eine Tabelle anlege den Befehl <nl>/</nl> zum Einsatz bringen, damit es keine ungewollten Umbrüche gibt. Richtig?

Und was ist, wenn das NL2BR Plugin irgendwann in der Entwicklung der Programmierung überflüssig würde, oder wird es das nie geben? Laienfrage... dachte ich einfach nur, weil ich etwas voraus dachte und mir gerade durch den Kopf geht, das ich dann alle Einträge mit Tabelle vom <nl> befreien müsste.

Ich habe mal gerade bei meinen anderen Blogs geschaut und stellte fest, das bereits bei 4 Blogs das NL2BR nicht installiert ist. Bis heute sind mir dabei keine komischen Sachen aufgefallen. Hab ich nur Glück gehabt?

Dabei fällt mir ein, das yellowled (Matthias) mir mal dazu geraten hat es abzustellen was ich auch sehr gerne getan habe, um das Problem von der Backe zu bekommen http://board.s9y.org/viewtopic.php?f=10 ... #p10431737

Ich stelle mir allerdings die Frage, wenn es ja bereits bei Installation mit ausgeliefert wird, warum bei der Entwicklung mit dem kombinieren von Editoren, dann nicht direkt eine Lösung mit programmiert wird, um keine unnötigen <br> zu schreiben. Es kann ja nicht Sinn und Zweck sein, den html Code von Hand nachzubessern.

Denke ich da jetzt zu einfach?

Blog-Anfänger kommen dann womöglich nicht damit zurecht. Ich bin ja schon nicht mehr so ganz "anfängerblond" und versuche mich im HTML rein zu denken und zu verstehen, was da so passiert. Hoffe du siehst mir nach, wenn ich dann für Entwickler, oder Profis halt eben meine "Laien" Fragen stelle.

Und ja Timbalu, du warst schon ganz schön geduldig und hast mir "liebevoll" versucht was zu erklären. DANKE

[Timbalu]

So, den Test mit dem Kontaktformular habe ich gemacht. In der erhaltenen Mail ist alles korrekt zu sehen. Absätze sind da wo sie hingehören.

Mit aktiviertem WYSIWYG-Editor (kurz folgend JS-Editor genannt) und aktiviertem NL2BR Plugin?

(Übrigens: Jedes Feld in das ein User etwas eintragen und absenden kann ist ein Formularfeld, wo auch immer.) Im Falle des Kontakt Mailformulares kann es sogar sein, dass NL2BR mit nl2br() völlig unnötig ist, da es ich hier nicht um HTML Ausgaben, sondern um MAIL Ausgaben handelt. Da liegt der Hase dann woanders. Wahrscheinlich ist deshalb, dass das NL2BR hier sowieso umschifft wird.

Nun zu meiner Überlegung. Sag mir bitte, ob ich das so machen kann. Ich schalte das NL2BR Plugin wieder zu, weil es ja eigentlich Sinn macht. Da ich immer mit dem WYSIWYG-Editor arbeite, müsste ich nun von Hand, wann immer ich eine Tabelle anlege den Befehl <nl>/</nl> zum Einsatz bringen, damit es keine ungewollten Umbrüche gibt. Richtig?

Falsch!
Sobald ein JS-Editor im Spiel ist wird NL2BR gar nicht mehr für die Ausgabe im Frontend durchlaufen!

Code: Select all

// don't add additional br or p tags, if the wysiwyg-editor, the textile, or markdown plugin already took care about markup

EIN JS-Editor kümmert sich von sich aus um die korrekte HTML-Schreibweise deiner Eingaben - auch von ENTER-Umbrüchen! (Ausnahme: Kommentare, siehe nächstes Posting.)

Und was ist, wenn das NL2BR Plugin irgendwann in der Entwicklung der Programmierung überflüssig würde, oder wird es das nie geben? Laienfrage... dachte ich einfach nur, weil ich etwas voraus dachte und mir gerade durch den Kopf geht, das ich dann alle Einträge mit Tabelle vom <nl> befreien müsste.

Man soll nie nie sagen, aber es ist eine programatische Funktion in PHP (als "Templatesprache"), die noch lange erhalten bleiben wird.
Was das eingesetzte <nl> Tag </nl> für die Ausnahmen angeht, so stört das nur den Browser und das auch nicht wirklich, da er/sie/es solches einfach stillschweigend ignoriert. Bei Verwendung des NL2BR Plugins werden diese für die Ausgabe aber wieder herausgerechnet!
Natürlich könnte eines Tages jemand auf die blendende Idee kommen <nl> zu einem offiziellen HTML Tag zu machen.... (aber davon schweigen wir jetzt!)

Ich habe mal gerade bei meinen anderen Blogs geschaut und stellte fest, das bereits bei 4 Blogs das NL2BR nicht installiert ist. Bis heute sind mir dabei keine komischen Sachen aufgefallen. Hab ich nur Glück gehabt?

Glück ist in dem Fall ein merkwürdiger Begriff. Es kommt wie immer darauf an, wer in diesem Fall für die Auszeichnung von ENTER-Umbrüchen verantwortlich war, ein JS-Editor oder ein anderes der genannten Markup-Plugins, oder der standardmäßige PLAIN-TEXT Editor, kurz folgend PTE genannt.
Die Frage wäre ja, wie diese Artikel in der Ausgabe deine aktiv gesetzten Teilenumbrüche mit ENTER ausgegeben haben.

Dabei fällt mir ein, das yellowled (Matthias) mir mal dazu geraten hat es abzustellen was ich auch sehr gerne getan habe, um das Problem von der Backe zu bekommen http://board.s9y.org/viewtopic.php?f=10 ... #p10431737

Ja, das hat er schon immer und voller Leidenschaft gemacht!

Ich stelle mir allerdings die Frage, wenn es ja bereits bei Installation mit ausgeliefert wird, warum bei der Entwicklung mit dem kombinieren von Editoren, dann nicht direkt eine Lösung mit programmiert wird, um keine unnötigen <br> zu schreiben. Es kann ja nicht Sinn und Zweck sein, den html Code von Hand nachzubessern.

Auch hier unterliegst du einem Irrtum, der wahrscheinlich auf meine unzureichenden Erklärungsversuche zurückzuführen ist. NL2BR mit nl2br() ist nur dann sinnvoll und wird im Plugin auch nur dann aktiv, wenn keines der anderen Plugins (JS-Editor+Textile+Markdown) installiert und aktiv ist. Dies gilt mind. seit Nov 24, 2011 und dem darauf folgenden S9y Release.

Denke ich da jetzt zu einfach?

Blog-Anfänger kommen dann womöglich nicht damit zurecht. Ich bin ja schon nicht mehr so ganz "anfängerblond" und versuche mich im HTML rein zu denken und zu verstehen, was da so passiert. Hoffe du siehst mir nach, wenn ich dann für Entwickler, oder Profis halt eben meine "Laien" Fragen stelle.

Ich sag es klar: Wer HTML schreibt - ob mit JS-Editoren, Textile oder Markdown mit eigener Syntax, oder sogar per Hand im PTE, hat NL2BR mit nl2br() zumindest für eigene Einträge eigentlich nicht nötig!

Diese "Purität" hat allerdings den Nachteil, dass man im letzteren Falle (mit PTE) jeden einzelnen Zeilenumbruch als <br> selber schreiben muss. Willst du allerdings den PTE verwenden und, aufgrund mangelnder Versiertheit oder als Liebhaber kurzer Wege, auf die schöne Funktion von nl2br(), nämlich der Umwandlung von ENTER (\n) in <br>, nicht verzichten, so musst DU halt selber aufpassen, wenn du strukturiertes Markup (siehe Tabellenbeispiele) in diesen PTE einfügst. Dafür und nur dafür sind diese Ausnahmen mit [NoBR]=<nl>...</nl> gemacht. So nebenbei: Auch die NL2P Option des NL2BR Plugins macht ähnliches, wenngleich viel komplizierter und scheitert deshalb manchmal bei komplizierteren Sachen.

Appendix:
Was ich bis jetzt überhaupt nicht verstehe, wie du überhaupt bei Benutzung eines JS-Editors auf treppenartige Tabellen in der Ausgabe treffen konntest (meiner Erinnerung nach der Grund der Fragestellung)

[Timbalu]

Setzt du nun einen WYSIWYG Editor ein, so werden alle Einträge in Eingabefelder grundsätzlich nicht mehr von NL2BR durchlaufen! [Für Kommentare ist das blöd!] (*)

[. . .]

(*) Hat das eigentlich schon mal jemand gemerkt?
Ich werde mir mal Gedanken machen, wie man (wenigstens) den CKEDITOR für Kommentar Textareas eingeschränkt nutzbar macht, oder für Kommentare eine Ausnahme des gegenseitigen "In-Ruhe-Lassens" bewirken kann. Ideas welcome.

Ziemlicher Bockmist!
Ich hatte einfach vergessen mich abzumelden.
Dann geht auch nl2br() für Kommentare wieder, TROTZ aktivem WYSIWYG-Editor! (Wie man sieht einer der Gründe, das NL2BR nie ganz zu deaktivieren!)

Aber nur, wenn man nicht angemeldet ist!

Ich muss also präzisieren: "... Gedanken machen, wie man in diesem Fall (nur WYSIWYG) das NL2BR oder die Core comment incs so umbauen kann, dass im angemeldeten Zustand die Kommentare-Ausgaben auch durch nl2br() gejagt werden...!" Ideas welcome!

[B.E.A.]

Appendix:
Was ich bis jetzt überhaupt nicht verstehe, wie du überhaupt bei Benutzung eines JS-Editors auf treppenartige Tabellen in der Ausgabe treffen konntest (meiner Erinnerung nach der Grund der Fragestellung)

Das ist ja das merkwürdige. Ich nutze seit meinem Anfang von Serendipity schon immer den WYSIWYG Editor. Wenn aber das Plugin NL2BR installiert und aktiv ist, passieren diese Treppenstufen, sowohl bei Bildern und Tabellen. Deshalb sagte mir Mathias damals, schalte es einfach ab.

Konsequenz:
Wenn ich also den WYSIWYG Editor immer nutze, schalte ich es ab, oder nicht? Ich komm schon bald echt durcheinander bei den vielen Überlegungen, denn du schreibst ja folgendes:

Ich sag es klar: Wer HTML schreibt - ob mit JS-Editoren, Textile oder Markdown mit eigener Syntax, oder sogar per Hand im PTE, hat NL2BR mit nl2br() zumindest für eigene Einträge eigentlich nicht nötig!

[Timbalu]

Eigentlich ja (für entryartige Einträge im Backend) - aber dies gilt dann ja nicht für Komnmentare, denn da schreiben weder du noch deine Kommentatoren per JS-Editor, also muss das Eingebene zur Ausgabenpräsentation durch ein "Markup Plugin", denn auch NL2BR ist ja ein solches, wenn auch auf kleinster Stufe, da es es sich nur um eine Sache kümmert.

Wie gesagt gibt es einen kleine Ungereimheit mit dem Admin (s.o.), ansonsten funktioniert es ja wie gewünscht, denn NL2BR erkennt grundsätzlich einen benutzten JS-Editor, wie auch die anderen Markup Plugins und umgeht die nl2br() parsung. Das ist auch keine Frage der Pluginreihenfolge in diesem Fall.

So das im Allgemeinen. Im Speziellen scheint das bei dir nicht zu funktionieren. Warum nur?
Das NL2BR Plugin müsste in Version 2.16 vorliegen. Die Frage ist also,

• reden wir von derselben Version?
• Und reden wir von aktuell geschriebenen und gespeicherten Einträgen oder von schon älteren aus der Zeit vor 1.7 oder sogar 1.6.x bei denen jetzt die Treppen auftreten?
• Ist das geklärt, könnte man immer noch mal schauen, wie so ein Beispieleintrag in der Datenbank abgespeichert ist, bzw ob eventuell der entryproperties cache etwas enthält was uns auf die Spur bringt.
• Welchen JS-Editor benutzt du? (meistens einer der letzten Buttons in der Reihe und meist ein [?] oder ein )

[Timbalu]

OK Bea

Im Hintergrund ist bis zum heutigen Release von Serendipity 1.7.6 (für mich) eine Klärung erfolgt, warum das bei dir (und damit wahrscheinlich auch anderen) so passiert.

Ich fasse das ganze einmal zusammen:

Nahezu jede Entry-artige Texteingabe in ein Formfeld wird von Serendipity so wie eingegeben in der Datenbank gespeichert. Dabei verbleiben ENTER-Umbrüche als "\n" Steuerzeichen.

• Dies gilt aber nur für die "normale" Speicherung. Wird der Cache von entryproperties benutzt, existiert zusätzlich ein bereits fertig aufbereiteter Datenbank-Eintrag für die Ausgabe, zum Zeitpunkt der Erstellung des Entries..

Dies können in der internen Verwendung sein:

• Blog Einträge, Statische Seiten Einträge, HTML Klotz (nugget) Einträge und Kommentare.

Im NL2BR Plugin kann man sie generell AN und AUS schalten. Dies gilt ohne jedes weitere Zutun auch für Staticpage Einträge.

• Eintrag Textformatierung auf Eintrag anwenden Ja Nein
• Erweiterter Eintrag Textformatierung auf Erweiterter Eintrag anwenden Ja Nein
• Kommentar Textformatierung auf Kommentar anwenden Ja Nein
• HTML-Klotz Textformatierung auf HTML-Klotz anwenden Ja Nein

Wie wir bereits gesehen haben, vollzieht die Funktion nl2br() ja nun nichts anderes, als ein "\n" zu einem "<br>" zu machen. Eine Funktion, die auch außerhalb des NL2BR Plugins (zb in Textile oder Markdown als PHP libraries) verwendet wird.

Wir haben es daher mit unterschiedlich Eingabearten zu tun, die unterschiedlich behandelt werden wollen. Das ist die Schwierigkeit!

Die gängisten Editoren sind:

• Der PLAIN-TEXT-EDITOR (default),
• Textile oder Markdown Plugin,
• WYSIWYG-EDITOR

Alle drei sind verschieden zu behandeln. Ihnen gemein ist, dass ihre damit abgespeicherten Entry-Ausgaben (ohne Cache Nutzung) von den verschiedenen aktiven Markup Plugins, wie "Textformatierung: NL2BR" und zB "Textformatierung: Serendipity" (s9ymarkup) durchlaufen werden. Dabei kommt die Pluginreihenfolge zum Tragen.
Über die Pluginreihenfolge kann ein Plugin einem anderen über eine interne Variable mitteilen, dass es so oder anders zu regieren hat, wenn dieses dafür Ausnahmen vorsieht.

Nun liegt der Text aber unterschiedlich vor:

• Mit dem WYSIWYG Editor werden die Einträge bereits quasi "Cache-artig" als HTML abgespeichert, und liegen zur Ausgabe bereits so vor, dass sie vor weiteren Textformatierungen geschützt werden müssen.
• Bei Markdown und Textile ist dies ähnlich, nur das hier eine spezielle (HTML ähnliche) Syntax verwendet wird, die dann nur vom jeweiligen Plugin in entsprechendes HTML verwandelt werden soll. Diese Markup Plugins werden im Gegensatz zum WYSIWYG-Editor bei allen Eintragstypen - also überall benutzt!
• Allein der Plain Text Editor möchte gerne die anderen Textformatierungen nutzen. Für ihn allein sind alle Ausnahmen (ISOBR und NL2P) und Optionsmöglichkeiten wie [NoBR] bestimmt.

Für Textile und Markdown macht es also Sinn das NL2BR Plugin ganz und dauerhaft zu deaktivieren.
Bei einem WYSWYG-Editor ist die Empfehlung eher, die oben genannten Schalter für Einträge zu verwenden, da dieser Editor nur im Backend verwendet wird, aber man die Kommentare ja gerne weiter von NL2BR behandelt sehen möchte.

Schwierig zu behandeln sind also alle Zwischenformen. ZB über die Jahre verschieden genutzte EDITOREN und ihre Einträge. So etwas ist automatisch nur sehr schwer korrekt abzufangen und wird daher größtenteils unterlassen.

Der Fix in Serendipity 1.7.6 bezieht sich auf einen Versuch von mir vor ein paar Jahren, einen benutzten WYSIWYG Editor ebenso einfach, aber unabhängig abzufangen, wie es für ein markdown oder textile Plugin möglich ist, solange sie in der richtigen Pluginreihenfolge stehen. Dies war ein Fehler und hat leider nur für den in Serendipity eingeloggten Nutzer funktioniert und daher eher für Verwirrung gesorgt.
Dies war/ist für deine Treppen verantworlich, solange man einen solchen Entry als nicht eingeloggter User betrachtet(e).
Ohne riesige Verrenkungen ist dem nicht beherrschbar beizukommen. Deshalb haben wir nun dem NL2BR Plugin eine Config-Notiz angehängt, die den User auf mögliche Ausgabefehler in Kombination mit Markup Editoren hinweist und diesen ungenügenden Versuch für eine automatische Ausnahmebehandlung für WYSIWYG-Editoren zurückgesetzt.

Die Empfehlung bei Benutzung von einem WYSIWYG Editor kann also nur lauten, im NL2BR Plugin "Eintrag" und "Erweiterter Eintrag" und "Klotz" auf "Nein" zu stellen! Und dann dabei zu bleiben!

Anhang: Ich hoffe inständig, meine nl2br "Romane" nicht weiter forsetzen zu müssen....