2.11.x bug: can't use different 'rte' for two fields in one DCA

[Serhii-DV]

Here is the problem.

In dcaconfig.php I rewrite rte eval property for News and Calendar modules. Example:

<?php
$GLOBALS['TL_DCA']['tl_news']['fields']['teaser']['eval']['rte'] = 'tinySimple';
$GLOBALS['TL_DCA']['tl_news']['fields']['text']['eval']['rte'] = 'tinyCustom';

In this case I expected to see for News field teaser tinyMCE config from tinySimple.php file and for text field - from tinyCustom.php file. But Contao loads only the last tinyCustom for this two fields. If to change previous code to this:

<?php
$GLOBALS['TL_DCA']['tl_news']['fields']['teaser']['eval']['rte'] = 'tinyCustom';
$GLOBALS['TL_DCA']['tl_news']['fields']['text']['eval']['rte'] = 'tinySimple';

then Contao will load only tinySimple config for this two fields.

The same will happen if to make changes in news/dca/tl_news.php file:

<?php

        'teaser' => array
        (
            'eval' => array('rte'=>'tinySimple', 'tl_class'=>'clr')
        ),
        'text' => array
        (
            'eval' => array('rte'=>'tinyCustom', 'helpwizard'=>true),
        ),

So, the problem is in that we can't use different tinyMCE configs in one table DCA.

[psi-4ward]

Damn, i thought we fixed this bug in ... contao 2.8?

[leofeyer]

I don't remember that we had fixed it or ever planned to fix it. I don't think it would work with the current implementation, either.

[Serhii-DV]

So, if this is not a bug, then I would like that it will became a feature request.

[psi-4ward]

Also ich hab #2536 gefunden und laut diesem Ticket sollte das funktionieren.
@leofeyer wenn du magst schau ich mir das nochmal genauer an und würde dir nen Pullrequest vorbereiten - verschiedene RTEs innhalb eines DCAs halte ich für wichtig! Nicht nur um TinyMCE configs anzupassen sondern eher noch um andere Editoren wie den CodeMirror einzubinden.

[leofeyer]

wenn du magst schau ich mir das nochmal genauer an und würde dir nen Pullrequest vorbereiten

Sehr gerne, vielen Dank :)

[psi-4ward]

Das Problem liegt im DataContainer, hier wird ein <script>tinyMCE.execCommand('mceAddControl', .... ausgeliefert, was die Ersetzung der textarea bewirkt. An dieser Stelle kann nicht mehr Unterschieden werden welche Editor-Config verwendet werden soll.
Siehe auch den Bug http://www.tinymce.com/develop/bugtracker_view.php?id=5125

Lösung:
Wir initialisieren den TinyMCE nicht mehr per execCommand sondern mit dem TinyMCE-Parameter mode=exact in der tinyMCE.php
Nachteil: Ich vermute damit wird der TinyMCE nicht mehr per AJAX (Subpaletten) funktionieren.

Ggf. könnten wir nur für Subpaletten den execCommand-Befehl ausliefern und somit zumindest das Problem im Umfeld von Hauptpaletten lösen.

[aschempp]

Genau wegen den Ajax-Subpaletten haben wir das "exact" geändert. Sprechen wir denn von zweinTinyMCE configs oder einem anderen Editor? Gehen überhaut zwei tinyMCE parallel?

[psi-4ward]

Du kannst auf einer Seite beliebig viele tinyMCE Instanzen mit jeweils einer speziellen Config betreiben (theoretisch).

Ich hätte das schon öfters gebraucht:

• Teaserfeld: sehr spartanischen TinyMCE
• Content: volle Funktionalität

[leofeyer]

Bezüglich Deiner Lösungsidee: Welche TinyMCE-Konfiguration würde denn geladen, wenn eine Subpalette execCommand aufruft und es mehrere Konfigurationen gibt?

[aschempp]

das würde vermutlich über die (globale) Variable definiert, welche angesprochen wird?

[psi-4ward]

Ich hab eine Idee

1. tinyMCE.init() in eine Funktion kapseln (contao/config/tinyMCE.php)

if(typeof TinyMceCfg == 'undefined') var TinyMceCfg = [];
TinyMceCfg['tinyMCE_standard'] = function()
{
    tinyMCE.init({
    mode : "none",
    ....
}

if(typeof TinyMceCfg == 'undefined') var TinyMceCfg = [];
TinyMceCfg['tinyMCE_reduced'] = function()
{
    tinyMCE.init({
    mode : "none",
    ....
}

1. Vor jedem tinyMCE.execCommand('mceAddControl' laden führen wir das entsprechende TinyMceCfg.init aus. (DataContainer.php Z.421)

            $updateMode = "\n  <script>TinyMceCfg['".$arrData['eval']['rte']."'](); tinyMCE.execCommand('mceAddControl', false, 'ctrl_".$this->strInputName."');$('ctrl_".$this->strInputName."').erase('required');</script>";

Natürlich könnten wir das noch "schön" implementieren und uns merken welche init-config als letztes geladen wurde.
Funktionieren tut es, setze es gerade testweise ein.

Auf einen Bugfix bei TinyMCE direkt brauchen wir wohl nicht warten.

[aschempp]

if(typeof TinyMceCfg == 'undefined') var TinyMceCfg = [];

can be simplified as

var TinyMceCfg = TinyMceCfg || [];

[psi-4ward]

PS: Schaffen wir einen deartigen Fix in 2.11.7? Ansonsten würde ich einen Workaround in den TinyMCE_Customizer einbauen.

[psi-4ward]

Der TinyMCE_Customzer fixt das Problem durch eine proxy-Methode auf tinyMCE.execCommand(), siehe tinyMCE.php Template

Eventuell könnte man das auch so in den Core übernehmen.

[leofeyer]

Der korrekt Link ist: https://gist.github.com/4665046

[leofeyer]

We moved the ticket to the 4.0 release, because the changes needed to fix the issue will break backwards compatibility.

[leofeyer]

Die Lösung ist prinzipiell, den tinyMCE_GZ.init-Aufruf im Seiten-Head zu belassen und den tinyMCE.init-Aufruf immer vor dem tinyMCE.execCommand() auszuführen, der die Textarea in den TinyMCE umwandelt (siehe DataContainer.php).

[aschempp]

Sooo... hier eine vollständig rückwärtskompatible Implementation. Das Script muss lediglich unten in die tiny_mce_gz.js eingefügt werden.

EDIT: hab das in ein gist abgelegt: https://gist.github.com/4682480

[aschempp]

Ich habe das gist aktualisiert. Nun ist das Script nicht mehr abhängig von MooTools und sollte noch kompatibler mit eigenen tinyMCE-Befehlen sein.

[leofeyer]

Sieht super aus, aber mangels Kommentaren habe ich keine Ahnung, was Du da machst :D

[aschempp]

na ich dachte ich programmier das wie tinyMCE das macht ^^

[psi-4ward]

Sehr nice Andy ;) Aber schon bissle böse ^_^

[leofeyer]

Behoben in d8715b0. Großen Respekt für Deine Lösung!

[Babelfisch]

Leider aber nicht ohne Nebenwirkungen.

[aschempp]

Die da wären?

[Babelfisch]

Die da: #5346