Redactor settings in Profilen anpassen

[rbergm]

Dieser PR ermöglicht die Anpassung der verschiedenen Redactor Settings (https://imperavi.com/redactor/docs/settings/) direkt in Profilen.

Dafür wird der Profil-Dialog um ein zusätzliches Eingabefeld erweitert, in dem sich die verschiedenen Settings als key: value Paare angeben lassen. Settings werden dabei durch Zeilenumbrüche getrennt. Über eine einfache Datentyp-Erkennung wird versucht, den korrekten Typ des Settings in die JS-Datei zu übernehmen. Unterstützt werden dabei boolsche Werte, Fließkomma- und Integerzahlen, Strings, sowie Listen aus Strings.

Ein Sonderfall ist das pasteImages Setting. Da hierfür in der aktuellen Version des Editors standardmäßig false gesetzt wurde, wird diese Einstellung erstmal beibehalten. Wird pasteImages allerdings explizit angegeben, überschreibt es die Standardeinstellung.

Beispielkonfiguration:

pastePlainText: true
markup: div
preSpaces: 2

Versionsnummern oder Update-Routinen habe ich erstmal bewusst außen vor gelassen, da ich hier euer Standardvorgehen nicht kenne.

[tbaddade]

Danke dir für den PR.

Die Settings hatte ich bisher hier abgelegt https://github.com/FriendsOfREDAXO/redactor/blob/master/package.yml#L36

Da könntest du die Einstellungen mit den Optionen dann mergen.

Aber ich frage mich grad, ob man das denn wirklich pro Profil benötigt?

[rbergm]

Die Settings hatte ich bisher hier abgelegt https://github.com/FriendsOfREDAXO/redactor/blob/master/package.yml#L36

Da könntest du die Einstellungen mit den Optionen dann mergen.

Für die Settings in der package.yml hatte ich keine Anweisungen gefunden, mit denen sie tatsächlich in die Profile übernommen werden bzw. bei der Erstellung des Editors eingelesen werden. Gibt es dafür schon eine Implementierung - und ich habe sie nur übersehen - oder fehlt der Code dafür tatsächlich noch? Davon unabhängig kann ich die package.yml aber gerne noch einbinden. Ich sehe dafür jetzt drei grundsätzliche Möglichkeiten:

1. die Settings aus der package.yml werden als Standardwerte für neue Profile gesetzt und können danach frei überschrieben werden
2. die Settings aus der package.ymlergänzen die Settings aus dem Profil und dienen als "Basiseinstellungen". Wenn das Profil also bspw. pastePlainText nicht spezifiziert, aber in der package.yml ein entsprechender Wert existiert, wird der übernommen. Umgekehrt, wenn das Profil einen anderen Wert als die package.yml setzt, wird der Wert aus dem Profil genutzt
3. die Settings aus dem Profil ergänzen die package.yml (Umkehrung von 2.). Wenn im Profil also zusätzliche Einstellungen auftauchen, werden die als Ergänzung genommen, die Settings der package.yml bleiben aber unangetastet.

Spontan würde ich zu Variante 1 oder 2 tendieren.

Aber ich frage mich grad, ob man das denn wirklich pro Profil benötigt?

Mich hat folgendes Szenario zu dem PR motiviert: bestimmte Nutzer sollten unterschiedliche Featuresets für den Editor zur Verfügung gestellt bekommen. Einfache Redakteure sollten bspw. nur reinen Text einfügen können (pastePlainText: true), da sie sonst aus Word o.ä. voformatierten Text übernehmen und das Styling der Webseite untergraben. Andererseits gibt es auch Nutzer, denen da durchaus vertraut werden kann und für sie ist es dann hinderlich, alle Formatierungen manuell neu einzufügen. Ähnliches gilt für Bilder oder Links.

Wenn der Editor für verschiedene Addons genutzt wird, ist es auch nützlich, einzelne interne Komponenten detailliert anzupassen - bspw. um für Textabsätze statt dem standard <p> Tag ein <p class="fancy-addon-text"> zu nutzen. Das geht aber nur, wenn die Settings tatsächlich pro Profil eigenständig sind und das Addon dann sein spezifisches Profil nutzt.

[tbaddade]

Könntest du den PR so ändern, dass die Default Optionen nicht mit in das Profil übernommen werden. Das könnte in Zukunft eine sehr lange Liste und dadurch sehr unübersichtlich werden.

[rbergm]

Das kann ich gut nachvollziehen. Aber gibt es nicht auch Fälle, wo Default-Optionen gewünscht sind? Bspw. könnte man ja einige Standard-Settings haben, die immer angewendet werden sollten (bspw. nur Text einfügen). Dann wäre es unpraktisch, diese Settings jedes Mal wieder zu spezifizieren. Andererseits könnten Plugins natürlich auch wollen, dass "diese und keine anderen" Settings eingestellt werden. Vielleicht könnte man auch noch eine Schlatfläche wie "Standardsettings importieren" ergänzen, über die das Verhalten explizit ein- bzw. ausgeschalten werden kann?

EDIT: oder meintest du den Kommentar so, dass die Settings nur in der Anzeige nicht erscheinen, beim Erstellen des Profils dann aber wieder berücksichtigt werden?

[alxndr-w]

Ich hätte wegen #40 Interesse daran, diesen PR zum Abschluss zu bringen.

Was kann ich tun, um dies voranzutreiben?

[alxndr-w]

Ich würde dann am 13.06.2022 (in 2 Tagen) mergen, falls das Repo nicht mehr aktiv betreut wird.

[rbergm]

Ich habe die vorgeschlagenen Änderungen jetzt übernommen. Allerdings ist es jetzt ja schon eine ganze Weile her seit der PR ursprünglich aufgemacht wurde und ich hänge nicht mehr 100% in der Implementierung drin. Es wäre also super, wenn ihr hier auch nochmal drüber schaut. Und mit genügend zeitlichem Abstand muss ich auch sagen, dass die Implementierung des Settings-Parser nicht sonderlich sauber ist und vermutlich missbraucht werden kann. So lange die package.yml als vertrauenswürdig gilt, sollte das aber kein Problem sein.

[alxndr-w]

"I Was Today Years Old..."

@rbergm ich konnte mich jetzt in einer ruhigen Stunde mit deinem PR beschäftigen, weil ich eigene Einstellungen setzen können möchte. Hab vielen Dank für den PR von damals.

Ich habe die Einstellungen getestet und festgestellt, dass die Default-Einstellungen der package.yml die eigenen Settings im Profil überschreiben - entsprechend habe ich die Reihenfolge umgedreht: Erst defaults, dann eigene Einstellungen überschreiben können. So ergibt das für mich mehr Sinn, denn die package.yml des Addons wird schließlich nicht von Nutzern angepasst.

Außerdem habe ich codemirror hinzugefügt, für die, die das über be_style/customizer aktiviert haben.