Toolbar im TinyMCE definieren (Fullscreen im InsideE.)

[Oldperl]

Hallo,

ich finde die Lösung mit den config-Dateien für system- bzw. mandantenweite Einstellungen sinnvoller, zumal diese Einstellung ja eigentlich nur 1-mal gemacht werden und fertig.
Soll die Möglichkeit bestehen für jeden Benutzer seperate Einstellungen zu tätigen, ist eine Lösung über die DB sinnvoller.

Vielleicht sollte man das kombinieren, indem man im config-File einen Schalter (standard: false) setzen kann, und wenn dieser auf true steht zusätzlich eine Abfrage der DB durchläuft. Die if-Schleife macht den Bock auch nicht fett, aber wir überlassen es dann dem Admin wie er damit umgehen will.
Wichtig hierbei ist natürlich hierbei eine entsprechende Dokumentation dieses Features, ansonsten geht es irgendwann unter bzw. wird vergessen.

Gruß aus Franken

Ortwin

[idea-tec]

Und wenn man das Ganze nun ordentlich durchdenkt, könnte man das mit einem xml-file machen, welches man einliest und die werte in der $cfg mitführt.
dann bleibt auch alles kompatibel, man kann dran anschließen, man kann weiter entwickeln, z.B. könnte man in dem einen oder anderen Modul/Plugin darauf zugreifen, ohne Probleme kann man dann sogar Attribute für Plugins nehmen zur sprachgesteuerten Konfiguration, etc... und... und... und...

[Oldperl]

...könnte man das mit einem xml-file machen

Auch eine Idee, wobei ich hier kein xml nehmen würde. Das config-Array hat unbestritten den Vorteil, dass man es direkt verwenden kann. Das xml-File muss erst geparst werden. Dann kann man auch ein ini-File nehmen, auch dafür hat PHP eine gute Parsingfunktion, die einem sogar gleich ein assiozatives array zurück liefert.

Gruß aus Franken

Ortwin

[idea-tec]

Dann kann man auch ein ini-File nehmen, auch dafür hat PHP eine gute Parsingfunktion, die einem sogar gleich ein assiozatives array zurück liefert.

Das mag sein, ist aber eingeschränkt und "bremst" wieder aus. Wobei das parsen der xml-Datei pillepalle ist.
Reicht doch im Grunde auch, wenn man die nur 1x am Anfang parst, danach kann man eine einfach Abfrage auf einen definierten Wert legen, wie z.B. $xml->konfig->loaded == true. Das legt man in die $cfg[konfig][loaded]==false ... man parst, setzt auf true und gut ist, wenn true, dann nicht mehr parsen.
Ist doch ganz simpel.

Das XML-File hat den Vorteil, dass es schlicht ohne Probleme von jedem Modul-/Pluginentwickler "bestückt" werden kann, OHNE dass andere Funktionen beeinträchtigt werden, es ist UNendlich erweiterbar, es bleibt IMMER kompatibel und man hat eine nahezu unendliche Flexibilität. Man kann gezielt auf bestimmte Knoten zugreifen, man kann via Attributen Weichen erstellen, Mandanten, Sprachen, einfach alles ansteuern/unterscheiden.

Dies alles habe ich mit einem simplen "ini-File" alles nicht! Aber im Grunde ist es mir egal... Es ist nur ein Vorschlag.

[OliverL]

Ok, ich verstehe jetzt deinen ersten Post.
Und deine Einwände/Vorschläge sind plausibel.

der Ablauf müste dann so sein:
-------------------------------------------------------------------------------------------------------------------------------
System-Config: - Erstellt durch Contenido-Devs (contenido/includes/config.wysiwyg.php)
System-Config-Erweiterung: - Individual ( contenido/includes/config.local.php )
-- Alte System-Config als DB-Settings --
> gespeichert in $cfg

Client-Config-Erweiterung: - ndividual (cms/config.local.php)
-- Alte Client-Config als DB-Settings --
> gespeichert in $cfgClient

Das Zusammenführung der $cfg + $cfgClient + Be-User-Settings wird in der cTinyMCEEditor gemacht.
-------------------------------------------------------------------------------------------------------------------------------

Bei dem array würde ich anders vorgehen:
Deins:
$cfg['wysiwyg']['cms_htmlhead']['contenido_toolbar_mode'] = 'custom';
Meins:
$cfg['wysiwyg'][tinymce]['cms_htmlhead']['contenido_toolbar_mode'] = 'custom';
und
$cfg['wysiwyg'][tinymce]['cms_htmlhead_1']['contenido_toolbar_mode'] = 'custom';


Wenn in ...['cms_htmlhead'] kein Array ist wird der String wie meinen Set behandelt.

Ich würde noch eine Flag setzen wie bei der cfgClient[set] damit das System bei False alle Config-Strings in Array umwandeklt und BD-Eiträge ergänzt.
(Erspart unnötige DB-Abfragen wenn der Tiny nicht verwendet wird.)
Das ganze würde ich auslagern in eine privat Function für cTinyMCEEditor. Also als eigene Methode.
So ist für den Inside-Editor (der mehrfach aufgerufen wird) klar wann er noch die Daten mit den DB-Daten ergänzen muss.


Grüße
OliverL

[OliverL]

hi ho, hatte garnicht gesehen das wir schon auf der zweiten Seite sind .
sorry, Oldperl & idea-tec. Bin somit nicht auf eure Post eingegangen.

So:
XML kommt garnicht in frage. Mit den Files soll jeder klar kommen. Das ist mit XML leider nicht gegeben.
Für uns unverständlich, ist aber leider so. Und sovviele Parameter haben wir nicht das wir da wilde konstruckte machen müssen.

Variablen befüllen wie xmurrix es angesprochen hat finde ich sehr gut. Das kann jeder der ein CMS aufsetzen kann.
Mein Configfile durch ein Configfile das mit direkten PHP-Funktionen geparst werden kann finde ich auch gut (Man muss das Rad ja nicht neu erfinden).
Ortwin kannst du kurz runterschreiben wie der ablauf wäre? (nix was wirklich funktionieren muss / einfach aus dem Kopf)
Und wie sich der auf Bau der ini-Datei verändert?

Wie in meinem letzten Post beschriebn, bleiben die User-Settings in der DB (so wie es ist) und werden nicht in ein File ausgelagert da es sowieso dann immer ein sonderfall ist. Ich werde das mal grob umsetzen als function rereadTinymces(); gleich der Funktion rereadClients();

wie wollen wir großen und kleinen Tiny trennen? wir haben ja schon
['cms_htmlhead'] & ['cms_htmlhead_1'] als keys,
kommt dann noch ['cms_htmlhead_inside'] & ['cms_htmlhead_1_inside'] ?

mfg OliverL

[xmurrix]

Hallo zusammen,

die Diskussion, welche Form zur Verwaltung der Konfiguration nun letztendlich gut/schlecht ist, finde ich für nicht sehr hilfreich. Das führt zu einem Glaubenskrieg wie mit Tabs oder Leerzeichen.

Hier hat jeder seine eigenen Vorlieben, die müssen wiederum nicht von anderen geteilt werden. Will man es jedem Recht machen, dann kommt nur eine Konfiguration in Frage, die mit allen Arten (XML, INI, YAML und PHP-Array) umgehen kann und das wäre z. B. Zend_Config, dem man noch um einen Adapter für YAML erweitern müsste.

Alle Formate haben ihre Vor-/Nachteile und Parsen muss man alle bis auf das PHP-Array.

Nachtrag
@idea-tec:
Bin nicht gegen deinen Vorschlag, Konfigurationen in XML abzulegen. Das Thema, wie Konfigurationen in Contenido behandelt werden sollen, würde ich aber separat angehen. Beim Erweitern des TinyMCE reicht es aus, wenn wir uns einig sind, ob die Einstellungen in der DB oder als cfg-Array abgelegt werden.

Grüße
xmurrix

[OliverL]

Ich als Themenstarter und Beta-Function-Maker habe eigendlich für mich entschieden das es mit dem PHP-Array umgesetzt wird.
Nichts gegen dichidea-tec aber alle *.config.*.php sind mit Arrays und dort etwas neues zu ergänzen würde Usern und uns nichts bringen den ich denke das dann die neue Funktion ungenutzt bleibt. (Hab mich ja auch deswegen von meinem Set abbringen lassen)

Wie wollen wir großen und kleinen Tiny trennen?

Wir haben ja schon für CMS_HTMLHEAD[1]
['cms_htmlhead'] & ['cms_htmlhead_1'] als keys.

Kommt dann noch
['cms_htmlhead_inside'] & ['cms_htmlhead_1_inside'] ?

mfg OliverL

[xmurrix]

Die Aufteilung mit

Code: Alles auswählen

$cfg['wysiwyg']['cms_htmlhead']['name'] = 'wert';

$cfg['wysiwyg']['cms_htmlhead_inside']['name'] = 'wert';

finde ich gut.

Als Alternative wäre noch möglich:

Code: Alles auswählen

$cfg['wysiwyg']['default']['cms_htmlhead']['name'] = 'wert';

$cfg['wysiwyg']['inside']['cms_htmlhead']['name'] = 'wert';

So hätte man eine saubere Abgrenzung über den Key, was aber zu mehr Schreibarbeit führt.

Warum möchtest du die Clientkonfiguration des wysiwyg in das $cfgClient Array packen, weil es sich explizit um Clientkonfiguration handelt?

Ich persönlich würde beim $cfg Array bleiben, weil das bisher immer zum Ablegen der Konfigurationen verwendet wurde, dann müsste man z. B. keine rereadTiny Funktion implementieren. Nicht falsch verstehen, ich habe da etwas weiter gedacht. Wenn zukünftige Features auch solche Konfigurationen für Clients brauchen, müsste man dann jeweils eine reread* Implementieren. Wäre es da nicht besser, wenn wir uns sowas sparen?

Gruß
xmurrix

[OliverL]

, was aber zu mehr Schreibarbeit führt.

da mach ich mir keine sorgen. Man kann ja die Zeilen kopieren und die Parameter anpassen.

Würdest du nicht noch die unterteilung mit $cfg['wysiwyg']['tinymce']... machen?
Im Backend wurde es auch vom Key wysiwyg in tinymce geändert.

ob die Einstellungen in der DB oder als cfg-Array abgelegt werden.

Ich bin jetzt davon ausgegangen das wir eine Kombination erstellen, so das "alte" konfiguartionen bei Updates ihre wirkung behalten.

$cfg als System Basis das durch die DB-Einträge ergänzt wird.
$cfgClient als Mandanten Basis das durch die DB-Einträge ergänzt wird.
und Nur die BE-User spezifischen ausschließlich aus der DB.

Durch rereadTinymces() wird das [set] in cfg und cfgClient gesetzt
und sagtaus ob die DB-Eiträge abgerufen und ergänzt (passiert auch in rereadTinymces() ) wurden.

In der cTinyMCEEditor (editorclass.php) werden dann die Daten $cfg + cfgClient + BEUser zusammen geführt und innerhalb an $this->_aSettings übergeben.

mfg oliverl

[Oldperl]

Würdest du nicht noch die unterteilung mit $cfg['wysiwyg']['tinymce']... machen?
Im Backend wurde es auch vom Key wysiwyg in tinymce geändert.

Ich würde wysiwyg weglassen, der key tinymce sagt doch eigentlich schon alles. Auserdem wird die Verschachtelung immer tiefer sonst und auch hier denke ich sollte man irgendwo eine Grenze ziehen.

Gruß aus Franken

Ortwin

[xmurrix]

Will mann die Kombination (DB und $cfg Array) beibehalten, macht die weitere Unterteilung im $cfg Array keinen Sinn, da mus man sich an das richten, was mit der DB-Konfig möglich ist.

... Würdest du nicht noch die unterteilung mit $cfg['wysiwyg']['tinymce']... machen? ...

Doch, so kan man das auch machen, besser wäre es vermutlich, wenn DB und $cfg einheitliche Struktur haben.

Anstatt einer rereadTinymces() Funktion wäre eine Funktion besser, die auch mit anderen Bereichen arbeitet, also etwas wiederverwendbares, z. B.:

Code: Alles auswählen

$res = conGetConfig('wysiwyg');

$res = conGetConfig('foobar');

Dabei kümmert sich conGetConfig() um das Laden der Konfiguration für den gewünschten Bereich, wenn dies vorher nicht passiert ist. Die Stadi, ob ein Bereich schon geladen wurde, kann man mit static Variablen in der Funktion lösen. Das kann man auch zukünftig auch für andere Bereiche einsetzen.

Gruß
xmurrix

[derSteffen]

Hallo,

ich habe mal eine Frage zu diesem Thread.

Ist es denn nun möglich verschiedene Eingabemodule (CMS_HTML[1], CMS_HTML[5], CMS_HTMLHEAD[1]) so zu ändern, dass man sagen kann Text-Eingabe kann über den Inline und den "großen" Editor gemacht werden, bei HTMLHEAD[1] wird gar kein Editor geöffnet.

Vielen Dank

MfG Steffen

[OliverL]

Erst mal ein "Hallo".

*denk *denk *denk

Man kann in den BE-Usern angeben ob der WYSIWYG-Editor benutzt wird oder nicht.
Für mich ist das ausreichend und für alle anderen Fälle nutze ich CMS_TEXT.

Hast du ein konkrettes Beispiel in dem es sinnvoll ist sperat den WYSIWYG-Editor abzuschalten?

mfg Oliver

[derSteffen]

Hallo Oliver,

also ich definiere den WYSIWYG bereits unter den Gruppeneigenschaften und kann somit ja Gruppen verschiedene Editoren (also Anzahl von Symbolen und welche Symbole angezeigt werden sollen) anbieten.

Ein Beispiel, wofür kein Editor aufgerufen werden brauch, wären Überschriften. Dieso sollen ja einfach nur reingeschrieben werden, fertig. Ich gebe zwar Überschriften sowieso ohne HTML-Tags aus (wie es auch sein soll) aber wenn ein Redakteur Formatierungen in einer Überschrift vornimmt und diese dann nicht auf der Webseite zusehen sind, wundert er sich vieleicht. Und wenn er erst gar keine machen kann, übergeht man das.

Alternativ würde ja auch gehen (wie hier die Ansätze waren) das man für bestimmte Eingabe-Bereiche anhand der ID bestimmte Editoren anbieten kann. Und für eine Überschrift wäre das halt dann ein Editor, der nichts kann außer Text eingeben.

MfG Steffen