Mehrere Websites: Siteaccesses #

Ein Siteaccess ist ein benannter Satz von Einstellungen, der für eine Anfrage gilt: welches Design, welcher Teil des Inhaltsbaums, welche Sprache, ob Besucher sich anmelden müssen. Eine Installation, eine Datenbank, viele Siteaccesses. Sie richten ein:

Warnung .htaccess bremst jede Anfrage. Sind .htaccess-Dateien erlaubt (AllowOverride alles außer None), geschweige denn genutzt, sucht Apache sie bei jeder Anfrage in jedem Verzeichnis des Pfads und liest und wertet sie aus, und die Ladezeiten der Seiten steigen drastisch (gemessen). Die einzige wirkliche Abhilfe ist, die Funktion für den virtuellen Host abzuschalten: AllowOverride None im virtuellen HTTPS-Host, und die Regeln in der Konfiguration des virtuellen Hosts selbst als mod_rewrite-Regeln. Das ist in Geschwindigkeitstests im Produktivbetrieb weit schneller und die Zeit für die Optimierung einer Produktivkonfiguration unbedingt wert. Stellen Sie sofort um: Übernehmen Sie die Regeln des Beispiels für einen virtuellen HTTPS-Host in Ihren virtuellen Host (mit dem statischen Cache auch staticcache_offload.conf), setzen Sie AllowOverride None, führen Sie apachectl configtest aus, laden Sie Apache neu und testen Sie die Website. Dieselben Regeln für andere Server: nginx, LiteSpeed, Caddy, IIS, Velocity (eingebaut); wohin Regeln für virtuelle Hosts in einem Control Panel gehören: Plesk, cPanel, DirectAdmin, ISPConfig. Unter LiteSpeed oder OpenLiteSpeed kann zusätzlich der Seiten-Cache des Servers anonyme Besucher und Crawler ohne PHP bedienen: Seiten-Caching mit LiteSpeed und OpenLiteSpeed.

Voraussetzungen: eine funktionierende Installation mit dem Siteaccess admin; die drei Hostnamen zeigen auf den Server, und der Webserver antwortet für alle mit demselben Document Root (Webserver-Beispiele); zwei Ordner Site A und Site B unterhalb der Wurzel des Inhaltsbaums (notieren Sie ihre Knoten-IDs, hier 60 und 61).

1. Die Liste und die Zuordnung #

Die Auswahl des Siteaccess gilt für die ganze Installation und gehört deshalb in das globale Override, settings/override/site.ini.append.php (wird niemals committet: es enthält auch das Datenbankpasswort):

<?php /* #?ini charset="utf-8"?

[SiteSettings]
DefaultAccess=site_a

[SiteAccessSettings]
AvailableSiteAccessList[]
AvailableSiteAccessList[]=site_a
AvailableSiteAccessList[]=site_b
AvailableSiteAccessList[]=admin
# Siteaccesses that share this database (the administration shows and clears their caches)
RelatedSiteAccessList[]
RelatedSiteAccessList[]=site_a
RelatedSiteAccessList[]=site_b
RelatedSiteAccessList[]=admin
# Choose the siteaccess by the host name only
MatchOrder=host
HostMatchType=map
HostMatchMapItems[]
HostMatchMapItems[]=www.example.com;site_a
HostMatchMapItems[]=www.example.org;site_b
HostMatchMapItems[]=admin.example.com;admin

*/ ?>

• MatchOrder listet die Prüfungen in der Reihenfolge, in der sie versucht werden: uri (das erste Segment des Pfads, /site_b/...), host, host_uri (Host und Segment zusammen, HostUriMatchMapItems[]=example.com;de;site_de), port, servervar. Der ausgelieferte Standardwert ist uri;host;port.
• Passt nichts, antwortet DefaultAccess.
• HostMatchMethod=start (oder ;start als viertes Feld eines Eintrags) passt auch auf Testhosts, die mit dem Namen beginnen, etwa www.example.com.test.local; siehe Siteaccess nach Host-Präfix.

2. Die Einstellungen jedes Siteaccess #

Jeder Siteaccess hat ein Verzeichnis settings/siteaccess/<name>/. Was sich je Website unterscheidet, gehört dorthin.

settings/siteaccess/site_a/site.ini.append.php:

<?php /* #?ini charset="utf-8"?

[SiteSettings]
SiteName=Example A
SiteURL=www.example.com
DefaultPage=/content/view/full/60
IndexPage=/content/view/full/60

[SiteAccessSettings]
RequireUserLogin=false
# The URL alias of Site A's folder is not repeated in every address
PathPrefix=Site-A

[DesignSettings]
SiteDesign=mysite
AdditionalSiteDesignList[]
AdditionalSiteDesignList[]=base

[RegionalSettings]
Locale=eng-US
ContentObjectLocale=eng-US
SiteLanguageList[]
SiteLanguageList[]=eng-US

[FileSettings]
VarDir=var/site_a

*/ ?>

settings/siteaccess/site_a/content.ini.append.php (die Wurzel der Menüs und von fetch ohne Elternknoten):

<?php /* #?ini charset="utf-8"?

[NodeSettings]
RootNode=60

*/ ?>

settings/siteaccess/site_b/ ist genauso aufgebaut, mit SiteName=Example B, SiteURL=www.example.org, Knoten 61, PathPrefix=Site-B, VarDir=var/site_b und Deutsch an erster Stelle:

[RegionalSettings]
Locale=ger-DE
ContentObjectLocale=ger-DE
SiteLanguageList[]
SiteLanguageList[]=ger-DE
SiteLanguageList[]=eng-US

SiteLanguageList[] ist die Reihenfolge, in der Inhaltssprachen angezeigt werden; die Sprachen müssen vorhanden sein (Setup > Sprachen). Der Siteaccess admin behält seine eigenen Einstellungen; tragen Sie dort SiteLanguageList[] für beide Sprachen ein.

VarDir je Website hält die Caches und den Speicher jeder Website getrennt. Um alle ihre Logs und Caches mit je einer Zeile in eigene Verzeichnisbäume zu legen, verwenden Sie LogVarDir, CacheVarDir und INICacheDir=site im globalen Override: Logs, INI-Cache und Ablaufzeitstempel je Website. Mit CacheVarDir muss der Webserver auch die öffentlichen Caches darunter ausliefern: Aktivieren Sie die auskommentierte Regel var_cache in .htaccess_root (oder die entsprechende Regel im Beispiel für Ihren Server). Tun Sie das in Ihrer Kopie, .htaccess (an ihren Platz gebracht mit ./console exp:setup:htaccess --apply), nie in der Vorlage. Von da an unterscheidet sich Ihre .htaccess von .htaccess_root: Nach einem Upgrade zeigt ./console exp:setup:htaccess diese Zeile unter den Unterschieden und weigert sich ohne --force zu kopieren; nach --force --apply aktivieren Sie die Regel wieder (.htaccess und config.php von der Konsole aus einrichten).

Einstellungen in einer Erweiterung. Eine Website-Erweiterung kann stattdessen extension/<ext>/settings/siteaccess/<name>/ mitbringen, sodass die Einstellungen unter Versionskontrolle stehen; siehe Einstellungen je Website in Erweiterungen.

3. Leeren und prüfen #

php bin/php/ezcache.php --clear-tag=ini --allow-root-user
./console exp:ini get site.ini/SiteSettings/SiteName -s site_b --allow-root-user
curl -sI https://www.example.org/ | head -1

Erwartet: Example B und HTTP/... 200 (oder eine Weiterleitung auf die Startseite). Jede Website zeigt ihren eigenen Teilbaum in ihrer eigenen Sprache; https://admin.example.com/ verlangt eine Anmeldung. Unter Velocity starten Sie Velocity nach einer Änderung an einem Siteaccess neu (./console exp:velocity restart --allow-root-user): Seine Worker halten die Einstellungen im Speicher.

Auf der Kommandozeile nimmt jedes Skript den Siteaccess mit -s (--siteaccess) entgegen: php runcronjobs.php -s site_b frequent --allow-root-user.

Für diese Seite geprüft (2026-10-18): Jede genannte Einstellung existiert in der ausgelieferten settings/site.ini oder settings/content.ini mit der beschriebenen Bedeutung; die Host-Zuordnung und ihre Methoden sind die aus doc/eng-us/features/6.0/siteaccess-host-and-language-matching.md. Die Konfiguration wurde für diese Seite nicht auf eine Website angewendet.

Häufige Fehler #

Abgeleitet aus #

• settings/site.ini ([SiteAccessSettings], [SiteSettings], [DesignSettings], [RegionalSettings], [FileSettings])
• settings/content.ini ([NodeSettings] RootNode), settings/siteaccess/mysite/site.ini.append
• doc/eng-us/features/6.0/siteaccess-host-and-language-matching.md, doc/eng-us/features/6.0/multi-site-log-and-cache-paths.md

Verwandte Seiten #

• Kochbuch
• Platzierungen von Einstellungs-Overrides, Einstellungen auf der Kommandozeile ändern
• INI-Einstellungen: site.ini Block für Block, mit Standardwerten
• Übersetzungen, Caching
• Die Programmierregeln und der Musterkatalog: die Standards
• Freie Dokumentation: Diese Seite darf frei kopiert, übersetzt und verbessert werden.