LangMan_XH (Languages Manager XH)

[olape]

Eigentlich eine gute Idee.
Aber, was ist wenn man z.B. LangMan einträgt? Stehen dann Ludwigs Vorschläge auch weiterhin zur Verfügung?

Darum geht es ja. Das Sprachmenü so erhalten, wie es jetzt ist. Dafür aber die Möglichkeit schaffen, ohne Änderungen im Template auch alternative Sprachmenüs einzubinden.
Ich bin dabei von deinem Vorschlag ausgegangen, Ludwigs Entwurf in LangMan zu übernehmen.
Oder natürlich Christophs Polyglot.

Ja, kann man so machen, aber ist es das wirklich wert? Beim Editor wird das ja genutzt, aber einen alternativen Dateimanager gibt es leider nicht. Und gerade mehrsprachige CMSimple_XH Sites sollte es doch nicht so viele geben, als dass man es dem Admin nicht "zumuten" kann, im Template den Aufruf von languagemenu() zu ersetzen (wenn er das überhaupt möchte).

Grundsätzlich kann man dem Admin alles zumuten, klar.
Aber wir sind uns ja seit einiger Zeit einig, hoffe ich jedenfalls, dass Komfort auch eine wesentliche Rolle spielt.
Min. ein alternatives Menü haben wir aktuell, alleine das lässt mich denken: Ja, das ist es wert.
Übrigens könnte man dann analog auch fragen: warum und ob wir konfigurierbare Templates brauchen.

Und noch schöner fände ich, wenn es in der Config kein Textfeld wäre, sondern ein DropDown und die Plugins die Liste dazu (enum:…) allein erweitern würden. Man bräuchte also eine Art Registrierungsfunktion.
Ganz profan würde es wohl reichen eine Variable (Array) zu setzen die das Plugin entsprechend erweitert und eine Funktion, die dann aus dem Array ein enum:… macht.
Also XH setzt i.e. $langMenuArray = array;
Und Polyglot würde dann $langMenuArray[Polyglot] = polyglot_languagemenu; oder fiktiv für LangMan, $langMenuArray[LangMan] = langman_languagemenu; setzen.
Und jetzt aus den Keys ein enum für die Konfig und die Values, damit auch bekannt ist, was nachher aufgerufen werden muss.
Abwärtskompatibel wäre das auch hin wie her, also eigentlich kein Problem.

Eigentlich könnte ich mir vorstellen, das für alle Templatefunktionen so zu gestalten.
Ob das in jedem Fall und aktuell immer Sinn macht :?:
Aber es täte auch keinem weh. Diese Config-Optionen dazu könnte man auch in den ausgeblendeten Bereich verschieben.

[Holger]

Und noch schöner fände ich, wenn es in der Config kein Textfeld wäre, sondern ein DropDown und die Plugins die Liste dazu (enum:…) allein erweitern würden. Man bräuchte also eine Art Registrierungsfunktion.

So etwas in der Art gibt es für Editor, Pagemanager etc. schon: https://github.com/cmsimple-xh/cmsimple ... .php#L2307
Dort halt als <datalist>.

Eigentlich könnte ich mir vorstellen, das für alle Templatefunktionen so zu gestalten.

Das ist wohl etwas übertrieben, denke ich.

Übrigens könnte man dann analog auch fragen: warum und ob wir konfigurierbare Templates brauchen.

Und wenn das konfigurierbare Template die Auswahl der Alternativen bereitstellt?

Wie dem auch sei. Ich habe auch nichts gegen eine weitere Config-Variable. Allerdings, wenn der Admin nur noch klicken braucht, muss zumindest noch eine Prüfung auf Existenz der konfigurierten Funktion erfolgen - halt mit Fallback zur vorhandenen Core-Funktion.

[frase]

Mal zusammengefasst:
Ludwigs Vorschlag für den Core und Olafs Lang_Man_XH sind - jedes für sich - schonmal hervorragende Verbesserungen für CMSimple_XH.
Könnte man das irgendwie zusammenfassen und an einer Stelle vereinen: umso besser.
Nach meiner Meinung sollten wir uns nichts ersparen, was es dem XH-User einfacher und übersichtlicher macht.
Ich sage es nochmal und wahrscheinlich noch öfter: CMSimple und CMSimple_XH haben in den letzten Jahren mit immer stärker und besser werdender Konkurrenz zu tun.
Wenn wir nicht als unbedeutendes Sparten-CMS enden wollen, mit geschätzen 50 "echten" Benutzern, die dazu auch noch Hobbyprogrammierer sein müssen, dann sollten wir uns sputen.

Übrigens:
Eine Signatur mit Link zu http://cmsimple.holgerirmler.de/ - praktisch ein toter Link - ist auch nicht gerade hilfreich.
Sorry, ich habe wohl nicht das Recht, irgendjemanden zu kritisieren und will das auch gar nicht. Gründe gibt es viele und ich habe auch Verständnis dafür. Im Laufe der Jahre sollte es aber auch mal ein paar Minuten geben, um den Link vielleicht auf https://github.com/TN03?tab=repositories zu ändern? Nochmal, sorry!

[Holger]

OT:

Übrigens:
Eine Signatur mit Link zu http://cmsimple.holgerirmler.de/ - praktisch ein toter Link - ist auch nicht gerade hilfreich.
Sorry, ich habe wohl nicht das Recht, irgendjemanden zu kritisieren und will das auch gar nicht. Gründe gibt es viele und ich habe auch Verständnis dafür. Im Laufe der Jahre sollte es aber auch mal ein paar Minuten geben, um den Link vielleicht auf https://github.com/TN03?tab=repositories zu ändern? Nochmal, sorry!

Da gibt es auch nicht viel zu sehen. Daher ist es wohl besser, die Signatur ganz zu entfernen

[olape]

So etwas in der Art gibt es für Editor, Pagemanager etc. schon: https://github.com/cmsimple-xh/cmsimple ... .php#L2307
Dort halt als <datalist>.

OK, das muss ich mir mal ansehen. Soweit bin ich noch nicht.

Das ist wohl etwas übertrieben, denke ich.

Mag sein, aber wenn wir es einmal anfassen würden, ...

Wir lassen das Languagemenü, wie es ist, schaffen dazu aber eine config-Option.
Da kann man dann Polyglot oder, falls es das mal gibt, Langman eintragen.
Ist etwas eingetragen, gibt die althergebrachte Funktion zurück, was eingetragen ist, ist nichts eingetragen, dann gibt sie zurück, was sie auch bisher zurückgibt.

Mal einen Entwurf (1.7.5) nach dieser Idee (Ich weiß, kein GitHub )

Download entfernt

Wer zusätzlich Polyglot installiert und in der config von XH jetzt polyglot einträgt, der sollte das Menü von Polyglot erhalten, ohne Änderung am Template --> ungetestet

[olape]

muss zumindest noch eine Prüfung auf Existenz der konfigurierten Funktion erfolgen

Das würde noch fehlen, ist ja aber kein Problem

[cmb]

(Ich weiß, kein GitHub )

Github muss ja auch nicht sein, aber ein .diff ist nicht verkehrt.

PS: wer auf Git verzichten will, könnte statt dessen WinMerge verwenden (mach ich gelegentlich).

[olape]

Github muss ja auch nicht sein, aber ein .diff ist nicht verkehrt.

PS: wer auf Git verzichten will, könnte statt dessen WinMerge verwenden (mach ich gelegentlich).

Stimmt WinMerge ist eine Idee. Da hätte ich auch allein drauf kommen können.
Nutze ich auch hin und wieder, aber auf die Idee es dafür zu nutzen, bin ich nicht gekommen.

Aber ok, die Änderungen an XH sind im Moment minimal.
default.config.php und die Sprachdateien müssten zusätzlich noch aktualisiert werden.
Aber es geht erst mal ums Prinzip.

[olape]

So etwas in der Art gibt es für Editor, Pagemanager etc. schon: https://github.com/cmsimple-xh/cmsimple ... .php#L2307
Dort halt als <datalist>.

Kann man

Code: Select all

XH_registerStandardPluginMenuItems(true)

und

Code: Select all

XH_registerPluginType('languagesmenu', $plugin)

gefahrlos gleichzeitig einsetzen?
Ersteres wird für ein richtiges Plugin - DropDownMenü benötigt, letzteres als Grundlage für Dropdown-Auswahl (enum) in der Config von XH.
Es funktioniert soweit, aber ist es problematisch beides zu nutzen?

[Holger]

So etwas in der Art gibt es für Editor, Pagemanager etc. schon: https://github.com/cmsimple-xh/cmsimple ... .php#L2307
Dort halt als <datalist>.

Kann man

Code: Select all

XH_registerStandardPluginMenuItems(true)

und

Code: Select all

XH_registerPluginType('languagesmenu', $plugin)

gefahrlos gleichzeitig einsetzen?
Ersteres wird für ein richtiges Plugin - DropDownMenü benötigt, letzteres als Grundlage für Dropdown-Auswahl (enum) in der Config von XH.
Es funktioniert soweit, aber ist es problematisch beides zu nutzen?

So ist es gedacht. Steht auch so im TinyMCE-Plugin und so habe ich das auch beim CKeditor in der admin.php stehen:

Code: Select all

/*
 * Register the plugin menu items.
 */
if (function_exists('XH_registerStandardPluginMenuItems')) {
    XH_registerStandardPluginMenuItems(true);
}

/*
 * Register the plugin type 'editor'.
 */
if (function_exists('XH_registerPluginType')) {
    XH_registerPluginType('editor', 'ckeditor');
}

Nur den Typ "languagesmenu" gibt es halt noch nicht im Core.

BTW: den Typ würde ich, angelehnt an die TOC TPL-Funktion, besser "languagemenu" (also Einzahl, ohne "s") nennen.