Serendipity Forums

Mit Bezug auf diesen Beitrag hänge ich mich hier mal dran

In Verbindung mit dem Plugin serendipity_event_imageselectorplus werden leider im Code des Galerie-Moduls von imageselectorplus diverse P-Tags eingefügt wo sie nicht hingehören und daher unzulässigen Code produzieren.

Mit dem letzten Stand 2.1 ändert sich leider auch nichts, außer ich stelle von p auf br um. Aber das kann ja nicht Sinn der Sache sein, denn die br erzeugen total unsinnige Umbrüche.

Yep, wie du siehst aber NL2P genauso......, denn...
es sind beide nur relativ dumme Funktionen, die einfach alles was einen Umbruch hat verwandeln, egal ob nach br oder p.

Da hilft nur lernen damit umzugehen. Im Falle von P möglichst keine Umbrüche, außer in Text.
Im Falle von br gilt dies grundsätzlich auch, dennoch habe ich diese kleine Hilfsmittel für Tabellenformate hineinprogrammiert (sus Gründen der Übersichtlichkeit in der textarea) und die Abfragen auf WYSISWYG-Editor, Textile und Markdown eingefügt. Das ist aber (noch) keine offizielle Plugin Version.

Ian

Nun ist es aber leider so, dass ich auf den Output vom Plugin keinen Einfluss habe. Denn scheinbar spielt auch die Reihenfolge der Plugins in der Event-Liste keine Rolle. Egal, ob nl2p vor oder nach imageselectorplus kommt, der falsche Code ist immer da.

bernd_d wrote:Nun ist es aber leider so, dass ich auf den Output vom Plugin keinen Einfluss habe. Denn scheinbar spielt auch die Reihenfolge der Plugins in der Event-Liste keine Rolle. Egal, ob nl2p vor oder nach imageselectorplus kommt, der falsche Code ist immer da.

Hmmm, das stimmt so nicht ganz....
Du kannst darauf Einfluss nehmen in der Art wie du deinen Blogeintrag schreibst. Vermeide Newlines! Dann sollte dir auch NL2P nicht dazwischenfunken, oder stimmt das gerade nicht?

Verwendest du einen Editor oder das Textile oder Markdown Plugin? Hast du das Plugin Erweiterte Eigenschaften... aktiviert, so wird dein Blogentry als fertiger Output als Cache zwischengespeichert und wird erst wieder verändert, wenn du ihn erneut speicherst. Damit kannst du auch - generell temporär - das NL2BR Plugin für diesen Eintrag deaktivieren.

Ian

Timbalu wrote:Yep, wie du siehst aber NL2P genauso......, denn...
es sind beide nur relativ dumme Funktionen, die einfach alles was einen Umbruch hat verwandeln, egal ob nach br oder p.

Das stimmt so nicht. nl2p kann beispielsweise innerhalb bestimmter Nodes Umbrüche komplett ignorieren. Um was für Code geht es genau? Vielleicht hilft diese Funktion hier ja.

onli wrote:Das stimmt so nicht. nl2p kann beispielsweise innerhalb bestimmter Nodes Umbrüche komplett ignorieren. Um was für Code geht es genau? Vielleicht hilft diese Funktion hier ja.

Danke für den Hinweis! Habe jetzt mediainsert zu den Ausnahme-Tags mit hinzugefügt, schon sind die vielen Validation-Fehler auch weg

onli wrote:Das stimmt so nicht. nl2p kann beispielsweise innerhalb bestimmter Nodes Umbrüche komplett ignorieren.

Hi Onli
Das stimmt natürlich, ich war einfach davon ausgegangen, dass er das schon probiert hatte....

Übrigens verstehe ich jetzt, nachdem ich deinen Beitrag über die WYSIWYG Abfrage noch einmal richtig gelesen habe, was du meinst, wenn du sagst, dass die Prüfung auf $serendipity['wysiwyg'] nicht immer trifft. Ist dir inzwischen etwas dazu eingefallen?

Was ist, wenn man das nl2br Plugin definitiv in Abhängigkeit zum Erweiterte Eigenschaften... Plugin setzt?! Dann hätte man dieses Problem gelöst. Ich weiß nur nicht, was man sich damit für Schwierigkeiten auf anderer Ebene aufhalst, außer das die Bedienung etwas Komplizierter wird...

Ian

Es wäre noch mehr, oder? Die Abhängigkeit wäre für die Option notwendig. Aber zusätzlich müsste geprüft werden, ob der cache aktiviert ist, den kann man ja ausschalten.

Wir müssten da anders rangehen. Eine solche Option darf wirklich nur dann greifen, wenn der Eintrag initial erstellt wird. Mir ist da noch nichts eingefallen, bei backend_save die brs rauszufiltern würde auch solche Treffen, die der Nutzer per Hand einsetzt. Vielleicht fällt uns über die Feiertage was ein.

Idee: Wir haben ja den backend_save-hook. Bei ihm speichern wir, ob der Eintrag behandelt werden soll, also z.B. mit CacheLite (Pseudocode) Das könnte man dann beim frontend_view-event jedes mal abfragen und nl2p dann nicht durchführen.

Hmmm, klingt gut, das ist mir neu. Aber ist es so wie es da steht eine (Ab)Frage?

Und wie könnte man eine Abhängigkeit zum E.E.Plugin realisieren? Da gilt es ja nicht nur dasselbige auch als default Plugin zu setzen, sondern muß immer wieder prüfen, ob beide auch aktiv sind.

Ian