CKEditor statt tinyMCE nutzen

[NinaG]

Es wäre schön, wenn du dir mal als Alternative zum tinyMCE den CKEditor anschaust: http://www.ckeditor.com/

Im Gegensatz zum tinyMCE ist der CKEditor in Bezug auf Barrierefreiheit sehr fortschrittlich und ist größtenteils auch z. B. von blinden Nutzern bedienbar. Allgemein scheint er auch den saubereren Code zu produzieren (der tinyMCE kommt gerne total durcheinander, wenn Redakteure mehrere Arbeitsschritte durchführen oder korrigieren).

Der CKEditor hat auch eine geeignete Open Source Lizenz.

Related issues: #2187

--- Originally created on February 2nd, 2010, at 11:25pm (ID 1495)

[leofeyer]

Ich habe inzwischen schon mal reingeschaut, konnte aber nicht erkennen, dass die Ausgabe des Editors so viel besser ist. Die Barrierefreiheit ist sicherlich ein gutes Argument, allerdings weiß ich nicht, ob es die vielen Anpassungen aufwiegen kann, die wir über die Jahre am TinyMCE vorgenommen haben. Ich werde es aber auf jeden Fall prüfen.

--- Originally created on February 2nd, 2010, at 11:45pm

[tristanlins]

Hi leo, ich habe mal in den Quellcode geschaut, es dürfte doch relativ einfach sein, den Editor einfach austauschbar zu machen.

In der BackendTemplate.php wird der Editor eingebunden (Snippet aus 2.8.RC2):

68.     // Rich text editor configuration
69.     if (count($GLOBALS['TL_RTE']) && $GLOBALS['TL_CONFIG']['useRTE'])
70.     {
71.         $this->base = $this->Environment->base;
72.         $this->brNewLine = $GLOBALS['TL_CONFIG']['pNewLine'] ? false : true;
73.         $this->rteFields = implode(',', $GLOBALS['TL_RTE']['fields']);
74.
75.         $strFile = sprintf('%s/system/config/%s.php', TL_ROOT, $GLOBALS['TL_RTE']['type']);
76.
77.         if (

![](file_exists($strFile))
78.         {
79.             throw new Exception(sprintf('Cannot find rich text editor configuration file "%s.php"', $GLOBALS['TL_RTE']['type']));
80.         }
81.
82.         $this->language = 'en';
83.
84.         // Fallback to English if the user language is not supported
85.         if (file_exists(TL_ROOT . '/plugins/tinyMCE/langs/' . $GLOBALS['TL_LANGUAGE'] . '.js'))
86.         {
87.             $this->language = $GLOBALS['TL_LANGUAGE'];
88.         }
89.
90.         ob_start();
91.         include($strFile);
92.         $this->rteConfig = ob_get_contents();
93.         ob_end_clean();
94.     }

Ist es nicht schon so, dass man den Editor prinzipiell austauschen könnte, wenn der Eintrag für die Sprache nicht da wäre? Könnte man die Zeilen 84-88 nicht in die Konfigurationsdatei auslagern? Das einbinden des passenden JavaScript Codes findet doch bereits in der config/tinyMCE.php Datei statt. Warum sollte man nicht auch die Sprachauswahl einfach da rein legen?

Danach wird es aber nochmal kompliziert, in den DCA's ist überall 'rte'=>'tinyMCE' im eval Feld eingetragen. Sinnvoll wäre hier eventuell, den Wert über das globales Konfigurationsarray zu holen, z.B.: 'rte'=>$GLOBALS['TL_CONFIG']['RTE'] danach ließe sich der Editor einfach per Konfiguration austauschen.

Dann hätten wir aber noch das Problemkind $GLOBALS['TL_RTE']['type'], welches ja nur einen Wert hält. Meine einzige Idee wäre es, dass Feld in ein Array um zu wandeln. Die Klasse TextArea ist die einzige, die dieses Feld beschreibt, dass dürfte also kein all zu großes Problem darstellen:

100.  // Register field name for rich text editor usage
ff    if (strlen($GLOBALS['TL_DCA'][$this->strTable]['fields'][$this->strField]['eval']['rte']) && $GLOBALS['TL_CONFIG']['useRTE'])
      {
          if ()isset($GLOBALS['TL_RTE'][$this->rte]))
              $GLOBALS['TL_RTE'][$this->rte] = array();
          $GLOBALS['TL_RTE'][$this->rte][] = 'ctrl_' . $this->strId;
      }

Jetzt werden die Felder zu den jeweiligen RTE's zugeordnet. Damit ließe sich sogar 2 oder mehr unterschiedliche RTE's gleichzeitig nutzen.

Bei einem bin ich mir aber nicht ganz sicher, worin besteht der Unterschied zwischen $GLOBALS['TL_DCA'][$this->strTable]['fields'][$this->strField]['eval']['rte'] und $this->rte ?

--- Originally created on February 14th, 2010, at 01:12pm

[leofeyer]

Die Einbindung des Editors ist sicherlich das kleinste Problem. Es geht um die vielen Anpassungen und nicht zuletzt das TinyMCE-Plugin "typolinks", die über die Jahre vorgenommen wurden. Mit einem neuen Editor würden wir bei Null anfangen.

--- Originally created on February 14th, 2010, at 01:23pm

[NinaG]

Mit einem neuen Editor würden wir bei Null anfangen.

Das wäre sicher nochmal ein erheblicher Aufwand. Da wir uns die Barrierefreiheit aber auf die Fahnen schreiben, wäre es imho schon eine sehr gute Sache. Die Benutzbarkeit des Backends leidet halt enorm, wenn man den tinyMCE ausschalten muss, weil er für den z. B. blinden Nutzer nicht bedienbar ist.

--- Originally created on February 18th, 2010, at 12:00pm

[leofeyer]

Es ist ja nicht so, dass TinyMCE nicht barrierefrei wäre. Zumindest behaupten das die Entwickler

--- Originally created on February 18th, 2010, at 12:12pm

[NinaG]

Es ist ja nicht so, dass TinyMCE nicht barrierefrei wäre. Zumindest behaupten das die Entwickler

Sie behaupten viel, wenn der Tag lang ist. Ich habe es aber z. B. mit mehreren blinden Nutzern getestet, die meinten, dass es mit seiner Barrierefreiheit nicht weit her ist.

Ich werde noch mal konkret recherchieren und für dich auflisten, welche Punkte problematisch sind. Dann könnten wir darauf basierend nachforschen, ob sich diese Probleme innerhalb vom tinyMCE für uns korrigieren lassen.

--- Originally created on February 18th, 2010, at 12:41pm

[leofeyer]

Eine gute Idee. Vielleicht ist es ja tatsächlich weniger Arbeit, den TinyMCE anzupassen, als einen komplett neuen Editor mit allen zusätzlichen Plugins und Features auszustatten. Außerdem ist die Barrierefreiheit vielleicht auch für die TinyMCE-Entwickler interessant.

--- Originally created on February 18th, 2010, at 12:43pm

[NinaG]

Eine gute Idee. Vielleicht ist es ja tatsächlich weniger Arbeit, den TinyMCE anzupassen, als einen komplett neuen Editor mit allen zusätzlichen Plugins und Features auszustatten. Außerdem ist die Barrierefreiheit vielleicht auch für die TinyMCE-Entwickler interessant.

Ich habe dazu im Forum einen Thread aufgemacht, da vielleicht auch andere Lust haben eine Anmerkung dazu zu machen oder an Lösungsfindungen beteiligt zu sein. http://www.typolight-community.de/showthread.php?t=6564

Heute schaff ich es vermutlich nicht mehr, dort mit den ersten Infos anzufangen, aber ich hab es auf meiner ToDo-Liste

--- Originally created on February 18th, 2010, at 01:19pm

[ghost]

http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.config.html Very flexible editor.

@config.forcePasteAsPlainText = true;@ THE BEST! :)

when CK editor appears in Contao?

ps Feature #2187 - my

--- Originally created by Energetik on August 2nd, 2010, at 02:33pm

[ghost]

Will CKEditor be included into the core or is this ticket cancelled?

--- Originally created by lonka on October 24th, 2011, at 05:19pm

[psi-4ward]

Da hats mittlerweile die erste Beta des TinyMCE_Customizers, damit kann man eigentlich nur TinyMCE Konfigurationen erstellen aber es wäre relativ leicht das Modul so aufzubohren, dass es auch beliebige andere Editoren unterstützt. Die Komplexität liegt hier eher in der GUI zur Anpassung des neuen Editors sowie der Integration von Bild- und Dateibrowsern für Contao.

Wenn hier genug Interesse besteht, fasse ich das Thema gerne ins Auge.

[xchs]

Raptor Editor: Ein interessanter neuer WYSIWYG HTML5 Editor, den man sich vielleicht auch mal anschauen könnte:

• http://www.raptor-editor.com/
• http://www.raptor-editor.com/demo
• https://github.com/PANmedia/Raptor

Lizenzierung: GPL

---

Okay, sehe gerade, dass hierfür wohl jQuery notwendig wäre. Dann wird das wohl nichts fürs Backend.

[leofeyer]

Auch GPL ist leider ein KO-Kriterium :(

[tristanlins]

@leofeyer wieso wäre das ein KO Krieterium? Du kannst ihn ohne Veränderungen ja trotzdem verwenden. Durch die reine "Verwendung der Binary" wird das Copyleft ja nicht erzwungen.

[leofeyer]

Nein, so einfach ist es leider nicht. Wird auch nur ein einziges GPL-Programm mit dem Core zusammen ausgeliefert, stünde automatisch der ganze Core unter GPL. Man könnte höchstens eine Extension anbieten, die sich die Nutzer bei Bedarf installieren (die Extension selbst kann unter GPL stehen und für den Endnutzer, der nur nutzt und nicht verbreitet, spielen Inkompatibilitäten kein Rolle).

[tristanlins]

mh, wenn du eine Library mit auslieferst, muss doch nicht gleich das ganze Programm unter der GPL stehen? Es muss nur bekannt gemacht werden, welche Libraries mitgeliefert werden und unter welcher Lizenz sie stehen. Das mit der Code veröffentlichung ist bei PHP sowieso egal, der ist ja immer dabei ;-) Das Problem ist glaube ich nicht das Ausliefern, sondern das du die Libs auch immer in das github Repo mit rein packst. Wenn du hier z.B. als git submodule die Libraries extern beziehen würdest, dann verhällt es sich imo mit den Vendor Libraries genau so wie mit den Extensions.

[leofeyer]

mh, wenn du eine Library mit auslieferst, muss doch nicht gleich das ganze Programm unter der GPL stehen?

Doch, das ist leider so. Daran besteht nach mehrfachen Rechtsberatungen und Diskussionen mit der FSFE kein Zweifel.

Wenn du hier z.B. als git submodule die Libraries extern beziehen würdest, dann verhällt es sich imo mit den Vendor Libraries genau so wie mit den Extensions.

Das müsste man abklären. Die Frage stellt sich nämlich dann auch für Pakete, die über Composer+Packagist als Abhängigkeit definiert und installiert werden.

[tristanlins]

Doch, das ist leider so. Daran besteht nach mehrfachen Rechtsberatungen und Diskussionen mit der FSFE kein Zweifel.

Ja hast recht, dieses verdammte strong copyleft ^^

Die Frage stellt sich nämlich dann auch für Pakete, die über Composer+Packagist als Abhängigkeit definiert und installiert werden.

Wie wäre es, wenn der Installer die notwendigen Pakete nachinstalliert? Dann vertreibst du kein Contao Paket mit den GPL Libraries, sondern nur das Plain Contao und die Libraries werden adhoc beim installieren gezogen? Wäre das eventuell eine Alternative für die Zukunft?

[leo-unglaub]

Ich verstehe das Problem nicht ganz. Der Editor liegt doch eh unter einer Dual-Lizenz vor. Damit man eben nicht in dieses Problem läuft.

@tristanlins: Von wegen "verdammtes strong copyleft". Das ist Gold wert!

[leofeyer]

Wie wäre es, wenn der Installer die notwendigen Pakete nachinstalliert? Dann vertreibst du kein Contao Paket mit den GPL Libraries, sondern nur das Plain Contao und die Libraries werden adhoc beim installieren gezogen?

Wenn das so rechtlich vertretbar ist, wäre das auf jeden Fall eine Alternative. Allerdings kann ich es mir kaum vorstellen, immerhin könnte man so jede beliebige Lizenz aushebeln :)

[Zeromax]

Zur Info: Es gibt eine Tinymce 4.0 Version (http://www.tinymce.com/). Habe es natürlich gleich mal in Contao eingebunden :D

Die Änderungen sind schon gravierend. Es muss Das Plugin angepasst werden, da sich die Api stark verändert hat. Der Filebrowser welcher auf tinymce vorgeführt wird kostet auch etwas sieht aber schick aus...

Der Tinymce basiert nun komplett auf HTML5. ob er besser ist wie die 3er version bleibt abzuwarten. Ebenso ist auch die Dokumentation noch nicht vollständig, so ist manches noch in bisschen im dunkeln tappen.

[fbender]

TinyMCE 4.0.17 hat massive Fortschritte bei der Accessibility gemacht, habe ein Ticket für's Update eröffnet: #6769.

[leofeyer]

TinyMCE 4 ist ohne Frage deutlich besser als die Version 3, aber das neue Theme integriert sich irgendwie nicht so richtig ins Backend finde ich:

Zum Vergleich das alte Theme:

Irgendwelche Ideen, wie wir das vielleicht optimieren könnten?

[tristanlins]

Ich finde es nicht ganz so kritisch, aber vielleicht nimmt man einfach ein anderes Theme / entwickelt ein eigenes Theme / passt das Standardtheme etwas an?!

[frontendschlampe]

Also ich finde, das Theme passt durchaus ins Backend. @leofeyer das ist nur die Gewohnheit an den alten Editor. Nach zwei Wochen merkt man nix mehr davon! Und wenn es Verbesserungen bringt, warum nicht?!

[Toflar]

Ich finde das auch vernachlässigbar :) Form follows function. :)

[fbender]

Ehrlich gesagt halte ich es vorher wie nachher für einen Fremdkörper, sehe also auch keinen zwingenden Grund am Theme was zu ändern. Man könnte höchstens den Verlauf der Buttonleiste durch eine einfache Farbe (oder einen einfacheren verlauf) ersetzen, aber das sollte ja mit 1-2 Zeilen CSS machbar sein ;).

[leofeyer]

Hab den Feature-Branch in eac953fef1f6b93cab320316b3696b4b1a6ed2bd mit dem develop-Zweig zusammengeführt. Der Commit stellt den Status-Quo wieder her, d.h. alle bisherigen Funktionen aus TinyMCE 3.5 sind nun auch – soweit von TinyMCE 4 noch unterstützt – in TinyMCE 4 verfügbar.

[Toflar]

Coole Sache!

[xchs]

Super! Sieht doch schon ganz gut aus.

Wenn man bei den Buttons (.mce-btn) die Hintergrundfarbe (background-color: #F0F0F0;) entfernt, würde es auch nicht schlecht aussehen und sich m.E. recht gut in das derzeitige Backend-Theme integrieren:

[xchs]

Vielleicht könnten wir auch noch den Shortcut für die Vollbildansicht von Ctrl+Alt+F auf F11 umändern. Dann nämlich hätten wir in allen Editoren (TinyMCE, ACE) einen einheitlichen Shortcut und man bräuchte sich keine unterschiedlichen Tastenkombinationen zu merken. Auch die Vollbildansicht vieler Webbrowser wird meist über die F11-Taste aktiviert/deaktiviert.

[xchs]

In den Artikel-Einstellungen wird der TinyMCE für den "Teasertext" nicht in voller Breite angezeigt:

[leofeyer]

Behoben in 785049600bc53d3431f3a6877d178430ba7a9fd5.

[ESchuderer]

Nun da die vielen Anpassungen am TinyMCE ohnehin verflogen sind, bietet sich vielleicht doch ein Wechsel zum CKEditor an? Der CKEditor bietet imho deutlich mehr Flexibilität (z.B. image oder image2).

Ein Artikel hierzu: http://www.krizalys.com/article/ckeditor-vs-tinymce

[zonky2]

Hi,

die Frage on TinyMCE(4) oder CKE oder ein anderer Editor würde sich u.a. daran ausmachen, wie flexibel der Edito anpassbar ist. Per se ist aktuell bei keinem der beiden Editoren es z.B. vorgesehen eine CSS-Klasse oder ein data-Attribut beim Einfügen eines Bildes, Tabelle, UL, DIV..... einzufügen.

Ein echtes Manko!

[ESchuderer]

Der CKEditor bietet derartige Funktionen an, würde mich wundern wenn es beim tinymce nicht genauso ist.

[Aybee]

@InitArt Der CKEditor bietet derartige Funktionen an, würde mich wundern wenn es beim tinymce nicht genauso ist.

Für den TinyMCE scheint es da noch kein Plugin für zu geben. http://www.tinymce.com/develop/bugtracker_view.php?id=7495

Irgendwo habe ich gelesen, dass es das für den CKEditor auch nicht gibt.

Man müsste also abwarten, oder selber ein Plugin schreiben. Die API scheint alle notwendigen Methoden zu besitzen.

Ich würde diese Funktionen (Felder) auch nicht auf die vorhandenen Plugins aufsetzen, sondern allgemein ein Plugin haben wollen, welches mir die Möglichkeit bietet auf jedes HTML-Element Attribute aufzusetzen.

@xantippe Eine Klasse kannst du mit dem Format-Menü aufsetzen. Ich arbeite gerade daran die TinyMCE.php dahingehend anzupassen, dass das Format und die Klassenauswahl wieder direkt als Select in der Menüleiste auftaucht. Bin auch schon fast fertig, ein paar Eigenarten gefallen mir allerdings noch nicht.

...
toolbar: "...formatselect | styleselect | removeformat...",
...
block_formats: ...
style_formats: ...

[zonky2]

o.k. bin gespannt...

[Aybee]

bitte ausprobieren https://github.com/contao/core/issues/7810