Editor-Klasse aus den Einstellungen wird nicht verwendet

[iceman-fx]

Beim Versuch den CKE4 als Editor anzugeben, wird diese Definition nicht dem Textarea-Feld zugewiesen.

Einstellungen > Editor: class="ckeditor" data-ckeditor-profile="default"
Beiträge > Neuer Eintrag: <textarea class="form-control" name="FORM[data_edit-rex_neues_entry][6]" id="yform-data_edit-rex_neues_entry-field-6" rows="10"></textarea>

Redaxo: 5.18.1
Neues: 6.0.0

[alxndr-w]

@christophboecker könntest du mal nachsehen? Sich früher einzuklinken, ist gut, aber scheinbar funktioniert er nicht ordnungsgemäß:

https://github.com/FriendsOfREDAXO/neues/blame/c0ec522020b0e72323bbd3e4ef0a1bdd1fc61d9b/lib/Entry.php#L55-L67

Es wird nur form-control ausgegeben.

[crydotsnake]

@christophboecker könntest du mal nachsehen? Sich früher einzuklinken, ist gut, aber scheinbar funktioniert er nicht ordnungsgemäß:

https://github.com/FriendsOfREDAXO/neues/blame/c0ec522020b0e72323bbd3e4ef0a1bdd1fc61d9b/lib/Entry.php#L55-L67

Es wird nur form-control ausgegeben.

Meine Vermutung ist, das er es nicht verarbeiten kann weil $e[5] kein einfacher String ist, sondern ein JSON-String. Denn wenn man sich $e[5] mit dump() ausgibt, bekommt man die Ausgabe:

"{"class":"class="form-control markitupEditor-markdown_full""}"

[crydotsnake]

Ich habe die getForm()-Funktion testweise so umgeschrieben, dass der Wert in $e[5] zuerst mit json_decode() in ein Array umgewandelt wird. Anschließend wird der Platzhalter ###neues-settings-editor### in der "class"-Eigenschaft durch den Wert aus rex_config::get('neues', 'editor') ersetzt. Zum Schluss wird das Array mit json_encode() wieder in einen JSON-String umgewandelt.

Das hätte aber zur folge, das man bei denn Einstellungen denn Editor ohne das class="" angeben muss.
Auch in der package.yaml in der default_config müsste man: editor: 'class="form-control redactor-editor--default"' abändern zu editor: 'form-control redactor-editor--default'

[alxndr-w]

Das "Problem" ist, dass Editoren wie CKE5 noch mehr Attribute mitbringen als bspw. Redactor, genauso grundsätzlich Codemirror.

Bspw.: class="form-control cke5-editor" data-profile="default" - deshalb wollte ich hier die Flexibilität schaffen, weitere Attribute mitzugeben. Man könnte natürlich auch Attribute im JSON-Format angeben bis hin zu einem Callback, um bspw. auch Dinge zu ermöglichen wie <textarea class="form-control cke5-editor" data-profile="default" data-lang="<?php echo \Cke5\Utils\Cke5Lang::getUserLang(); ?>"> (User-Sprache mitgeben, oder Datensatzsprache angeben).

Mein Vorschlag, class="xyz" weiteresattribut="weiteresvalue" zuzulassen, wäre der Kompromiss.

[crydotsnake]

Das "Problem" ist, dass Editoren wie CKE5 noch mehr Attribute mitbringen als bspw. Redactor, genauso grundsätzlich Codemirror.

Bspw.: class="form-control cke5-editor" data-profile="default" - deshalb wollte ich hier die Flexibilität schaffen, weitere Attribute mitzugeben. Man könnte natürlich auch Attribute im JSON-Format angeben bis hin zu einem Callback, um bspw. auch Dinge zu ermöglichen wie <textarea class="form-control cke5-editor" data-profile="default" data-lang="<?php echo \Cke5\Utils\Cke5Lang::getUserLang(); ?>"> (User-Sprache mitgeben, oder Datensatzsprache angeben).

Mein Vorschlag, class="xyz" weiteresattribut="weiteresvalue" zuzulassen, wäre der Kompromiss.

👍🏼

[christophboecker]

Vielleicht bin ich ja komplett auf ner anderen Rille unterwegs .... aber wenn ich im AttributFeld notiere ´{"class":"###neues-settings-editor###"}` dann muss auch im ConfigEintrag "Neues|Editor" ein dazu passender String stehen. Wenn das schon formal nicht zusammenpasst, dann kracht es. Das hat nix damit zu tun, dass die Logik in getForm fehlerhaft ist.

In dem Fall würde (ungetestet, aber nicht unlogisch) ein Config-Eintrag form-control markitupEditor-markdown_full funktionieren. Sogar ein Hack würde klappen: form-control markitupEditor-markdown_full", "noch-was":"xyz würde auch einen validen JSON-String. Aber sowas wieclass="form-control markitupEditor-markdown_full" einzufügen, ergibt eben kein gültiges JSON bzw. führt zu unerwarteten Attributen im HTML.

Alternativ einfach nur ###neues-settings-editor### als Attribut eintragen und das gesamte JSON in "Neues|Editor" hinterlegen. Dann aber bitte sauberes JSON und nicht class=..... Attribute müssen ein valider JSON-Stringg sein, hab ich mal gelernt.

Oder vergiss das mit ###neues-settings-editor### und trag alles klassisch ein. Dann steht halt bei X Feldern zu 95% dasselbe.

[christophboecker]

... bis hin zu einem Callback, ...

Sehe ich anders. Die Callback-Methode muss ja irgendwo "gelagert" sein. Wo bitte, in welcher Klasse dockt man die an?

Mein Vorschlag ist eher, konsequent auf Modell-Classes zu setzen. Immer. Ohne Ausnahme. Wenn YForm-Tabelle, dann via ModelClass. Und dann brauche ich auch keinen Callback mehr, denn es gibt ja ModellClass::getForm. Dann wird der Attribut-Json halt auch mit aktuellen, variablen Werten on the fly aufgebaut und JSON-Encoded in das Feld geschoben.

Es ist doch so viel schon da, man muss nur kreativ nutzen.

(Das ist keine Kritik, nur ein Appell)

[alxndr-w]

Mir geht's im Endeffekt nur darum, dass auch Nutzer anderer Editoren leicht auf ihre Kosten kommen.

Oder vergiss das mit ###neues-settings-editor### und trag alles klassisch ein. Dann steht halt bei X Feldern zu 95% dasselbe.

Da das Tableset beim Import aktualisiert wird, scheidet diese Idee aus. Das wäre nicht updatesicher.