Mögl. Datenverlust mit Tiny 5/6b in MBlock Datenblöcken nach Umsortieren

[ischfr]

Das folgende Problem wurde vor einer Weile schon mal im Slack besprochen. Da es hier bisher keinen Eintrag dazu gibt, stelle ich das mal ein, damit es nicht vergessen geht.

Voraussetzung:

• ein Modul, das MBlock (mit oder ohne MForm) für unbegrenzte Datenblöcke nutzt
• in der MBlock-Datenblock-Definition wird dabei jeweils eine Textarea mit Tiny eingesetzt (jeder vom Redakteur angelegte Datenblock erhält also eine Tiny-Instanz)
• ein Artikel-Block im Backend auf Basis dieses Moduls mit mind. drei befüllten MBlock-Datenblöcken

Testfall - Editieren des Blocks:

• mehrfaches Ändern der Datenblock-Reihenfolge (entweder durch Sortierpfeile oder Drag)
• anschließendes Speichern
• erneutes Öffnen zum Editieren

Ergebnis: Die Editor-Inhalte mancher Blöcke sind nun entweder vertauscht oder gelöscht.

Beobachtungen:

• Während des Umsortierens scheint sich die Reihenfolge zunächst richtig zu ändern, das Problem wird erst nach dem Speichern und erneutem Aufruf sichtbar.
• So lange nur Datenblöcke neu angelegt oder bearbeitet werden, funktioniert alles.
• Wenn nur ein Datenblock um eine Position bewegt wird und man anschließend speichert, scheint das Problem nicht zu bestehen.
• Die Redactor- und CKE5-Addons haben dieses Problem nicht

Vermutung: Wenn ich es richtig verstehe, sollen vom Tiny-Addon beim Umsortieren von MBlock die TinyEditor-Instanzen beendet und nach Änderung der Reihenfolge erneut Initialisiert werden. Das scheint nicht so gut zu funktionieren. Evtl. ein Reihenfolge/Timing-Problem?

Evtl. verwandt: https://github.com/tinymce/tinymce/issues/8477 https://github.com/tinymce/tinymce/issues/7753 https://fiddle.tiny.cloud/33faab (Tiny Version auf 5.x setzen und fiddle mit Run neu starten)

[ischfr]

Einfaches Modulbeispiel zum Testen (MForm und MBlock benötigt):

INPUT

<?php

$id = 10;

$mform_mb = MForm::factory()
    ->addFieldsetArea('TEST', MForm::factory()
        ->addTextField("$id.0.name", array('label'=>'Titel'))
        ->addTextAreaField("$id.0.text", ['label'=>'Text', 'class'=>'tiny5-editor', 'data-profile'=>'default']) 
    );

echo MBlock::show($id, $mform_mb->show());

?>

OUTPUT

<?php

dump( rex_var::toArray("REX_VALUE[10]") );

?>

[dergel]

ich werde erstmal die vorhandenen Issues entfernen und einen Stand fertigstellen, mit welchem man ein Release machen kann. Im Moment ist die aktuelle Version von tinymce 6.8.3 .. deswegen verhält sich vielleicht auch einiges schon anders

[ischfr]

Danke für das neue Release!

Leider bleibt das Issue bestehen – ich habe das gerade mit der neuen Version getestet und habe bei dem o.g. Testaufbau wieder das gleiche Ergebnis wie vorher.

Insofern halte ich es nach wie vor für riskant, TinyMCE in Kombination mit MBlock einzusetzen, da man sich beim Ändern der Reihenfolge und anschließendem Speichern u. U. Inhalte löscht, ohne es gleich zu merken!

[ischfr]

Einige weitere Beobachtungen dazu:

Mblock-IDs:

Wenn man für einen MBlock Textfelder und -areas definiert und dann in einem Block mehrfach einsetzt, dann haben die beim Artikel-Editieren zunächst HTML-IDs wie "rv2_0_name" und "rv3_0_text" im ersten MBlock und "rv2_1_name" und "rv3_1_text" im zweiten usw ...

Sobald man die MBlock-Sortierung ändert, werden für alle MBlöcke neue IDs nach einem anderem Muster generiert: "REX_INPUT_VALUE100name" und "REX_INPUT_VALUE100text", bzw.
"REX_INPUT_VALUE101name" und "REX_INPUT_VALUE101text" usw.

Das ist in MBlock wohl Standardverhalten – war mir bisher nicht bewusst, ist aber m.E. für das folgende relevant.

In dieser Betrachtung haben die Textareas die Klasse "tiny-editor", sollen also wie im obigen Modul-Beispiel als Tiny-Editoren genutzt werden.

TinyMCE-Addon - assets/tinymce/scripts/base.js:

Die Funktion "tiny_init" initialisiert neue Editor-Instanzen aus allen Seiten-Elementen mit der CSS-Klasse "tiny-editor". Sowohl beim ersten Aufruf (on rex:ready), als auch beim wiederholten (on rex:change). Ein wiederholter Aufruf von tiny_init sollte eigentlich eine vorhandene Editor-Instanz mit tinymce.remove(#INITIAL-ID) beenden, bevor er eine neue Instanz initialisiert. Dazu wird zunächst pro Tiny-Instanz mit der entsprechenden HTML-ID geprüft, ob sie existiert.

Dieser Vorgang passiert anscheinend erst "on rex:change", also nachdem MBlock bereits neu sortiert und neue IDs vergeben hat. Tiny scheint die Editoren intern mit der ursprünglich genutzten ID zu verwalten. Die neu sortierten und generierten IDs greifen deshalb vermutlich jeweils auf den falschen Editor zu. So lange alle diese Editor-Instanzen nur removed werden, sollte das wohl keinen Unterschied machen ...

Es sei denn, das ID-Benennungsmuster ändert sich ... und genau das passiert beim ersten Ändern der Reihenfolge in MBlock (s.o.). Das führt dazu, dass Tiny die ursprünglichen Instanzen mit der neuen ID nicht mehr findet und entfernen kann. Sie bleiben tinymce-intern bestehen, während zusätzliche initialisiert werden.

Das kann man nachvollziehen, wenn man sich am Ende der tiny_init Funktion von Tiny die Anzahl der Instanzen ausgeben lässt:

console.log('Anzahl Tiny Instanzen: ' + tinymce.get().length);

Wenn man am Anfang der tiny_init Funktion die bestehenden Editor-Instanzen in die Console ausgibt, dann kann man nach einem Sort die ursprünglichen Instanzen mit den alten IDs auch sehen:

if( tinymce.get().length ){
    for(let i=0; i<tinymce.get().length; i++) {
        console.log('Alte Instanz: ' + tinymce.get(i).id);
    }
}

Weiter bin ich hier mit meinem begrenzten Wissen nicht gekommen, aber ich vermute einen Zusammenhang mit dem beschriebenen Problem. Die zusätzlichen Instanzen scheinen Tiny bei zusätzlichen Sorts durcheinander zu bringen.

Ich hoffe, dass diese Hinweise helfen können, das Problem zu beheben.

Vielleicht jemand, der mit dem Tiny-Addon und MBlock vertraut ist?

[tbaddade]

Ich kann das Verhalten nachstellen. Aber nur, wenn ich direkt den Speicher-Button des Modul nutzen. Wenn ich den Übernehmen-Button verwende, habe ich nicht diesen Datenverlust.

Ich bin mir nicht sicher, ob dass Issue hier richtig ist. Denn für das Aufarbeiten zum Speichern der Daten, Verschieben der Blöcke und Erhalten der IDs ist MBlock verantwortlich.

[tbaddade]

Die Daten gehen verloren, weil das name Attribute beim Verschieben der Blöcke angepasst wird und es dadurch bei den Blöcken zu Dopplungen von name kommt.

[alxndr-w]

Wg. @skerbis @joachimdoerr https://github.com/FriendsOfREDAXO/mblock/issues/165

[tbaddade]

Weshalb wird das Issue genau geschlossen? Nur weil Joachim den Support für Mblock einstellt, muss ja nicht der Support generell eingestellt werden. Ich halte das Addon immer noch für recht wichtig.

[alxndr-w]

Es gibt ja den Nachfolger mit dem MForm Repeater, da funktioniert das mit den Editoren im übrigen auch nicht.

Wäre vielleicht gut, erstmal nach vorne zu schauen und das dort zu lösen.

Ansonsten Issue gerne wieder aufmachen. Nur 4-5% der Issues, die ich aktuell schließe, werden nochmal geöffnet.

Ein Fix könnte auch seit einem Jahr beigesteuert werden.