Plugin-Aufruf-Editor

[cmb]

Hallo zusammen!

Olaf hatte kürzlich in einem anderen Thread geschrieben:

Was man vereinfachen könnte wäre z.B. das Einbinden von Plugins in den Inhalt.
Das sind aus meiner Erfahrung die Dinge, die die User am ehesten abschrecken
Einige löbliche Plugins gibt es, die schon mal einen fertig konfigurierten Aufruf im Backend bereitstellen.
Spontan fällt mir da Video_XH ein, glaub ich jedenfalls. Meine Plugins zählen leider auch nicht dazu . Noch einfacher wäre es, wenn man das Einfügen über ein Dropdownmenü lösen könnte.

Daher habe ich mal einen alten Entwurf für ein TinyMCE 3 Editorplugin herausgekramt, und in ein Github-Repo verfrachtet. Wirklich nützlich ist das ganze wohl noch nicht, aber es deutet vielleicht schon an, was machbar wäre. Die wesentlichste Verbesserung würde konkrete Unterstützung durch die jeweiligen Plugins erfordern; diese könnten eben die Informationen, die derzeit noch händisch in call.js eingepflegt werden müssen, dynamisch ausliefern.

Wer will, kann es sich ja mal herunter laden und anschauen. Installationshinweise finden sich in README.md. Derzeit werden nur englische und deutsche Sites unterstützt; für andere Sprachen müssten die Dateien in langs/ übersetzt werden (oder halt einfach kopiert werden, z.B. für Französisch: en.js → fr.js und en_dlg.js → fr_dlg.js); ansonsten funktioniert der TinyMCE gar nicht.

Über Feedback würde ich mich freuen.

[olape]

Hallo,

zumindest auf die Schnelle habe ich das nicht hinbekommen.
Muss aber auch gestehen, ich habe mich noch nie wirklich mit TinyMCE beschäftig.
Da muss ich wohl mal etwas mehr Zeit zum Testen einplanen.

[cmb]

zumindest auf die Schnelle habe ich das nicht hinbekommen.

Zunächst: beim Entpacken des Archivs ist darauf zu achten, dass es danach die Datei plugins/tinymce/tiny_mce/plugins/calleditor/editor_plugin.js gibt (also kein Calleditor_XH-master im Pfad vorkommt). Das sollte ich wohl noch mal deutlicher dokumentieren.

Bzgl. der init-Datei kannst Du einfach die bestehende plugins/tinymce/inits/init_full.js durch diesen Code ersetzen.

[olape]

Hallo,

mit ein paar Minuten mehr Zeit,....

Das ist genau der Ansatz, den ich meinte.
Damit ist das Einfügen von Plugin-Aufrufen so einfach, wie das Einfügen von Bildern.

1+

[lck]

Wer will, kann es sich ja mal herunter laden und anschauen.

Gemacht und angetestet. Ich glaube das wäre eine schöne Vereinfachung, im Sinne von CMSimple_XH.
Bedeutet natürlich wieder Mehrarbeit für die Plugin-Entwickler, auf alle Fälle interessant. Bin gespannt, wie sich das entwickelt.

[Holger]

Die wesentlichste Verbesserung würde konkrete Unterstützung durch die jeweiligen Plugins erfordern; diese könnten eben die Informationen, die derzeit noch händisch in call.js eingepflegt werden müssen, dynamisch ausliefern.

Gut, dass diese Thema noch einmal auf's Tapet kommt.
Ich kenne den Entwurf noch aus dem ersten Anlauf. Meiner Meinung nach ist das größte Problem dabei eben die Bereitstellung der Daten durch die Plugins. Einfache Dinge, wie sie jetzt in call.js stehen, sind ja einfach machbar. Auch eine Auswahl an Parametern (wie im Beispiel die Seiten bei acDIVs oder die Namen vorhandener Galerien) sind auch noch kein Problem. So in etwa war das auch einmal, wenn ich mich richtig erinnere, mit einem optionalen Editorplugin bei Websitebaker gelöst (lange nicht mehr danach geschaut. Gibt's Websitebaker überhaupt noch?).

Aber richtig interessant wird es, wenn man die oftmals mehreren optional möglichen Parameter eines Plugins auch berücksichtigt (und nur so macht es IMO Sinn). Beim einfügen eines PluginCalls müsste ein Formular mit Checkboxen, Inputs etc., entsprechend den möglichen Parametern des jeweiligen Plugins, generiert werden. Und dann müsste beim Doppelklick auf einen bestehenden PluginCall das gleiche Formular, mit entsprechend gesetzten Optionen, wieder angeboten werden.
Und natürlich, das hatte ich damals auch schon gesagt, müsste die ganze Sache auch noch universell mit anderen Editoren funktionieren.

[cmb]

Das ist genau der Ansatz, den ich meinte.

Danke, freut mich!

Bin gespannt, wie sich das entwickelt.

Ich auch!

Gibt's Websitebaker überhaupt noch?

Ja, und die scheinen viel aktueller als wir:

Due to the release cycles of PHP, the support of PHP versions less then 5.6 was finally stopped on Dec-01-2016! It is highly recommended to set the server to PHP-5.6 still better to switch to PHP-7.x. !!

Würde ich eigentlich auch gerne schreiben können.

Aber richtig interessant wird es, wenn man die oftmals mehreren optional möglichen Parameter eines Plugins auch berücksichtigt (und nur so macht es IMO Sinn).

Ich denke, dass optionale Parameter auf jeden Fall berücksichtigt werden müssten, aber nicht unbedingt solch spezielle Parameter wie bei Video_XH.

Und dann müsste beim Doppelklick auf einen bestehenden PluginCall das gleiche Formular, mit entsprechend gesetzten Optionen, wieder angeboten werden.

Ja, guter Punkt! Ändert sich die Signatur eines Funktion, dann gibt es vermutlich Probleme (kann man in der aktuellen Vorversion ja auch schon gut nachvollziehen). Allerdings sollten Plugins solche Signaturänderungen auch nur selten durchführen, und dann auch wenigstens prominent dokumentieren ("Upgrade-Guide").

Bezüglich des Formulars im Allgemeinen: das könnte wohl auch aus einer komplexeren "call.js" rein clientseitig erzeugt werden, aber es ist natürlich auch denkbar, dass dieses per Ajax vom Plugin als HTML(-Fragment) abgerufen wird (und der resultierende Pluginaufruf dann entsprechend vom Plugin erzeugt wird – natürlich wieder per Ajax). Ich kann mir auch vorstellen, dass beides implementiert wird, und das Plugin letztlich selbst entscheidet, ob ein spezielles Formular sinnvoll ist.

Und natürlich, das hatte ich damals auch schon gesagt, müsste die ganze Sache auch noch universell mit anderen Editoren funktionieren.

Zumindest ein Teil müsste schon sehr Editor spezifisch implementiert werden, aber ein anderer Teil könnte wohl auch Editor übergreifend implementiert werden. Im Falle einer reinen Ajax-Variante wäre allerdings wohl kaum noch etwas Editor übergreifend zu programmieren.

[Holger]

Eigentlich fände ich eine andere Variante zur Konfiguration einzelner PluginCalls besser. Das müsste aber durch das Plugin erledigt werden - vielleicht mit Core-Unterstützung aus einer zukünftig verbesserten API:

Der Editor liefert lediglich die Basisvariante des PluginCalls. Das wäre vermutlich leicht für mehrere Editoren integrierbar und der Aufwand für den Pluginautor bleibt auch überschaubar. Zur Not bleibt es zunächst bei einer call.js, die der Admin für den User konfiguriert.

Nachdem der User dann das Plugin einmal eingefügt hat, könnte im View-Mode vom Plugin ein Konfigurationsdialog angeboten werden. Ein ausklappendes Formular oder eine Anzeige in einer Modal-Box, beides aktiviert mit einem Klick auf ein Icon. Hier macht der User dann die endgültigen Einstellungen - quasi an Ort und Stelle des Geschehens. Gut, die Daten müssten dann irgendwo gespeichert werden. Das müsste aber nicht unbedingt im Content sein...