NL2BR plugin und mysteriöse newlines

[Timbalu]

Hi

Ich brüte gerade über einem Problem mit dem nl2br plugin (auf br) gestellt.
In meinem entry text habe ich folgendes:

Code: Select all

<div style="text-align: center;"><xp>
hah
</xp><table>

stehen - wobei der <xp> tag nur ein test tag für die Ausnahmeregelung des Plugins ist - result ist aber laut Quellcodeanzeige:

Code: Select all

<div style="text-align: center;"><xp>
hah
</xp><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<table>

und der table ist ist in der Anzeige natürlich auch entsprechend verschoben.
Selbst ohne das startende div und ohne xp test tags ist das Ergebnis immer dasselbe.

Ich habe nun versucht im Plugin selbst dafür eine Antwort zu finden bzw ein preg_replace einzubauen, doch bisher ohne entscheidenden Erfolg. Es muss am table tag liegen, der im Plugin allerdings nur im NL2P Modus als Ausnahme gehandelt wird.

Vielleicht hilft mir da jemand auf den richtigen Weg, warum dieses Phänomen so auftritt.
Ian

Edit:
Komischerweise gibt es - mit aktiviertem plugin 'Erweiterte Eigenschaften von Artikeln' - ein weiteres Problem. Da ich es irgendwann satt hatte, habe ich das NL2BR Plugin via Markierung abgeschaltet. Da ich jetzt dem Problem mit dem mysteriösen br's mal auf den Grund gehen wollte, habe ich den Eintrag natürlich wieder aufgerufen und den Origialzustand wieder hergestellt. Speichere ich nun den Eintrag und rufe ich ihn wieder auf, demarkiere die Abschaltung und speichere, so ist sie beim nächsten Aufruf wieder markiert. Die Vorschau behält die Einstellung. Woran liegt das?

[garvinhicking]

Hi!

Also so viele BRs dürften ja garnicht kommen, das wundert mich wirklich. Evtl hast du <table> auch als Ausnhame definiert und das klappt nicht weil Du kein </table> hast?


Zum abschalten des gewählten Eintrags - welche s9y version nutzt Du? Ich meine da gabs es mal einen Bug der das nicht richtig ausgewählt hat, aber ich dachte das wäre schon in den 1.5ern behoben; spätestens aber in den 1.6ern...

Grüße,
Garvin

[Timbalu]

Version ist 1.5.4 und keine Ausnahme für tables definiert; sonst ist alles richtig ausgezeichnet, Codebeispiele waren natürlich nur etwas auf den Punkt gebrachte Beispiele.

Für die vielen brs vor tables habe ich jetzt doch noch ein paar sucheinträge gefunden.
http://board.s9y.org/viewtopic.php?f=2& ... e+in+entry
http://www.s9y.org/154.html
http://board.s9y.org/viewtopic.php?f=2& ... e+in+entry
etc. etc. etc.
Ich finde die Lösungen (disable NL2BR, kein Umbruch in Tables schreiben, disable entryproperties, etc) sind irgendwie alle nicht das Gelbe vom Ei!
Lieber wäre es mir, man könnte für das nl2br plugin eine wie auch immer geartete table regex schreiben, die sich dieses Problems wirklich annimmt.

Ian

Edit:
Ein 'einfaches' preg_replace a la
$eventData[$element] = preg_replace(array('<table.*?>\n*',<thead.*?>\n*',<tbody.*?>\n*',<tr.*?>\n*',<td.*?>\n*'), array('nur als tags'), $eventData[$element]);
müsste dem ja so in etwa Genüge tun - wenn man es denn irgendwie so schreiben kann. (Ich kann das nicht...!, das Beispiel verdeutlicht aber hoffentlich was ich damit meine...) Billiger wäre noch soetwas: replace (tags+\n mit tag)...
Diesen Vorputz dann vor $eventData[$element] = nl2br($eventData[$element], true); gesetzt, könnte uns einer Lösung näher bringen, oder?

[garvinhicking]

Hi!

Zeig mal nen screenshot von nl2br plugin. Eigentlich sollte genau das passieren, wenn Du "table" in deine ausnahmeliste aufnimmst.

Grüße,
Garvin

[Timbalu]

Hi Garvin

Das habe ich schon probiert. Ergebnis: alles in table wird ausgenommen. Das ist zwar ein anständiges Result, aber nicht das, was ich anstrebe, da ich innerhalb der td tags mit Umbruch arbeite und nicht jeden persönlich mit br schreiben will (Beispiel Gedichtstrophen). Dort also soll nl2br wieder anspringen. Ich 'regexe' mich hier zu Tode und finde einfach keine Lösung... , dabei könnte es so einfach sein, wenn man alle tags, gefolgt von \newline vor dem nl2br in tags ohne \n verwandeln lassen könnte - Beispiel
$eventData[$element] = preg_replace('|(?<!>).\n|', '', $eventData[$element]);
(funktioniert leider nicht!)
oder umgekehrt text\n in tables soll immer von nl2br geparst werden....

Ian

edit:
wg dem markieren/demarkieren des plugins, war der 'ep_disable_markup_...' key auf nl2br:uid gesetzt, obwohl mit demarkiert gespeichert.
Nach händischem Löschen der entryid in PREFIX_entryproperties und erneutem Speichern ist das genannte Phänomen dann weg.

[garvinhicking]

Hi!

Ahja. Okay, dafür ist das Plugin tatsächlich nicht ausgelegt. Und das zu programmieren ist schon höllisch schwer, wie Du schon bemerkt hast.

Ich würde die Umbrüche in der Tabelle dann manuell setzen; wenn Du eh schon HTML-Code tippst sollte das ja gehen. Oder konzeptionell mal überlegen ob Du wirklich eine Tabelle brauchst, oder nicht eher ein Ausgabeplugin dafür bastelst bzw. den Text-ersetzer nutzt.

Grßüe,
Garvin

[Timbalu]

Ahja. Okay, dafür ist das Plugin tatsächlich nicht ausgelegt. Und das zu programmieren ist schon höllisch schwer, wie Du schon bemerkt hast.

Tja, ich weiß nur nicht warum, weil es doch eigentlich so einfach scheint... Irgendetwas funkt non-visuell dazwischen...

Ich würde die Umbrüche in der Tabelle dann manuell setzen; wenn Du eh schon HTML-Code tippst sollte das ja gehen. Oder konzeptionell mal überlegen ob Du wirklich eine Tabelle brauchst, oder nicht eher ein Ausgabeplugin dafür bastelst bzw. den Text-ersetzer nutzt.

Die workarounds kenne ich ja...., mich hatte nur irgendwie der Ehrgeiz gepackt....
NL2P kann das..., so in etwa.... (für mich aber nicht wirklich besser zu benutzen als NL2BR), das ist aber nicht wirklich portierbar.

Ian

[Timbalu]

Ich antworte mir - weiter fragend - mal selber....

Garvin, wenn ich wüßte, ob die Abfrage

Code: Select all

if(...
!$eventData['properties']['ep_no_nl2br'] && !isset($serendipity['POST']['properties']['ep_no_nl2br'])

die Nutzung von WYSIWYG-Editoren abdeckt, und damit NL2P und NL2BR untersagt, könnte ich meine - eigentlich dann doch sehr einfache Lösung (weil ständig an der falschen Stelle probiert), - hier einfach mal zum testen posten.

Sie konvertiert alle <tags><br> zurück in <tag> bzw <tag>\n. Ich habe eine neue config option eingeführt, mit der man die Nutzung dieser Lösung (die einfach zu generell ist, als das sie immer gelten könnte) explizit anschalten kann.

Ich wäre damit fürs erste schon zufrieden, habe aber nicht ausreichend bedacht, was damit möglicherweise für neue Komplikationen auftauchen. Denkt doch alle mal mit nach....! Danke.

btw, was ist der Text-ersetzer ?

Ian

[onli]

>NL2P kann das..., so in etwa.... (für mich aber nicht wirklich besser zu benutzen als NL2BR), das ist aber nicht wirklich portierbar.

Was kann nl2p "so in etwa" genau und woran scheitert der Einsatz? Ich wollte das schon länger nochmal umprogrammieren, derzeit ist das einfach (schneller!) bloat-code. Aber solange es funktioniert...

Ich sehe gerade nicht, warum du brs wieder rückumwandeln willst?

[Timbalu]

>Was kann nl2p "so in etwa" genau und woran scheitert der Einsatz? Ich wollte das schon länger nochmal umprogrammieren, derzeit ist das einfach (schneller!) bloat-code. Aber solange es funktioniert...

Ich sehe gerade nicht, warum du brs wieder rückumwandeln willst?

zu 1) die klippen der table tags im Gegensatz zu nl2br umschiffen, dafür hakt er bei mir mit blockquotes etc (müsste ich erst mühselig wieder rauskramen...)

zu 2) will ich gar nicht! Aber ich will auch nicht <table><br>
<tr><br>
<td><br> usw...

[onli]

dafür hakt er bei mir mit blockquotes etc (müsste ich erst mühselig wieder rauskramen...)

Krame es bitte raus, sonst kann ich das nur schwer fixen.

nl2p kann das übrigens wirklich, also auch: innerhalb von <table> nl ignorieren und dann in <td> sie wieder beachten. Dafür muss man das derzeit im Code aktivieren, es ist nur für <blockquote> an.

wenn ich wüßte, ob die Abfrage

Code: Select all

if(...
!$eventData['properties']['ep_no_nl2br'] && !isset($serendipity['POST']['properties']['ep_no_nl2br']

die Nutzung von WYSIWYG-Editoren abdeckt,

Tut sie meines Wissens nicht. Zumindest derzeit wird nl2br auch auf wysiwyg-editoren angewandt. Dafür könnte man $serendipity['wysiwyg'] prüfen.
Vll verstehe ich aber die Frage falsch.

[Timbalu]

Tut sie meines Wissens nicht. Zumindest derzeit wird nl2br auch auf wysiwyg-editoren angewandt. Dafür könnte man $serendipity['wysiwyg'] prüfen.

Ist das wirklich so? Das müsste doch fürchterlichste Ausgaben ergeben und das Forum wäre voll von verzweifelten Bloggern...! Allerdings wäre das in dem Fall bei NL2P auch so...!
Wenn du mir das definitiv bestätigst, lade ich meine version mit eingebauter wysiwyg Abfrage mal in den thread.

Ian

[onli]

Ich habe es ausgetestet und ja, das sieht nicht gut aus ;)

Deswegen hat YL in dem anderen Thread ja auch vorgeschlagen, aus dem du hierher verwiesen hast, das zu deaktivieren wenn wysiwyg an ist. Was wir auch tun sollten und über

Code: Select all

case 'frontend_display':
   #don't add additional brs if the wysiwyg-editor already
#took care about newlines
if ($serendipity['wysiwyg']) {
     return true;
}

in Zeile 131 funktioniert.

[Timbalu]

Ah, ok, Ich hatte es mit in die if Abfrage reingetan, aber das ist noch klarer!

zu den NL2P Problemen:
zb bei <div style="text-align:center;"><div style="background: blah blah;display: inline-block; width:100%;height: 100px;"><span style="float: right;margin-left: 100px;">Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</span></div></div>
Ergebnis mit NL2P:
<p class="break"><div style="text-align:center;"></p><p class="break"><div style="background: blah blah;display: inline-block; width:100%;height: 100px;"></p><p class="break"><span style="float: right;margin-left: 100px;">Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</span></p><p class="break"></div></p>

Zwar darstellbar (per FF), aber bestimmt nicht valid!

Bei blockquote arbeite ich auf einem Blog zusätzlich zu anderen blockquote Einstellungen wie blockquote:lang(de) zB mit background: url("img/closequote.png") ...; und ... list-style-image: url("img/openquote.png");
NL2P haut da natürlich <p class="break" rein>rein</p>, aber der Effekt war, das ich double-quotes bekam, die sich für mich einfach nicht per CSS bereinigen ließen. Ich kann mich dunkel erinnern, sehr lange mit diesem Problem beschäftigt gewesen zu sein. Das war in meiner Testphase mit NL2P und NL2BR.

Aber hier, da ich sowieso auf das schlichtere NL2BR stehe, meine Version zum testen

Ian

(siehe neuere Datei weiter unten)

[onli]

Argh. Wir haben da einen Denkfehler drin, oder?
Speichern die Formatierungsplugins nicht die Texte nur, wenn man sie cached, also werden die nicht immer (mal) wieder angewandt? Dann würde eine Prüfung auf serendipity['wysiwyg'] genau gar nichts bringen... (Wenn ja, wäre das ein schönes Beispiel dafür, wie das konzeptuelle Modell dieser Plugins nicht mit dem ersten Gedanken übereinstimmt ;) )

Das würde dann wohl trotzdem noch funktionieren wenn die wysiwyg-Option an ist (z.B. weil als Standard so gesetzt), aber eigentlich will man ja, dass der Beitrag immer so erhalten bleibt egal ob man später ohne den wysiwyg-Editor arbeitet.