Unterschiedliches Lösch-Verhalten der Editoren TinyMCE3, TinyMCE4 und CKEditor

[lck-git]

Test - löschen des kompletten Inhaltes einer Seite.

TinyMCE3.5.11
STRG+A und Entfernen --> Ansicht Quelltext: alles gelöscht
Manuelles Markieren per Maus und entfernen --> Ansicht Quelltext: Seitenüberschrift noch vorhanden (solange man nicht die Backspace-Taste zusätzlich drückt)

TinyMCE4
STRG+A und Entfernen --> Ansicht Quelltext: alles gelöscht
Manuelles Markieren per Maus und entfernen --> Ansicht Quelltext: alles gelöscht

CKEditor
STRG+A und Entfernen --> Ansicht Quelltext: Seitenüberschrift noch vorhanden
Manuelles Markieren per Maus und entfernen --> Ansicht Quelltext: Seitenüberschrift noch vorhanden (solange man nicht die Backspace-Taste zusätzlich drückt)

Fazit: Für den Advanced-Mode in XH_split sollte der CKEditor die erste Wahl sein. Aber warum ist das Ergebnis so verschieden?

[frase-git]

Tiny 3.x sollte nicht mehr mit "split" ausgeliefert werden. Da kommen zukünftig sowieso noch ganz andere Probleme. (html5-Tags ...) Wer will auf die ganzen Fragen antworten ...?

Tiny 4: Das Verhalten finde ich besser - weil wie erwartet.
Wenn ein Profi (No-NOPE-Modus) alles löscht, will er auch die Seite löschen.
Man könnte vor dem Speichern allerdings warnen: Seite wirklich löschen?

CKE: Dem muss man nur beibringen, dass er Kommentare erfasst.

[lck-git]

Tiny 3.x sollte nicht mehr mit "split" ausgeliefert werden. Da kommen zukünftig sowieso noch ganz andere Probleme. (html5-Tags ...) Wer will auf die ganzen Fragen antworten ...?

Da gebe ich dir recht, das predige ich schon seit einem Jahr.

In den anderen Dingen muss ich dir widersprechen. Meiner Meinung nach ist das Verhalten des CKEditors genau das Richtige. Wer komplette Seiten löschen will (samt Überschrift), der sollte und musste teilweise, um sicherzugehen das alles entfernt wird, auch bisher in der HTML-Ansicht arbeiten.
Beispiel Advanced-Mode:
Man möchte nur den Inhalt der Seite löschen und einen neuen Text erstellen. Hat man den alten Text in obiger genannte Methode gelöscht und speichert dann die Seite ab, findet man den neu erstellten Text unter dem des vorherigen Menulevels, da ja die Uberschrift auch vorher mit entfernt wurde.

[frase-git]

In den anderen Dingen muss ich dir widersprechen.

Trotz fortgeschrittenem Alter, bin ich nicht ganz beratungsresistent. Gut erklärt : verstanden.
Dann muss man eben dem Tiny 4 beibringen, die Kommentare NICHT zu erfassen.

[cmb69]

Dann muss man eben dem Tiny 4 beibringen, die Kommentare NICHT zu erfassen.

Wenn das geht, gut. Ansonsten finde ich das nicht so problematisch, weil es ja nur den Advanced-Mode betrifft, und Leute, die diesen verwenden, sollten auch mit der unterschiedlichen Art der Löschung klar kommen können. Das unterschiedliche Verhalten sollte halt gegebenenfalls dokumentiert werden.

Einzig könnte diese Sache die Wahl des Standardeditor beeinflussen. TinyMCE 3 ist sowieso raus. Holger hat den CKEditor schon vor langem vorgeschlagen. Mir ist es eigentlich egal, weil sowohl TinyMCE 4 als auch CKEditor deutlich anders sind als TinyMCE 3 (und ich selbst sowieso den Codeeditor bevorzuge).

[frase-git]

Stimmt.
Man muss den tiny 4 nicht noch mehr ummodeln. Hinweis für Nutzer des Advanced-Mode genügt.

Ich kann mich immer noch nicht für einen der beiden relevanten Editoren entscheiden.
Gibt es bei Ludwig Preferenzen? Das wäre dann (für hier) die entscheidende Stimme.
Holger müssen wir, glaube ich, nicht fragen. ;-)

[lck-git]

Ich kann mich immer noch nicht für einen der beiden relevanten Editoren entscheiden.
Gibt es bei Ludwig Preferenzen?

Mir geht's genauso. Ich müsste mir das nochmal ganz genau anschauen, der CKE gefällt mir persönlich, weil er den Quelltext sehr übersichtlich darstellt.
Ich vermute, dass die meisten Nutzer den TinyMCE verwenden, da dieser ja bisher mit CMSimple_XH ausgeliefert wurde als Standard-Editor und daher werden sie wahrscheinlich eher zum TinyMCE4 tendieren und akzeptieren (?).

Holgers Meinung wäre aber doch wichtig.

[cmb69]

Wir sollten auch nicht unbedingt vergessen, dass es noch eine ganze Reihe weiterer nicht uninteressanter Editoren geben könnte. Der Aloha Editor machte zumindest vor einer ganzen Weile einen recht vielversprechenden Eindruck, aber derzeit gibt es wohl keine Online-Demo, und neulich bin ich auf WYSIHTML5 gestossen, der auch ganz interessant zu sein scheint. Und dann gibt es noch den WYMeditor, und eine bereits fertige CMSimple_XH Integration des elRTE Editors.

Auf jeden Fall fände ich es sinnvoll, dass der Default-Editor nicht in einem IFrame läuft – das macht wirkliches WYSIWYG praktisch unmöglich. Der TinyMCE kann das, beim CKEditor bin ich nicht sicher (vermute aber schon).

[TN03]

Mir ist es eigentlich egal welcher Editor in Zukunft als Standard zum Paket kommt. Ich möchte nur gerne, dass der CKEditor als Alternative möglichst gut vom Core und den Plugins unterstützt wird. Mir gefällt der CK halt besser und es gibt auch einige User die ihn lieber verwenden als TinyMCE.
Von meiner Seite also heute schon grünes Licht für den TinyMCE4.

Auf jeden Fall fände ich es sinnvoll, dass der Default-Editor nicht in einem IFrame läuft – das macht wirkliches WYSIWYG praktisch unmöglich. Der TinyMCE kann das, beim CKEditor bin ich nicht sicher (vermute aber schon).

Der CKEditor kann auch in einem DIV laufen. Dazu einfach dieses Plugin http://ckeditor.com/addon/divarea herunter laden und den Ordner divarea aus dem ZIP in den Ordner /plugins/ckeditor/plugins_external kopieren. Danach muss in der Konfiguration unter "Plugins - Remove" noch wysiwygarea hinzugefügt werden, um das Plugin für den Iframe-Editor zu deaktivieren.

Noch schöner fände ich die Inline-Variante: http://sdk.ckeditor.com/samples/inline.html
Das sollte prinzipiell auch möglich sein.
Nur gibt es dann keinen Platz mehr für die PD-Tabs ;-) ...

[cmb69]

Ich möchte nur gerne, dass der CKEditor als Alternative möglichst gut vom Core und den Plugins unterstützt wird.

Unterstützung vom Core ist kein Problem; was Plugins machen liegt aber im Zweifel nicht in unserer Hand. Wobei das ja nur die wenigsten Plugins betrifft – eigentlich nur Filebrowser-Plugins.

Der CKEditor kann auch in einem DIV laufen. […]

Ah, danke! Vielleicht solltest Du das divarea Plugin mit in die Distro packen?