Subsites

[Martin]

Wenn ich nun auch eine in den content Ordner der Hauptsprache/Hauptsite lege, brauche ich keine langconfigs mehr

Ja! Wir Dösbaddel! So einfach wäre es damals gewesen.

Das Problem mit den abweichenden Konfigurationen für Plugins ist dann aber weiter offen. Muss wohl im Pluginloader geregelt werden. Wenn eine ./subsite/plugins/pluginname/config.php existiert, wird diese genommen.

Stimmt, das ließe sich an der Stelle vermutlich auch ganz einfach machen. Am Ende der Funktion PluginFiles() in plugins/index.php

Code: Select all

 if (file_exists($pth['folder']['content'] . 'plugins/'. $plugin . '/config.php')){
            $pth['file']['plugin_config'] = $pth['folder']['content'] . 'plugins/'. $plugin . '/config.php';
        } 

... und ähnliches dann auch für die Plugin-Sprache. Aber, selbst wenn es damit tatsächlich keine Kompatibiltätsprobleme gäbe - vielleicht schlägt ja irgendein Plugin mal eine Einstellung oder die Sprache direkt und nicht über den Umweg Plugin-Loader nach -, sind wir damit mitten in unser aller Lieblingsdiskussion: Die Ordnerstruktur!

Martin

[cmb]

Hallo Martin, hallo Gert,

ich habe mir noch mal Gedanken über das Problem mit den mehrsprachigen Subsites gemacht. Ich bin die ganze Zeit davon ausgegangen, dass verschiedene Subsites-Ordner die verschiedenen Sprachen abbilden könnten (daher auch die Idee mit SUBSITE-LANG). Aber wieso eigentlich? Warum nicht so, wie es bisher auch schon von CMSimple für Multilang gemacht wird? Da sind die 2lang/ Ordner Unterordner der "Hauptinstallation". Warum also nicht die Multilang-Ordner der Subsite als Unterordner davon (also subsite/fr/, subsite/it)? Dazu müsste deren index.php nur 2 Verzeichnisse nach oben verweisen, und in cms.php das Setzen von $pth[folder][base] noch eine weitere elseif-Klausel haben, die ebenfalls 2 Verzeichnisse nach oben verweist.

Ob das nun irgendwie sinnvoll genutzt werden kann, ist mir nicht klar. Aber die Idee ist vielleicht ganz interessant.

Christoph

PS: Wieso eigentlich die Plugin-Konfig? Bisher ging es doch nur um die Plugin-Language.

[Gert]

Naja, wenn ich aber recht überlege:

Mit den unterschiedlich konfigurierbaren Plugins wird dann aber die Pflege von Subsites nach einem Plugin Update so aufwändig, dass ich dann auch gleich eine komplette CMSimple_XH Installation machen kann, anstelle einer Subsite. Ich muss ja dann evtl. in allen Subsites und Sprachen eine neue config.php einspielen.

Und wenn schon, dann könnte das ganze auch ohne $txc Variablen passieren, wenn eh in jeder Sprache und in jeder Subsite eine config.php liegt, kann es auch gleich eine config.php mit $cf Variablen sein.

Dann könnte ich da nur die $cf Variablen eintragen, die auch überschrieben/ersetzt werden sollen, das ginge doch einfach mit "nach-includen"? Also wenn schon, dann richtig, ohne $txc Variablen.

Ich spiele mal noch ein wenig.

[cmb]

Hallo Gert,

das eventuelle Abschaffen der $txcs hätte schon was. Aber das würde für den Anwender beim Update bedeuten, dass er nicht nur die langconfig.php verschieben und umbenennen muss, sondern auch noch die $txc's umbenennen muss. Und Anpassungen beim Laden und Speichern wären auch noch nötig.

Mit den unterschiedlich konfigurierbaren Plugins wird dann aber die Pflege von Subsites nach einem Plugin Update so aufwändig

Wieso denn? Schon vor einigen Posts:

Das geht dann nur noch, indem in den Sprach- und Subsite-Ordnern plugins/ Verzeichnisse angelegt werden

und als Antwort:

Und für die Plugins ließe sich sicherlich auch eine passende Lösung finden. Z.B. könnten subsites-Sprachdateien in einen Unterordner von languages gelegt werden oder auch einfach nach dem Muster SUBSITE-SPRACHE.php angesprochen werden. Das sollte vom PL aus eigentlich völlig transparent für die Plugins machbar sein.

Also gibts es dann z.B. PLUGIN/languages/SUBSITE-fr.php etc. Das ist eigentlich das gleiche wie bei der jetzigen Subsite-Lösung. Aber Martin hat natürlich recht, dass es Probleme gibt, wenn das Plugin selbst languages/$sl.php liest.

Christoph

[Martin]

... und in cms.php das Setzen von $pth[folder][base] ...

Noch simpler fände ich übrigens sowieso $sl, CMSIMPLE_ROOT und CMSIMPLE_BASE direkt in die index.php zu schreiben. Dort ist es ja im Grunde bekannt und muss nicht erst mühsam konstruiert werden.

PS: Wieso eigentlich die Plugin-Konfig? Bisher ging es doch nur um die Plugin-Language.

he, he - das verwirrt mich ja immer so. Register konfiguriert ja beispielsweise seine Logout-Seite in der Sprachdatei ... Aber, wie auch immer, mit Sprache und / oder Konfiguration ist es ja vielleicht noch nicht immer getan. Was ist mit den Plugin-Daten, css etc. - Wenn Familie Müller eine Familienhomepage macht, soll die "subsite" "mueller/sohn/" vielleicht ganz anders aussehen als "mueller/tochter", auf "mueller/firma" wird gesiezt ...

Und wenn schon, dann könnte das ganze auch ohne $txc Variablen passieren, wenn eh in jeder Sprache und in jeder Subsite eine config.php liegt, kann es auch gleich eine config.php mit $cf Variablen sein.

Dann könnte ich da nur die $cf Variablen eintragen, die auch überschrieben/ersetzt werden sollen, das ginge doch einfach mit "nach-includen"?

Jein. Nach dem Speichern hättest du dann nicht mehr nur die, ich sag mal, User-$cf-Variablen sondern den ganzen $cf-Array in deiner content(bzw. subsite)/config.php. Irgendwie müsste man trennen zwischen $cf und $site_cf. Dann würden, denke ich, auch die Updates leichter - wenn der Anwender "seine" Konfiguration in "seinem" Ordner hätte, müsste er nicht mehr nach jedem Programm-Update Passwort, Seitentitel etc. neu setzen ...

LG
Martin

[cmb]

Hallo Martin,

Noch simpler fände ich übrigens sowieso $sl, CMSIMPLE_ROOT und CMSIMPLE_BASE direkt in die index.php zu schreiben

CMSIMPLE_ROOT und CMSIMPLE_BASE fände ich dort eigentlich nicht verkehrt, obwohl das mühsame Konstruieren ja auch nicht sooo mühsam ist. $sl ist aber zumindest bei 2lang/ nicht bekannt, und müsste dann ja immer vom User manuell eingetragen werden.

Register konfiguriert ja beispielsweise seine Logout-Seite in der Sprachdatei

Das ist vielleicht nicht sooo schön. Wir sollten da vielleicht mal an eine langconfig.php für Plugins denken Im Ernst: ich find's eigentlich nicht schlimm, und es passt irgendwie zu CMSimple.

Was ist mit den Plugin-Daten, css etc.

Da hast Du natürlich recht. Es ist vielleicht schon ein Problem, wenn Frau Müller einen pinken Hintergrund mit Blümchenmuster für Advancedform stylt, und das dann auf dem Kontaktformular der Firmenseite (ein Bestattungsunternehmen) erscheint.

Mit den Plugindaten im allgemeinen sehe ich eher weniger Probleme. Da wird ja häufig nicht mal Multilang berücksichtig, sondern der User hat nur verschiedene Fotogalerien, Mailformulare, etc. die er eben entsprechend zuweisen muss.

Aber insgesamt hast Du schon recht: die Subsite-Lösung, egal welche Variante, wird nur bedingt nutzbar sein.

Christoph

[Martin]

Hallo Christoph,

wenn "2lang" wirklich zu einem zweibuchstabigen "Sprachordner" gemacht wird, kein Problem:

Code: Select all

$sl = basename(dirname(__FILE__)); 

Wenn man etwas anderes damit vorhat, eine subsite, muss $sl sowieso mit der Hand gesetzt werden - oder man streicht die Zeile, wenn man die "default language" nutzen will. Mit dem Vorschlag, diesen Teil des Setups in die index.php zu verlegen, bin ich aber ein bisschen vom Thema "subsites" zu meiner Wunschliste abgedriftet: ein Ordner "cmsimple", ein ordner "user", in dem er dann seine Dateien, Konfigurationen, Sprachänderungen und Content-Folder, ob er sie nun für Übersetzungen (en, fr, ..) oder "subsites" nutzt, sammelt. (Keine Update-Probleme mehr, keine unterschiedlichen Pfade von den content.htm's zu den Dateien mehr ...)

Aber eins stimmt natürlich auch: Eine "subsite" wird so oder so keine eigenständige Installation ersetzen können und wollen. Wenn man sich da nicht auf eine einheitlich Gestaltung der Galerien einigen kann, ist jede CMSimple-Subsite-Lösung sowieso überfordert. Also müssen wir uns auch keine Gedanken über <subsite>/<plugin>/stylesheet.css etc. machen. Konfiguration und Sprache reichen. Und das wäre ja machbar ...

Martin

[Gert]

Hallo Martin und Christoph,

jetzt seid Ihr aber schon fast bei Martins Entwurf der 2.0

Und da machen wir es dann auch.

Die 1.5 bleibt einfach eine weitere Version 1.x.x - mit einer einfachen subsites Lösung, die auch für weitere Versionen 1.x.x so bleibt. Bisher hat alles, was ich getestet habe, funktioniert (ausser Holgers Plugins, die $sl auf 2 Stellen prüfen), und mit ein paar Einschränkungen (dass z. B. ein datepicker nur English spricht wegen fallback) muss der User eben leben.

[cmb]

Hallo Martin,

Du hast natürlich völlig recht, dass $sl in index.php automatisch gesetzt werden könnte. Das wäre auch für 1.5 bereits machbar, bringt vielleicht aber noch keine wirklichen Vorteile, da es so, wie es jetzt ist, auch schon funktioniert. Und Deine Wunschliste klingt natürlich super. Aber das ist natürlich nichts mehr für die 1.5, da hier die Abwärtskompatibilität noch im Vordergrund steht. Und bei einer solchen Änderung der Ordnerstruktur würden zumindest verlinkte Bilder und Downloads ja nicht mehr stimmen. Aber es ist ja erst Oktober, und wer weiß? -- vielleicht beschert uns der Weihnachtsmann was entsprechendes

Konfiguration und Sprache reichen. Und das wäre ja machbar ...

Ja klar. Darauf sollten wir uns dann auch beschränken. Und vermutlich sind Multilang+Subsites auch gar nicht wirklich nötig. Trotzdem wäre $sl als verlässlicher ISO-639-1 Code schon schön.

Christoph

PS: Hallo Gert,

Bisher hat alles, was ich getestet habe, funktioniert (ausser Holgers Plugins, die $sl auf 2 Stellen prüfen)

huch, hast Du schon eine neuere Version des Sitemapper als ich? Und Holgers Plugins sind, soweit ich weiß, bereits aktualisiert. Aber vielleicht hast Du ganz recht, und wir sollten die Subsites eben so nehmen, wie sie sind, und uns auf den Weihnachtsmann freuen -- auch wenn er vielleicht zwei lange Ohren hat, und einen Korb voll bunter Eier

[Holger]

Puhh, ich kann kaum mehr folgen...

Und da machen wir es dann auch.

Denk' ich auch.

(ausser Holgers Plugins, die $sl auf 2 Stellen prüfen)

DAS ist ist das geringste Problem, sag' ich jetzt zum 3. Mal .

und mit ein paar Einschränkungen (dass z. B. ein datepicker nur English spricht wegen fallback) muss der User eben leben.

Wenn's nur um die richtige Sprachdarstellung geht, ist's ja ok.
Und wenn über $sl wichtige Dinge passieren, muss das Plugin dann doch eine Prüfung auf 2 Buchstaben machen.
Bisher fällt mir nur lb_gallery ein, wo es einen "Nebeneffekt" gibt: die Dateien mit den Infos zu den Bildern heißen dann halt bildname_Gymnastikabteilung.txt .