Defaultsprache auch im Unterordner

[Michael_G]

Fazit/Workaround: bei mir schlägt die Website „mit der Kraft der zwei Herzen CMSimple_XHs – beide in je einer Standardsprache, aber als separate Installationen in Unterordnern a la Sprachordner:
Root: jeweils identische .htaccess, eigene sitemap.xml m. hreflang-Support, robots.txt und index.php.
/de: CMSimple_XH – deutsche Sprachversion (und deutschsprachiger Domainname)
/en: CMSimple_XH – englische Sprachversion (und englischsprachiger Domainname)
Mit richtigem Routing klappt das hervorragend.

Das verstehe ich nicht. Wenn es für DE und EN eigene Domainnamen und eigene Installationen gibt, wozu braucht man dann Routing? Das sind einfach vollwertige und getrennte Installationen die bestenfalls (manuell) miteinander verlinkt sind, oder

Wenn es meine erste Website wäre, würde ich Deine Frage beinahe bejahen. Bliebe immer noch das (gelöste) Problem, dass diese Konfiguration kein / (root) ohne Sprachordner kennt, was auch olape richtig erkannt hat. Allein das benötigt schon ein Routing.
Meine Website existiert seit über 20 Jahren und Google vergisst niemals irgendeine Seite. Durch Verwendung verschiedener Techniken veränderte sich mit den Jahren ab und zu auch die Seitenstruktur. Um fehlerhafte Seitenabfragen in diversen Varianten abzufangen, verwende ich ein ausgefeiltes Routing (die Abfragen werden nicht weniger, wenn ich sie ignoriere, also leite ich sie um).

All die Mühe war ja nur nötig, weil CMSimple_XH nicht multidomainfähig ist und Zweitsprachen anders behandelt als die Standardsprache. Sonst würde das alles mit einer Installation genauso gut funktionieren.

Ich würde es begrüßen, wenn CMSimple_XH bei gewünschter Mehrsprachigkeit automatisch auf Knopfdruck den Standardordner aus seinem Korsett befreien und mit der/den Zweitsprache/n eigene Ordner anlegen/nutzen würde.
Die Realisierung macht nur einmal etwas Mühe (für die PHP-Gurus unter euch ein Klacks) und das Handling wäre einfacher.

[Michael_G]

Das glaube ich eigentlich gar nicht. In den Zweitsprachen funktioniert alles was auch in der Hauptsprache funktioniert.
Man müsste ausser der Umleitung wahrscheinlich nur dafür sorgen, dass das Root mit einer "Sprache" hantiert, die es real nicht gibt.

Ja, da hast Du Recht!

Mal ganz kurz, aber auch nicht ganz zu Ende gesponnen.
[… gekürzt …]

Vielen lieben Dank für Deine „Spinnerei”, endlich macht sich mal jemand Gedanken dazu!
Und was Du da aus dem Ärmel geschüttelt hast, funktioniert so tatsächlich (angepasst) online real!
Ich habe das mit einer Testsite online ausprobiert und es funzt!

Habe es dann mal kurz auf meiner produktiven Website umgesetzt und auch da war alles prima – bis auf meinen nach Sprachversion getrennten Wartungsmodus.
Also doch wieder rasch Fallback auf das Backup und das läuft ja mit zwei Instanzen super gut.

Plugins wie Polyglott oder Sitemapper sehe ich da schon eher problematisch.

Das stimmt auch – Polyglott kann eh nicht mit einer zweiten Domain (für Zweitsprache …) umgehen und cmb müsste es minimal anpassen, damit es – gern optional – nur noch Sprachordner beachtet.

Auch Sitemapper hatte ich deinstallieren müssen, weil ich mangels Programmierkenntnissen nicht wüsste, wie man ihm Multidomain beibringt (für PHP-Cracks sicher leicht, aber für mich unmöglich).

Um hreflang Genüge zu tun, hatte ich im Web recherchiert, mir eine sitemap.xml mit hreflang-Berücksichtigung generiert und die pflege ich seitdem manuell und lade sie nach Änderung im Editor per SFTP wieder hoch. Google freut´s.

[olape]

bis auf meinen nach Sprachversion getrennten Wartungsmodus.

Den du vermutlich mittels .htaccess umsetzt?
Dann müsstest du dies wahrscheinlich nicht im root machen, sondern in dem jeweiligen Sprachordner.
Mit angepassten Pfaden vermutlich.

Ganz grundsätzlich aber soll XH auch auf Systemen funktionieren, die keine .htaccess unterstützen.
Von daher sollte unsere erste Wahl immer die Umsetzung per PHP sein.

[Michael_G]

@olape:
Ja, korrekt. Und weil das mittels separater .htaccess im Sprachordner störenden Einfluss auf das gesamte Routing hatte,
gab ich das wieder auf und habe den Wartungsmodus nach Sprache getrennt erst wieder eingeführt, seitdem ich die Lösung mit zwei Instanzen mit separaten Stammverzeichnissen nutze. Denn so kann das Script für den Wartungsmodus in der .htaccess bleiben und das Routing bleibt harmonisch.

Ja, selbstverständlich sollte CMSimple_XH auch ohne .htaccess auf diversen Webservern (nicht nur Apache) laufen können.
Mein Workaround erfüllt einfach meine speziellen Ansprüche, da ich kein PHP programmieren kann.
Ich habe das hier im Forum auch angesprochen und erläutert, um allen Interessenten zu verdeutlichen, dass CMSimple_XH auch dann verwendet werden kann, wenn man solche Ansprüche hat.
Bei Bedarf/Interesse helfe ich auch gern mit meinen .htaccess-Snippets, damit nicht nochmal jemand das Rad neu erfinden muss.

Auch wenn ich nicht in PHP programmieren kann – ich liebe diese Programmiersprache dafür, dass so etwas wie CMSimple_XH damit möglich ist – bei höchster Performance!
BTW: Trotz Umleitungen (auch für Fehlertoleranz bei falsch geschriebenen Seitennamen) ist CMSimple_XH immer noch schneller als ein CMS mit Datenbank.

[Holger]

Bliebe immer noch das (gelöste) Problem, dass diese Konfiguration kein / (root) ohne Sprachordner kennt, was auch olape richtig erkannt hat.

Jetzt hab' ich's dann auch kapiert .
Dachte doch schon immer, dass ich "net von Dummbach bin" .

[Michael_G]

@Holger:
Das würde Dir sicher niemand von uns unterstellen!

@olape:
Nochmals vielen herzlichen Dank dafür, dass Du („ungetestet”) Deine Gedanken/Idee dazu niedergeschrieben hattest!
Ich berichtete zwar von meinem erfolgreichen Test und Fallback, aber inzwischen ist Deine Idee hier erfolgreiche Praxis!

Hintergrund: gestern war mir aufgefallen, dass das Routing seit getrenntem Wartungsmodus doch nicht mehr ganz perfekt läuft.

Ich hätte dann einfach mehrere Backups ausprobieren können, um wieder auf den Stand zu kommen, als ich zum ersten Mal die sprachlich getrennte Wartung (mit zwei Instanzen – ohne Einbußen bei der Fehlertoleranz) hinbekommen hatte.
Aber weil die Lösung mit einer Instanz – nahe an der Standardkonfiguration – ein paar Vorteile hat, habe ich diese gewählt.
Einziger Nachteil: Wartungsmodus (per .htaccess) nur für gesamte Website machbar, aber den brauche ich recht selten.

[Michael_G]

Nachtrag:
@olape:
Weil CMSimple_XH mit Deinen „ungetesteten Modifikationen” theoretisch nur noch die Unterordner von /content/ beachten dürfte, war ich neugierig und habe tatsächlich die Datei /cmsimple/config.php nochmal modifiziert:

Code: Select all

$cf['language']['default']="de";
$cf['language']['2nd_lang_names']="de=Deutsch;en=English";

Fazit: Funktioniert tatsächlich problemlos.
Nur die Backup-Routine prüft noch, ob in /content/ eine content.htm vorhanden ist und erstellt dort eine zu /content/de/ identische Kopie der Backup-Datei.
Wenn ich wüsste, wo man das abstellen kann … ist aber nur kosmetisch, also lasse ich bis zu einer Lösung einfach immer eine content.htm dort stehen, damit das System nach Contentänderung beim Ausloggen nicht meckert.

Eine wichtige Ergänzung zum prima funktionierenden Workaround:
Alle Pfade zu /userfiles/ müssen einmalig in den content.htm-Dateien per Suchen & Ersetzen geändert werden, damit Bilder angezeigt werden:

Ändern von …

Code: Select all

/userfiles/

oder

Code: Select all

./userfiles/

in …

Code: Select all

../userfiles/

Wer schon länger mit einem mehrsprachigen CMSimple_XH gearbeitet hat, kennt das von den Zweitsprachen und hat es vielleicht der Einfachheit halber eh schon für alle content.htm-Dateien so gehandhabt.

[olape]

Datei /cmsimple/config.php nochmal modifiziert:
$cf['language']['default']="de";
$cf['language']['2nd_lang_names']="de=Deutsch;en=English";
Fazit: Funktioniert tatsächlich problemlos.

Ob das gut ist?
Jetzt hast du 2x de einmal als default und einmal als Zweitsprache.
Dass das mal keine Probleme macht.
ich hätte rd als default gelassen. Das tut dir doch nicht weh.

[Michael_G]

Stimmt, es schadet nicht.
Aber es stört auch nicht.

Auf das eigentliche Stammverzeichnis hat sowieso niemand Zugriff. Ohne folgendes Script in der .htaccess gäbe es einen 403er:

Code: Select all

# Fehlenden Sprachordner (de|en) einfügen | optimal: 02.01.2022
	RewriteCond %{REQUEST_URI} !^/(de|en) [NC]
	RewriteCond %{HTTP_HOST} ^(deutschedomain1.info|deutschedomain2(?:.info|.de))$ [NC]
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteCond %{REQUEST_FILENAME} !-d
	RewriteRule ^(.*)$ /de/$1  [R=301,NE,QSA,L]
	RewriteCond %{REQUEST_URI} !^/(de|en)	[NC]
	RewriteCond %{HTTP_HOST} ^(englischedomain1.info|englischedomain2.info)$ [NC]
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteCond %{REQUEST_FILENAME} !-d
	RewriteRule ^(.*)$ /en/$1  [R=301,NE,QSA,L]

Und damit immer die richtige Hauptdomain aufgerufen wird, folgt noch dieses Script:

Code: Select all

# Domain sprachabhängig | seit 08.01.2021 | optimal: 21.11.2021
	RewriteCond %{REQUEST_URI} ^/de/ [NC]
	RewriteCond %{HTTP_HOST} !^deutschedomain1.info [NC]
	RewriteRule ^(.*)$ https://deutschedomain1.info/$1	[R=301,NE,QSA,L]
	RewriteCond %{REQUEST_URI} ^/en/ [NC]
	RewriteCond %{HTTP_HOST} !^ englischedomain1.info [NC]
	RewriteRule ^(.*)$ https://englischedomain1.info/$1	[R=301,NE,QSA,L]

# Sprache domainabhängig | seit 08.01.2021 | optimal: 21.11.2021
	RewriteCond %{HTTP_HOST} ^(deutschedomain1.info|deutschedomain2(?:.info|.de))$ [NC]
	RewriteRule ^$ https://deutschedomain1.info/de/ [R=301,NE,QSA,L]
	RewriteCond %{HTTP_HOST} ^(englischedomain1.info|englischedomain2.info)$ [NC]
	RewriteRule ^$ https://englischedomain1.info/en/ [R=301,NE,QSA,L]

Mit diese Einträgen in der .htaccess läuft das schon seit über einem Jahr sehr gut und ich brauchte nur noch Kleinigkeiten optimieren wie die Flags [R=301,NE,QSA,L], damit wirklich alles abgedeckt wird.
Wer glaubt, dass hier etwas Unnötiges drin ist, hat noch nicht mit der Dummheit von Bots gerechnet.
Damit auch falsche Kombinationen von Sprache und Domain bzw. Seiteninhalt und Sprachordner abgefangen werden, sind diese Scripte wohl durchdacht und haben ihre Bewährungsprobe seit einem Jahr hinter sich.

Wer die echte Website in Aktion sehen und testen will, braucht nur mein Profil aufrufen und die dort genannte Website anklicken.
Ist übrigens direkt mit meinem eigenen Testbericht zu CMSimple_XH verlinkt.

[Michael_G]

Hallo olape,

es gibt gute Neuigkeiten (Sprachordnerlösung ohne .htaccess-redirect-Bedarf)!

Ich hatte ja schon geschrieben, dass CMSimple_XH bei mir auch mit Hauptsprache de und Zweitsprachen de/en prima läuft.
Mit der Zwangsweiterleitung via .htaccess gab es keinen unerwünschten Zugriff auf das Stammverzeichnis der Domain(s), das lief super, auch Google hatte damit keine Probleme (canonical = Sprachordner jeder Domain!).

Nur eine Berliner Online-Website-Testseite (URL finde ich nicht mehr) meinte im Audit-Report, dass das Stammverzeichnis einer Domain direkt erreichbar sein soll (also domain.tld/ und nicht nur domain.tld/de/ bzw. domain.tld/en/).
Googles WebmasterTools hat das nie gestört (Sprachordner sind bei mir canonical, quasi root, alles okay).

Ich blieb aber neugierig und habe dann zwei Deiner Vorschläge wieder zurückgenommen, das war die Lösung:

Du hattest die Anlage einer Fake-Sprache als Default vorgeschlagen; in meiner config-php-Version sah/sieht das so aus:

Code: Select all

$cf['language']['default']="de";
$cf['language']['2nd_lang_names']="de=Deutsch;en=English";

entsprechende Sprachen im Root und in Content (bleiben wir mal bei dem Beispiel: also jeweils en und de)

index.php im Root anpassen

Nein, ist gar nicht nötig …

Wer die index.php nicht ändern möchte, der kann unter /cmsimple/ die Datei userprelude.php anlegen

… und das als Alternative auch nicht (diese Variante hatte ich erfolgreich genutzt)

Was da stört ist das Sprachmenü.
/cmsimple/tplfuncs.php Zeile 525 auskommentieren

Code: Select all

    //array_unshift($r, $cf['language']['default']);

Dieser Codeschnipsel ist Gold wert!
Egal, ob für Fake-Hauptsprache genutzt oder nicht: das ist der Schlüssel!

DE auch als Hauptsprache wird nur für eine Introseite benutzt, daher auch kein Double Content:
Fürs „Finale” brauchte ich mich nur noch ins Stammverzeichnis einloggen, hier aus der großen content.htm-Kopie eine Introseite machen (alle fürs Intro überflüssigen Seiten löschen, also fast nur versteckte Error-400–500-Statusseiten übrig lassen) und ausloggen.


Eine .htaccess-Datei sollte man schon aus Sicherheitsgründen anlegen, in der man einen canonical link für https einheitlich mit oder ohne www regelt und vielleicht sogar eine https://perishablepress.com/7g-firewall/ einbaut.
Aber es funktioniert nun auch ohne (.htaccess bzw. redirect), was es für eine Offline-Testumgebung einfacher macht.

Plug-ins wie Polyglott_XH oder Sitemapper sehe ich da schon eher problematisch.

Solange kein PHP-Profi diese beiden anpasst, kann man sie leider nicht damit nutzen.
Aber um hreflang optimal zu bedienen, ohne jede einzelne Webseite einzeln anzupassen, ist eine manuell gepflegte sitemap.xml eh besser, solange das Plug-in nicht mehr aktualisiert wird. Die Handarbeit dafür hält sich in Grenzen (einmal per Onlinetool generieren oder manuell eine alte Plug-in Version umschreiben, danach immer nur Veränderungen nachtragen).

Vielleicht ist die PHP-Codeanpassung ähnlich einfach wie die Domain-Erkennung, mit der ich Franks geniales Template fhs-whitespace optimiert habe:

Als Beispiel ein Ausschnitt aus der …
template.htm vorher:

Code: Select all

<html lang="<?=$sl;?>">

template.htm nachher:

Code: Select all

<?php if ($_SERVER['SERVER_NAME'] == 'de-domain.info'):?>
	<html lang="de">
<?php elseif ($_SERVER['SERVER_NAME'] == 'en-domain.info'):?>
	<html lang="en">
<?php endif;?>

Seit vorgestern auch zur vollautomatischen Anpassung von Logo, Titel, Sprachauswahlmenü + Footer im praktischen Einsatz.