LangMan_XH (Languages Manager XH)

[lck]

Ok, also doch gelöscht, nicht deaktiviert, na ja indirekt. Gut.

Warum? in dem Ordner ist doch nichts verwertbares drin. Oder habe ich etwas übersehen?

Alles gut. Im Backend steht "deaktivieren", deswegen. Ich dachte dann wird halt der Sprachordner per vorangestelltem Punkt oder dergleichen deaktiviert. Ein Blick in den Root zeigte mir aber, dass der Ordner gelöscht wird. Kein Problem.

[olape]

Alles gut. Im Backend steht "deaktivieren", deswegen. Ich dachte dann wird halt der Sprachordner per vorangestelltem Punkt oder dergleichen deaktiviert. Ein Blick in den Root zeigte mir aber, dass der Ordner gelöscht wird. Kein Problem.

Das wäre natürlich auch ohne Weiteres möglich, macht es aber nicht wirklich übersichtlicher, wenn man jetzt mal per ftp reinschauen wöllte.
Außerdem würde auch das Plugin wieder etwas umfangreicher, da das Anlegen des Ordners für das Erstellen einer Sprache eh benötigt wird. So müsste noch zusätzlich geprüft werden, ob der Ordner .xx existiert und wenn ja ... oder wenn nicht ...
Ich bin ja auch ein wenig faul.
Aber, grundsätzlich wäre es keine Problem.

[cmb]

Ich dachte da an unbedarfte Admins, die da gerne mal rumspielen und ausprobieren.

Den Gedanken dahinter habe ich schon verstanden. Aber JS ist nicht meins.
Ich müsste mich auf die Suche machen, nach einer Idee, wie das umsetzbar ist.
Also sowas wie onchange und dann auf die Auswahl "delete" reagieren.

Du kannst onsubmit des forms nutzen:

Code: Select all

<form … onsubmit="if (this.conf_setup_lang.value === 'delete' && !confirm('Really?')) return false;"

Schöner ist es eigentlich, wenn man das per PHP erledigt (ähnlich wie hier im Forum), aber das ist dann halt auch wieder aufwendiger.

[cmb]

Die Auswahl der Hauptsprache könnte/sollte das Plugin auch gleich noch mit übernehmen.

Äh, ja, hm, also, ...
Ehrlich gesagt habe ich mich noch nie damit beschäftigt, wie ich aus einem Plugin heraus Systemeinstellungen ändern kann.

Eine API gibt es dafür leider nicht. Aber eigentlich ist es nicht wild; hier mal vereinfacht:

Code: Select all

function modifyConfig() {
    global $pth;

    include $pth['file']['config'];
    // do whatever you want with $cf
    file_put_contents($pth['file']['config'], var_export($cf, true));
    // redirect/reload
}

Hier sollte auf jeden Fall noch File-Locking implementiert werden. Und das Editieren per Form könnte möglicherweise mit den FileEdit-Klassen implementiert werden; dann wird auch die geänderte config.php wieder wie gewohnt aussehen.

[olape]

Eine API gibt es dafür leider nicht. Aber eigentlich ist es nicht wild; hier mal vereinfacht:

Code: Select all

function modifyConfig() {
    global $pth;

    include $pth['file']['config'];
    // do whatever you want with $cf
    file_put_contents($pth['file']['config'], var_export($cf, true));
    // redirect/reload
}

Hier sollte auf jeden Fall noch File-Locking implementiert werden. Und das Editieren per Form könnte möglicherweise mit den FileEdit-Klassen implementiert werden; dann wird auch die geänderte config.php wieder wie gewohnt aussehen.

Das muss ich mir in Ruhe zu Gemüte führen.

[olape]

Und ganz verrückt: Die Auswahl der Hauptsprache könnte/sollte das Plugin auch gleich noch mit übernehmen.

Zu diesem Punkt hatte ich eine Idee, die ich aber wieder verworfen habe.

Ich wollte eigentlich beim Wechsel der Defaultsprache die aktuelle Defaultsprache als Zweitsprache verschieben.
Aber, da ja auch Plugins ihre Daten in /content ablegen, und zwar einige sprachunabhängig direkt in /content/,
andere dagegen sprachabhängig in /content/ bzw. /content/xx/ und es gibt keine Möglichkeit sicher festzustellen, welche Plugindaten mit nach /content/xx/ verschoben werden müssten und welche weiterhin in /content/ verbleiben müssen,
--> verworfen.
Also keine wirkliche Möglichkeit außer eine Liste zu führen. und das macht eben keinen Sinn.

Es bleibt also die Idee einfach "hart" die Defaultsprache umzustellen wie es bisher auch in der CMS-Konfiguration ist.

[olape]

Du kannst onsubmit des forms nutzen:

Code: Select all

<form … onsubmit="if (this.conf_setup_lang.value === 'delete' && !confirm('Really?')) return false;"

onsubmit ist auf jeden Fall besser als onchange. Das tut es erst mal.

[olape]

Eine API gibt es dafür leider nicht. Aber eigentlich ist es nicht wild; hier mal vereinfacht:

Code: Select all

function modifyConfig() {
    global $pth;

    include $pth['file']['config'];
    // do whatever you want with $cf
    file_put_contents($pth['file']['config'], var_export($cf, true));
    // redirect/reload
}

Hier sollte auf jeden Fall noch File-Locking implementiert werden. Und das Editieren per Form könnte möglicherweise mit den FileEdit-Klassen implementiert werden; dann wird auch die geänderte config.php wieder wie gewohnt aussehen.

Das muss ich mir in Ruhe zu Gemüte führen.

Tut mir leid, ich habe es mehrfach gelesen, aber ich weiß nicht, wie ich damit umgehen soll, wenn ich doch nur die eine Position ändern will.
Ich habe mir eine Lösung von Holgers hi_admin "geklaut".

[olape]

LangMan_XH 1.0. beta1

[Holger]

Die Idee ist gut Ich muss auch immer nachdenken, wie das mit einer weiteren Sparache geht.
Auf jeden Fall eine wichtige Erweiterung IMHO.

Allerdings gibt es mit der aktuellen Beta ein CSS-Problem mit dem Pagemanager. Der schaut jetzt etwas durcheinander aus