Website in der Website

Dass man diese Art der "Website in der Website" auch für mobile Nutzungen gebrauchen kann ist nicht sofort ersichtlich, ergibt sich aber recht simpel aus folgender Überlegung:

1. Auf mobilen Geräten ist trotz der Flatrates der Datentransfer ein Nadelöhr, also ist weniger mehr!
2. Wir brauchen folgende Infos:
   Impressum/ eMail/ Telefonnummer/ Standortbeschreibung/ Öffnungszeiten/ Kurzangebote-Leistungen

Das war's schon. Und wenn man dafür nur ein "mobiles layout" als Vorlage anlegt und in die entsprechenden Rubriken/ Menüpunkte mit {SHOW_CONTENT Artikel aus dem Desktopbereich} hantiert, hat man neben seiner Desktopausführung schnell eine mobile Seite mit einer einzigen Datenbank zusammen und funktionstüchtig. Es ist weniger Arbeit, als alles noch einmal mit einem separaten CMS zu erstellen.

Die Idee:

Mit Hilfe von ein paar logischen Zusammenhängen, wird schnell klar, dass es möglich sein muss, mit Hilfe einer weiteren TLD oder Subdomain bestimmte Teile der Website anzusteuern, ohne dafür ein komplettes neues System zu installieren.

Aber ich gebe dabei zu bedenken, dass die Daten alle in ein und derselben Datenbank geführt werden. Mit einer solchen Website in der Website auf einen anderen Server umzuziehen dürfte ein wenig aufwendig werden!

Grundsätzlich sind alle normalen Server/ Hoster so konfiguriert, dass man mit einer TLD nur einen Ordner im Webspace ansteuern kann und keine Sripte. Mit Hilfe der LEVEL-ID kann man eine Website wie folgt strukturieren

• HOME----------(0)
• ---WEB1-----------(1)
  • Bereich1----(2)
  • bereich2----(2)
  • bereich3----(2)
• ---Web2 -----------(1)
  • Bereich4----(2)
  • bereich5----(2)
  • bereich6----(2)  u.s.w.

Mit der TLD soll nun WEB1 oder WEB2 angesteuert werden, welche auch einen entsprechenden alias-Namen haben.

WEB1 und WEB2 werden/ können  unterschiedliche Layouts und HTML-Vorlagen zugeordnet. Dadurch sieht WEB1 u.U. vöiig anders aus als WEB2.

Änderung in R530!

Mit der Version R 530 gab es einige konzeptionelle Änderungen. Das Script wie rechts läuft da nicht mehr. Ergo, einfach das Teil als php-Script mit den entsprechenden Anfangs- und Ende-Notationen speichern als /content/pages/name.php und von (in meinem Falle) HOME aus mit CP "ext. Content" das Script aufrufen und schon klappts auch wieder mit der schönen Nachbarin

Lösungsansatz

Voraussetzung für eine solche Lösung ist unbedingtes Einhalten einer LEVEL-ID-Struktur.

Ebenfalls braucht man eine Menüführung, die nur in diesem Level funktioniert und keine höheren Level ansteuert! Ich habe dafür eine horizontale Menüführung modifiziert:

In der Vorlage wurde folgendes Installiert:

<div style="position:absolute; top:110px; right:0px;" id="menu_container">
{ NAV_HORIZ_DD:412,3 }
</div>

Die ID 412 ist der Beginn von einem ausgewählten Webbereich für eine bestimmte TLD. Ebenso werden die anderen Menüs verwendet. Bis zu einer relativen Tiefe 3 werden die Menüs entsprechend angezeigt.

Ansteuerung durch TLD auf alias

Die gesamte phpWCMS-Konstruktion beginnt IMMER bei HOME (Level 0). Genau an dieser Stelle muss spätestens die Entscheidung fallen, welche TLD wurde aufgerufen und wohin soll die Reise gehen?

Dafür habe ich ein kleines Script geschrieben, dass man in einen HTML-CP unter HOME (oder unter /content/pages/ oder als tld.php im root ablegt), welches diese Fragen beantwortet. Je nach Konfiguration - vor allem ab Version 1.8.x sollten diese Scripte mit Bedacht abgelegt werden:

[ PHP ]
$DomainName = strtolower($_SERVER['HTTP_HOST']);
// www. in Domainname nicht enthalten?
if (strpos($DomainName,'www.') === false)
{ $DomainName = "www.".$DomainName; }
switch($DomainName)
{

case 'www.MeineTLD1.de':
header( "HTTP/1.1 301 Moved Permanently" );
headerRedirect('/aliasTLD1.html');
break;

case 'www.lMeineTLD2.de':
header( "HTTP/1.1 301 Moved Permanently" );
headerRedirect('/aliasTLD2.phtml');
break;

.....

default: .....
}

[ /PHP ]