Umstieg von Standard-Editor zu CKEditor vorbereiten

[Czorneboh]

Hallo miteinander,
hallo Timbalu!

eigentlich möchte ich schon zum CKEditor seit Deinem (@Timbalu) ersten großen Aufruf/der Eröffnung dieses Threads Ende Mai 2013 wechseln:

http://board.s9y.org/viewtopic.php?f=4& ... #p10438296

Ich hatte mir die Testseite vom CKE angesehen und bin vom den Möglichkeiten und dem Design dieses Editors angetan.

Die immer wieder neuen bösen Überraschungen, die Du beschreibst, ließen mich erst mal vom Wechsel Abstand halten. Das ist ja eine ziemlich komplexe Geschichte

Ich würde durch den Wechsel wohl den weißen Streifen unter dem Eintragsbereich auf allen statischen Seiten im Frontend verlieren und das Problem mit dem blockierten Eintragsfeld in der "simple templates"-Ansicht im Backend des Plugins "Statische Seiten".

(Problem war von Don gepostet worden, dem ich den Fehler im Backend gemeldet hatte.).
Gut, aber das Problem stört mich nicht so.

Wovon könnte ich mein System in der Folge des Wechsels zu CKE sonst noch befreien?
Es gibt anscheinend einige gegenseitige Beeinflussungen mit anderen Plugins?

Mit welchen (nach jetzigem Stand)?
Vielleicht lässt sich das zusammenfassend hier darstellen?

Welche der nachfolgenden (bei mir installierten) Plugins würden überflüssig, weil CKE deren Funktion mitübernimmt oder weil sich das Problem, zu dessen Kontrolle eines dieser Plugins dient, damit in Luft auflöst?

a) "Übliche XHTML-Fehler beseitigen"
b) "Sonderzeichen/Erweiterte Buttons für Non-WYSIWYG "
c) "Tooltips"
d) sonst noch welche?

Wechselwirkungen mit der Funktion "Rangordnung von Kategorie-Vorlagen" des Plugins "Eigenschaften/Templates von Kategorien" (z.Z. bei mir deaktiviert)?

Müsste ich möglicherweise Einstellungen im Plugin "Mediengalerie" ändern?
(Ich hatte in der Vergangenheit schon viel Ärger und/oder Arbeit mit den Bildern und will die nicht noch einmal ändern/anpassen müssen.).

Das Kinetic-Template verlangt als Idealmaß 608x456 Pixel. Für "Porträt" nehme ich 360x480 Pixel. Ich habe aber noch immer einige Bilder mit 480x360 Pixel in der Mediengalerie und in Artikeln integriert.

Beste Grüße
Czorneboh

[Timbalu]

Die immer wieder neuen bösen Überraschungen, die Du beschreibst, ließen mich erst mal vom Wechsel Abstand halten. Das ist ja eine ziemlich komplexe Geschichte

Ja, da ist halt ein Plugin was sich entwickelt. Zwischen den allgemeinen u. speziellen Anfordeungen an einen JS Editor und an S9y mit all seinen Möglichkeiten gab es halt einiges zu regeln, was nicht von vornherein klar war. Das wird sicher auch in Zukunft so sein, gilt aber für andere Editoren auch, nur dass sich da nicht immer jemand die Mühe gemacht hat diese Besonderheiten berücksichtigen zu wollen.

Ich würde durch den Wechsel wohl den weißen Streifen unter dem Eintragsbereich auf allen statischen Seiten im Frontend verlieren und das Problem mit dem blockierten Eintragsfeld in der "simple templates"-Ansicht im Backend des Plugins "Statische Seiten".

Ich habe keinen Schimmer was das erste sein soll, aber das zweite (wenn ich es richtig deute) wurde schon vor mind. 15 Monaten gelöst (Staticpages 3.99 glaube ich).

Welche ... Plugins würden überflüssig...?

Alle diejenigen, die bereits geschriebenes HTML nachträglich beinflussen wollen, davon insbesondere das NL2BR. Von den von dir genannten, wahrscheinlich außer c) keines. Das Besondere an einem JS Editor ist, dass ein JS-geschriebener Eintrag, quasi fertig - also wie ein Cache - im Gegensatz zu anderen Editoren - von Serendipity gespeichert wird. Das einzige Plugin was bisher(!) ganz und gar nicht geht, ist das "Speichern im Hintergrund" Plugin, aber das wurde im CKE Thread ausführlichst beschrieben, wenn ich mich recht erinnere.

Will man also neu anfangen und "für immer" bei einem JS Editor bleiben, sollte man body, extended body und nugget im NL2BR generell ausschalten, ansonsten, da etwas Variantenreicher für einen Mix der Systeme geeignet, jeweils bei einem Artikel über das entryproperties Plugin das NL2BR einzeln deaktivieren (ja, leider etwas umständlich, aber man kann sich daran gewöhnen) und bei den Staticpages den Knopf "Textformatierungen durchführen" auf Nein stellen. Du siehst schon hieran, dass ein Umstieg in einem bereits existierenden Blog Fragen aufwirft, wie man nun mit den alten Einträgen umgeht, "generell" oder "individuell"... was schon quantitativ oft ein Frage ist.

Ansonsten ist es manchmal eine Frage der Pluginreihenfolge, was aber nicht so sehr bei CKE vorkommt, sondern mehr bei textile und markdown der Fall ist. (Siehe meine verstreuten Bemerkungen in verschiedenen markup threads.)

Die Mediendatenbank sollte "keine" Beeinflussungen ergeben.

Ich kann daher nur raten es einfach auszuprobieren und solange man die Finger vom "Cachen aller Artikel" lässt (*), (da der Cache von entryproperties schwierig zu bedenken ist, speichert er doch eine bestimmte Situation einer bestimmten Zeit unter bestimmten Markup-Verhältnissen, ) sollte sich genügend Spielraum für einen intensiven Test (zb mit ein paar Drafts) ergeben.

Allerdings gilt die Regel, je komplizierter man "markup- und pluginmäßig" arbeitet, desto schwieriger ist es mit Automatismen. Unweigerlich gibt es Übergänge und Schwierigkeitsgrade, die man nur noch mit klarem Verstand abfangen kann. Andere Systeme sind da bestimmt restriktiver und simpler. Aber dafür hat man mit Serendipity ein höchst konfigurierbar arbeitendes Gerät mit einem gewissen Schuß an Genialität. Ein Gerät, mit dem man umgehen lernen muss.

(*) http://board.s9y.org/viewtopic.php?f=2&t=19336

[Timbalu]

Btw: Was genau meinst du mit Umstieg vom "Standard-Editor" ...?

Ein Wechsel innerhalb von JS-Editoren kann eigentlich nur Auswirkungen haben auf die eventuellen Erlaubnisbeschränkungen von "individuellem" HTML Markup (siehe ACF im CKEDITOR), bzw. anderen kleinen und feinen Unterschieden in der Annahme und Ausgabe von HTML. Willst du also zb. von Xinha nach CKEDITOR wechseln, musst du das selber untersuchen. Doch gilt eine gegenseitige mögliche Quellcode-Beeinflussung natürlich nur dann, wenn man ein altes Entry neu aufruft und abspeichert. Ansonsten nicht, da JS-Editoren DB Entry Einträge nicht per Abruf, sondern ausschließlich per Speichern verarbeiten.