Code - Hilfe: wie finde ich einen PluginCall?

[Holger]

Hallo zusammen,

ich stehe vor einem simplen Problem:

wie finde ich sicher einen Pluginaufruf, sagen wir "meinplugin" innerhalb von $c[$s]???
Okay, Regexp . Da gibt es aber mehrere Varinten des Aufrufs. Klassich, mit # (kommt wohl nicht mehr wirklich vor und könnte ignoriert werden), mit vorangestelltem "plugin", mit angabe von Paramentern und ohne Parameter.... Und "meinplugin" könnte natürlich auch einfach als Text im Content stehen, klar.

Jemand eine Idee?

Hintergrund ist: ich möchte einen bestimmten PD-Tab nur registrieren, wenn auf der Elternseite das Plugin auch aufgerufen wird. Ähnlich wie bei ExpandContract, das alle Unterseiten einsammelt, soll auf diesen Unterseiten der Tab generiert werden. Auf den sonstigen Seiten jedoch nicht.

[cmb]

Bei Register_XH hatte (oder habe?) das so gelöst: https://github.com/cmb69/register_xh/bl ... ex.php#L99

Ich würde aber versuchen, so etwas gänzlich zu vermeiden. Vielleicht ist es ja möglich, statt des Pluginaufrufs auf der Elternseite, diese Funktionalität per PD-Tab zur Verfügung zu stellen. Dann könnte man die entsprechende Info für die Unterseiten eben aus den PageData auslesen.

[Holger]

Bei Register_XH hatte (oder habe?) das so gelöst:

Prima! Vielen Dank .

Ich würde aber versuchen, so etwas gänzlich zu vermeiden. Vielleicht ist es ja möglich, statt des Pluginaufrufs auf der Elternseite, diese Funktionalität per PD-Tab zur Verfügung zu stellen. Dann könnte man die entsprechende Info für die Unterseiten eben aus den PageData auslesen.

Da habe ich mich vielleicht schlecht ausgedrückt.
Ich möchte auf den Unterseiten nichts aus dem Plugin-Call der Elternseite auswerten.

Vielmehr habe ich auf den Kind-Seiten einen umfangreichen PD-Tab zur Anpassung dieser betreffenden Einzelseite an die Default-Konfiguration. Den Tab möchte ich aber nur auf Seiten anzeigen, für die er auch relevant ist.
Kurz gesagt: keine Elternseite mit Pluginaufruf? -> kein Tab.

Der Wunsch kam, weil ich beim Testen zwischen Pluginausgabe und Kind-Seite immer mal auf einer falschen Seite den Tab bearbeitet habe .

[cmb]

Ich würde aber versuchen, so etwas gänzlich zu vermeiden. Vielleicht ist es ja möglich, statt des Pluginaufrufs auf der Elternseite, diese Funktionalität per PD-Tab zur Verfügung zu stellen. Dann könnte man die entsprechende Info für die Unterseiten eben aus den PageData auslesen.

Da habe ich mich vielleicht schlecht ausgedrückt.
Ich möchte auf den Unterseiten nichts aus dem Plugin-Call der Elternseite auswerten.

Vielmehr habe ich auf den Kind-Seiten einen umfangreichen PD-Tab zur Anpassung dieser betreffenden Einzelseite an die Default-Konfiguration. Den Tab möchte ich aber nur auf Seiten anzeigen, für die er auch relevant ist.
Kurz gesagt: keine Elternseite mit Pluginaufruf? -> kein Tab.

Ja, das hatte ich so verstanden. Mein Punkt ist, dass die Prüfung auf einen Plugincall eben doch recht frickelig ist. Falls möglich, wäre es also sinnvoll den Plugincall auf der Elternseite durch ein PD-Tab auf der Elternseite zu ersetzen. Dann müsste man nur prüfen, ob eben die PageData der Elternseite den "Aufruf" enthalten.

[Holger]

Ja, das hatte ich so verstanden. Mein Punkt ist, dass die Prüfung auf einen Plugincall eben doch recht frickelig ist. Falls möglich, wäre es also sinnvoll den Plugincall auf der Elternseite durch ein PD-Tab auf der Elternseite zu ersetzen. Dann müsste man nur prüfen, ob eben die PageData der Elternseite den "Aufruf" enthalten.

Das wäre auch eine Idee. Ich muss überlegen, ob das irgendwie Sinn macht. Das Plugin erzeugt automatisch verlinkte "Teaser" aus den Unterseiten. Diese Unterseiten haben einen PD-Tab, mit dem man allerlei für die Ausgabe möglichst einfach einstellen kann.
Es erzeugt also Inhalte und es wäre gut, wenn man die Stelle der Ausgabe auch im Editor festlegen kann. Durch Platzierung des Plugin-Calls ist das ja gegeben. Es ginge auch ohne PluginCall in der Seite irgendwie, macht es aber schon wieder komplizierter.

Den ganzen Aufwand musste ich auch nur treiben, weil es mit TinyMCE nahezu unmöglich ist eine Containerstruktur mit drei verschachtelten DIVs zu erzeugen. Und selbst wenn man das irgendwie in die Seite bekommt, lassen sich die Container nicht mehr sauber entfernen. Quelltext ist keine Option für den User.
Also, ich muss mich echt noch einmal mit dem CKEditor beschäftigen. Da funktioniert das 100x besser

[cmb]

Es erzeugt also Inhalte und es wäre gut, wenn man die Stelle der Ausgabe auch im Editor festlegen kann. Durch Platzierung des Plugin-Calls ist das ja gegeben. Es ginge auch ohne PluginCall in der Seite irgendwie, macht es aber schon wieder komplizierter.

Ja, das ist dann wieder etwas frickelig. Man könnte halt einen Marker setzen lassen, und diesen dann durch die Pluginausgabe ersetzen.

Den ganzen Aufwand musste ich auch nur treiben, weil es mit TinyMCE nahezu unmöglich ist eine Containerstruktur mit drei verschachtelten DIVs zu erzeugen. Und selbst wenn man das irgendwie in die Seite bekommt, lassen sich die Container nicht mehr sauber entfernen. Quelltext ist keine Option für den User.
Also, ich muss mich echt noch einmal mit dem CKEditor beschäftigen. Da funktioniert das 100x besser

Ja, der CKEditor wäre wohl eine gute Alternative, zumal der Zuspruch zum TinyMCE 5 bisher nicht so positiv ausfiel, und TinyMCE 4 wirklich keine Option für die Zukunft ist.

[frase]

Ja, der CKEditor wäre wohl eine gute Alternative ...

+1
.. und gleich mit optionaler Inline-Bearbeitung.

[Holger]

Ja, der CKEditor wäre wohl eine gute Alternative ...

+1
.. und gleich mit optionaler Inline-Bearbeitung.

Ich könnte mich schwarz ärgern, dass ich nicht gleich nochmal den alten CK ausgepackt habe ...

Den ganzen Aufwand musste ich auch nur treiben, weil es mit TinyMCE nahezu unmöglich ist eine Containerstruktur mit drei verschachtelten DIVs zu erzeugen. Und selbst wenn man das irgendwie in die Seite bekommt, lassen sich die Container nicht mehr sauber entfernen. Quelltext ist keine Option für den User.
Also, ich muss mich echt noch einmal mit dem CKEditor beschäftigen. Da funktioniert das 100x besser

Ich hab das jetzt mal getestet. Meine drei verschachtelten DIVs, die sich immer wieder untereinander wiederholen und deshalb regelrecht "aneinander kleben", kann man problemlos mit dem CK bearbeiten.

Noch besser, wenn man "MagicLine" aktiviert hat (diese rote Linie die sich immer dann einblendet wenn man an Stellen kommt, die der Cursor sonst nicht erfassen kann). MagicLine kann per Mausklick ein Element zwischen meinen DIVs einfügen, dann ist der Container abgesetzt und lässt sich ganz einfach komplett selektieren und entfernen. Man kann auch die Blöcke per "ShowBlocks" anzeigen lassen. Dann geht's noch einfacher.

Die "Snippets" sind zwar gut, für meinen User aber keine Option, da nur im Quelltext anwendbar. Damit die Blöcke jetzt überhaupt erzeugt werden, habe ich extra ein Plugin für den Zweck geschrieben. Den ganzen Aufwand hätte ich sparen können, weil der CK mit passendem Plugin auch HTML-Dateien einfügt.

Ich hatte keine Zeit für ein Editor-Update. Aber das "InsertHTML-File-Plugin" und die Option, per Config auf Inline-Editor umzustellen, habe ich mal schnell eingebaut. Ansonsten ist es aus Zeitgründen noch der alte Code.
Das Update ist aber einfach und ich werden das Plugin auf jeden Fall aktualisieren und modernisieren. Zum Beispiel ist das PluginCall-Plugin ja noch ohne Button usw. Damals ging es da nur beim Tiny weiter .

Wer mal spielen möchte: Download
(die beiden Buttons rechts unten neben dem Fragezeichen waren mein Schlüssel)

[frase]

Na, da bin ich aber mal gespannt, wie das Ganze mit Version 5 (v33) aussieht. Du bist ja regelrecht euphorisch.
Bis Version 4 waren wir ja auch mit dem Tiny zufrieden.

Aber sicher: Ein paar Dinge macht der CKeditor wirklich besser. Man muss sich halt wieder umgewöhnen.

Block-Anzeige gibt es im Tiny übrigens auch. Und HTML-Templates kann man auch einfügen - was allerdings nicht ansatzweise so komfortabel wie im CKEditor funktioniert. Also ein weiterer Pluspunkt.

Automatisch angefügte Bildmaße zu entfernen funktioniert übrigens im CKE bestens - was im Tiny standardmäßig nicht möglich ist. Wichtig für responsive Layouts!

Aber, bevor ich mich nun tagelang mit dem CKE 4 herumschlage, warte ich lieber auf eine aktuellere Version.

[Holger]

Bis Version 4 waren wir ja auch mit dem Tiny zufrieden.

Ich nicht. Ich nutze v4 und es geht nicht! Ich finde auch keine Plugins mit denen ich die Anforderungen ansatzweise hinbekommen könnte.

Und HTML-Templates kann man auch einfügen - was allerdings nicht ansatzweise so komfortabel wie im CKEditor funktioniert. Also ein weiterer Pluspunkt.

Die Templates sind mir beim CK auch noch zu umständlich. Ich rede davon einfach per Filebrowser eine (Snippet-)Datei zu wählen und die dann an Cursorposition einzufügen. Im WYSIWYG-Mode.

Aber, bevor ich mich nun tagelang mit dem CKE 4 herumschlage, warte ich lieber auf eine aktuellere Version.

Da kannst du lange warten. Der CK4 hat z.Zt. noch LTS 2023. Für den 5er gibt es lange noch nicht die Ausstattung / Plugins wie für den 4er. Daher bleibe ich auf jeden Fall zunächst beim 4er.
Und auch beim CK get's ja jetzt los mit "Premium" Features. Während du heute noch Dinge wie <figure> / <figcaption> etc. einfach nur installieren / konfigurieren musst, bin ich da beim CK5 nicht mehr so sicher.

Du bist ja regelrecht euphorisch.

Nee. Einfach nur ernüchtert.
Alles, womit ich tagelang Zeit verschwendet habe, ist sogar mit dem alten CK out of the Box bedienbar.