Highlight plugin calls

[Holger]

Ich kam jetzt aus Zeitgründen nicht dazu alles noch einmal zu testen. Aber, verstehe ich das richtig, das div bzw. span mit den entsprechenden Klassen xhplugincall und mceNonEditable wird dann so im Content abgespeichert???

Ja.

Das wollt Ihr jetzt aber nicht wirklich so machen . Oder ist das okay, wenn Editor x dann noch "editor_x_noneditable", und Y, Z, A, B, C usw. dann auch noch ihre Klassen und spans oder divs hinzufügen? Und manches Plugin könnte auch solch einen Mechanismus gebrauchen.

Könnte man vor der Auslieferung allerdings auch noch entfernen (XH_finalCleanUp()).

Mit einer Konfigurationsvariable in der per RegExp übergeben wird was alles entfernt werden kann?

Deine Beharrlichkeit hat nun - nach 4 Jahren - endlich zum Erfolg geführt.

Na ja, es gab schon früher von mir einen Vorschlag (für CKEditor): viewtopic.php?f=16&t=12682#p59750

Und ob div oder span: so, wie es die Editoren bisher automatisch erledigt haben, war es doch ok für jeden User ...

Na ja, eben nicht.
Die Aufrufe wurden manchmal nicht als solche erkannt oder gar (versehentlich) verstümmelt.
Jetzt sind sie optisch hervorgehoben und lassen sich nur noch löschen.
Dass ein Unwissender einen Aufruf anklickt, dann den Button klickt und dort verändert - ist kaum zu erwarten, aber auch nicht zu verhindern.

Das meinte ich nicht. Wenn man in den Editoren in einer leeren Seite oder einem leeren Bereich einen Plugin-Aufruf einfügt, haben die Editoren schon immer - nach Bedarf - ein Blockelement drumherum gebaut. DAS war meines Wissens bisher kein Problem.

Warum fügt ihr die nötige Klasse und ein umschließendes <span> nicht nur im EditMode (nur innerhalb des TynyMCE) dynamisch hinzu? Das nötige CSS könnte mit den CSS-Dateien des TinyMCE, oder des Plugins geliefert werden.

[frase]

Könnte man vor der Auslieferung allerdings auch noch entfernen (XH_finalCleanUp()).

Mit einer Konfigurationsvariable in der per RegExp übergeben wird was alles entfernt werden kann?

Warum fügt ihr die nötige Klasse und ein umschließendes <span> nicht nur im EditMode (nur innerhalb des TynyMCE) dynamisch hinzu? Das nötige CSS könnte mit den CSS-Dateien des TinyMCE, oder des Plugins geliefert werden.

Hätte denn dann der Tiny bei der nächsten Bearbeitung noch die Chance das Plugin als solches zu erkennen und zu behandeln?

Na ja, es gab schon früher von mir einen Vorschlag (für CKEditor): viewtopic.php?f=16&t=12682#p59750

Wenn ich mich recht entsinne, war ich vom Placeholder-Plugin begeistert.
In XH ist aber immer noch der Tiny der Standard-Editor - und der brauchte halt sowas auch.

[cmb]

Wo soll dieses Plugin denn schlussendlich beheimatet sein?

Wenn du nichts dagegen hast, am besten gleich in https://github.com/manu37/tinymce4.

Warum fügt ihr die nötige Klasse und ein umschließendes <span> nicht nur im EditMode (nur innerhalb des TynyMCE) dynamisch hinzu? Das nötige CSS könnte mit den CSS-Dateien des TinyMCE, oder des Plugins geliefert werden.

Gute Frage! Ist natürlich sinnvoll; halt wie beim Placeholder Plugin für den CKEditor. Danke! Wer macht's?

[manu]

Ok. Alles schön nachgetragen im Master.

Die Sprachdateien (3x) sind nicht aktualisiert.
In "plugin.min.js" Zeile 11 hatte ich noch geändert ...

Code: Select all

tooltip: 'Insert/edit a XH plugin call',

... damit die alten Langs wieder stimmen.

Das nächste Mal führen wir diese Diskussion im GitHub, gell?

Okay. Dann aber in Deutsch.
PRs sind mir zu kompliziert und Schreibzugang ist "gefährlich"

ist aktualisiert in GitHub, ächz.
Die Auscheckerei auf GitHub ist kein Hexenzeugs, für Windows gibts TortoiseGit. Will ich nicht mehr missen, sogar für die lokale Versioniererei.

[cmb]

Die Auscheckerei auf GitHub ist kein Hexenzeugs, für Windows gibts TortoiseGit. Will ich nicht mehr missen, sogar für die lokale Versioniererei.

Geht mir auch so.

[frase]

Na ja, es gab schon früher von mir einen Vorschlag (für CKEditor): viewtopic.php?f=16&t=12682#p59750

Das habe ich mir jetzt nochmal zur Erinnerung genauer angeschaut. Perfekt!
Auch, dass es gar keinen Einfügen-Button gibt ist kein Nachteil - vielleicht sogar ein Vorteil.
Das wäre es wert, im CKE und im Tiny als Standard eingeführt zu werden. Immerhin sind Plugins und Funktionen für XH beinahe überlebenswichtig.

[manu]

Wo soll dieses Plugin denn schlussendlich beheimatet sein?

Wenn du nichts dagegen hast, am besten gleich in https://github.com/manu37/tinymce4.

Warum fügt ihr die nötige Klasse und ein umschließendes <span> nicht nur im EditMode (nur innerhalb des TynyMCE) dynamisch hinzu? Das nötige CSS könnte mit den CSS-Dateien des TinyMCE, oder des Plugins geliefert werden.

Gute Frage! Ist natürlich sinnvoll; halt wie beim Placeholder Plugin für den CKEditor. Danke! Wer macht's?

Bin dran.

[manu]

Ich habe jetzt eine Version im Master, die im edit Modus den <span> setzt und beim speichern/Verlassen des Edit Modus den <span> wieder löscht. Funktioniert bei einem Pluginaufruf tipptopp. Bei mehreren Pluginaufrufen habe ich ein Problem beim string.replace() resp. regex. Es ersetzt mir nicht die zwei einzelnen Plugin Aufrufe, sondern fasst die zwei Pluginaufrufe zusammen. Kennt sich da jemand mit js regex aus? Wenn ich den regex in php prüfe funktioniert er.

[cmb]

Ich habe jetzt eine Version im Master, die im edit Modus den <span> setzt und beim speichern/Verlassen des Edit Modus den <span> wieder löscht. Funktioniert bei einem Pluginaufruf tipptopp.

Super!

Bei mehreren Pluginaufrufen habe ich ein Problem beim string.replace() resp. regex. Es ersetzt mir nicht die zwei einzelnen Plugin Aufrufe, sondern fasst die zwei Pluginaufrufe zusammen. Kennt sich da jemand mit js regex aus? Wenn ich den regex in php prüfe funktioniert er.

Die Regex ist wohl greedy. Bei PHP kann man das mit dem U-Flag korrigieren (ansonsten sollte der Default ebenfalls greedy sein). Allgemein im Zweifel das (.*) durch ([^}]*) ersetzen (funktioniert nicht, wenn ein } im Pluginaufruf vorkommt, aber das sollte wohl nicht passieren). Weiß nicht aus dem Kopf, ob JS ein Pedant zum U-Flag kennt, oder ob lookahead Assertions unterstützt werden (letzteres wohl schon, aber erst seit ?).

PS: ungreedy siehe https://stackoverflow.com/questions/364 ... xpressions (also wie auch in PHP möglich)

PPS: Statt alert() verwende ich seit einer ganze Weile console.log() (oder gleich den Debugger).

[manu]

PS: ungreedy siehe https://stackoverflow.com/questions/364 ... xpressions (also wie auch in PHP möglich)

PPS: Statt alert() verwende ich seit einer ganze Weile console.log() (oder gleich den Debugger).

Ja mittlerweile habe ich das non greedy auch entdeckt /(.*?)/. Jetzt läuft es vom Reslutat her aber der replace beim save läuft doppelt so viel mal durch als nötig. Die alerts brauche ich hier, weil ja unmittelbar der page reload kommt und dann sind die console.logs wieder weg. Aber ich sehe grad, da gibts ja eine checkbox "nicht leeren"...