Hier eine Anleitung, wie man eine einzige Drupal Installation für verschiedene Projekte verwendet. Drupal ist für diese Art Installation bereits ausgelegt. Wie geht man aber vor, wenn man als Konfigurationssoftware Plesk auf dem Server verwenden möchte? Viele Server-Hoster bieten Ihre Rootserver Pakete mit vorinstallieren Plesk an. Es wäre also äußerst ärgerlich, wenn man auf den Komfort verzichten müsste.

Wieso ist das eigentlich ein Problem?

Um eine einzige Drupal-Installation für mehrere Projekte nutzen zu können (der sogenannte Multi-Site Modus), muss der Webserver so konfiguriert werden, dass die Domain, die die Drupal-Installation beherbergt, für jedes weitere Projekt ein Domainalias zugewiesen werden muss. Das ist normalerweise auch kein Problem, da man dies einfach in der httpd.conf ergänzen könnte. Ein andere Weg wäre, dass man über Plesk dem Hauptprojekt einfach alle Projekt, die damit betrieben werden sollen, als ein Domainaliase zuweist. Der Nebeneffekt davon wäre aber, dass man dann nicht mehr die Funktionalität von Plesk für die einzelnen Projekte nutzen kann (wie z.B. projektbezogene E-Mailaccounts, Quota oder Webstatistiken).

Es gibt einen Ausweg

Hier zeige ich auf, wie man dennoch den vollen Umfang von Plesk nutzen kann, obwohl nur ein Projekt also Drupalinstallation dient.

Folgendes ist gegeben:

  • hosting.de (das Hauptprojekt, welches die Drupal-Installation beinhaltet und unter /srv/www/vhosts/hosting.de/httpdocs zu finden ist)
  • projekt_a.de (erstes Projekt in der Multi-Site Umgebung)
  • projekt_b.de (zweites Projekt in der Multi-Site Umgebung)
  • projekt_c.de (drittes Projekt in der Multi-Site Umgebung)
  • projekt_d.de (viertes Projekt in der Multi-Site Umgebung)

Alle 4 Projekt werden weiterhin als eigenständige Domains innerhalb der Plesk-Administration geführt. Auf hosting.de wird Drupal installiert, alle anderen Projekte werden über die Dateien dieser Installation versorgt.

Der ganze Trick besteht eigentlich darin, dass man für jedes Projekt, welche man innerhalb der Multi-Site Umgebung verwenden will, die Webserverkonfiguration über die jeweilige conv/vhost.conf Datei anpasst. Diese Anpassung ist für alle Projekte notwendig, die innerhalb der Multi-Site Umgebung verwendet werden sollen.

Hier einige Beispiele, wie ein vhost.conf aussehen könnte (normalerweise existiert diese Datei nicht und muss erst angelegt werden):

/srv/www/vhosts/projekta.de/conf/vhost.conf mit Public Download-Methode:

DocumentRoot /srv/www/vhosts/hosting.de/httpdocs
<Directory /srv/www/vhosts/hosting.de/httpdocs>
    php_admin_flag engine on
    php_admin_flag safe_mode off
    php_admin_value open_basedir "/srv/www/vhosts/hosting.de/httpdocs:/tmp:/usr/share/php5"
</Directory>

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.projekta\.de$
RewriteRule ^(.*)$ http://www.projekta.de$1 [L,R=301]

Der Abschnitt mit ab RewriteEninge ist nicht essentiell und kann daher auch weggelassen werden (er ist dafür gedacht, dass alle Domainalias auf die Projekthautdomain weitergeleitet werden und so DC (doppelten Content) bei Suchmaschinen verhindern soll). Wichtig ist allerdings, falls mod_rewrite Anweisungen gemacht werden müssen, dass diese ausserhalb der Directory Anweisung gemacht werden. Keine Sorge, diese Anweisungen sind dennoch nur für das aktuelle Projekt gültig und hat keine Auswirkungen auf andere Projekte. Grund dafür ist, dass Plesk die komplette vhost.conf innerhalb des Virtuelhost Blocks inkludiert.

/srv/www/vhosts/projektb.de/conf/vhost.conf mit Private Download-Methode:

DocumentRoot /srv/www/vhosts/hosting.de/httpdocs
<Directory /srv/www/vhosts/hosting.de/httpdocs>
    php_admin_flag engine on
    php_admin_flag safe_mode off
    php_admin_value open_basedir "/srv/www/vhosts/hosting.de/httpdocs:/srv/www/vhosts/projekt_b.de/dateien:/tmp:/usr/share/php5"
</Directory>

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.projekt_b\.de$
RewriteRule ^(.*)$ http://www.projekt_b.de$1 [L,R=301]

Hier die /srv/www/vhosts/projekt_b.de/conf/vhost.conf für projekt_b.de. projekt_b.de unterscheidet sich von projekta.de darin, dass innerhalb Drupal die Download-Methode auf Privat steht. Es ist also wichtig, dass der Dateisystem-Pfad außerhalb des DOCUMENT_ROOT Verzeichnisses untergebracht wird. Um nun auch die Quota-Einstellungen von Plesk benutzen zu können, muss dieses Verzeichnis innerhalb von /srv/www/vhosts/projektb.de angelegt werden. Hier verwende ich /srv/www/vhosts/projektb.de/dateien. Da mit Plesk der Dateizugriff durch openbase_dir eingeschränkt wird, muss hier das Verzeichnis zum Dateisystem-Pfad angegeben werden, um keine Fehlermeldungen innerhalb Drupal zu erhalten.

Es können nun für die einzelnen Projekte die Konfigurationsdateien für die Datenbankverbindung angelegt werden, so wie es für die Multi-Site Installation von Drupal auch vorgesehen ist. Für jedes Projekt wird eine eigene Datenbank verwendet. Wenn man nur eine Datenbank zur Verfügung hat, kann man auch mit unterschiedlichen Tabellenpräfixen arbeiten. Wichtig ist aber, dass für jedes Projekt eine Unterscheidung stattfindet und nicht die gleichen Tabellen verwendet werden.

Im Verzeichnis sites werden also für die Projekte die Verzeichnisse angelegt: Inhalt des Verzeichnisses sites Der Verzeichnisname muss mit dem Domainnamen übereinstimmen. Falls man Domainaliase für ein Projekt verwendet, reicht es nicht, wenn man innerhalb Plesk diese Aliase zuweist. Es muss für jedes Alias ein symbolischer Link zur Hauptdomain erstellt werden. Wie im Beispiel zu sehen ist, wurden für die Domain projekt_d.de zwei symbolische Links angelegt (Domain projektd.de und projektd.com).

Der Inhalt innerhalb eines Projekt-Verzeichnisses sieht wie folgt aus: Inhalt des Verzeichnisses für projekt_a.de Es wird als darin jeweils eine Kopie der Datei sites/default/settings.php abgelegt und die Datenbankverbindung für die jeweilige Domain angepasst. Im Unterverzeichnis themes werden die Themes abgelegt, die nur diesem Projekt zur Verfügung stehen sollen. Genauso ist es mit dem Unterverzeichnis modules: hier werden Module installiert, die nur für dieses Projekt verwendet werden sollen. Falls man Module verwenden will, die in mehreren Projekten gleichzeitig eingesetzt werden, so sollten diese im Verzeichnis sites/all/modules abgelegt werden. Diese Vorgehensweise hat den großen Vorteil, dass ein Modul nur ein einziges Mal vorhanden sein muss, was das Updaten auf eine neuere Modulversion um einiges schneller oder übersichtlicher macht. Das Verzeichnis dateien dient für projekt_a.de zur Dateiablage (öffentliche Download-Methode).

Besonderheiten

Beachtet werden sollte, dass die .htaccess Datei im Drupal Hauptverzeichnis für alle Projekte gleichzeitig genutzt wird. Projektbezogene Webserveranweisungen müssen also immer in der jeweiligen conf/vhost.conf durchgeführt werden. Desweiteren muss darauf geachtet werden, dass innerhalb der Drupaleinstellungen für jedes Projekt ein unterschiedlicher Dateisystem-Pfad für die Dateiablage verwendet wird. Wenn die Download-Methode Public verwendet wird, bietet sich hierfür ein Unterverzeichnis im Sites-Projektverzeichnis an. (siehe weiter oben). Weiterhin müssen alle projektrelevanten Dateien im jeweiligen Sites-Projektverzeichnis abgelegt werden, die betrifft z.B. favicon.ico, Bilder für die Templates oder eventuell benötigte Javascript-Bibliotheken.

Diese Anleitung funktioniert nur ab Drupal Version 5.0, da in älteren Versionen noch globale Dateien benutzt werden (wie z.B. drupal.css), wodurch eine Multi-Site Nutzung um einiges verkompliziert, wenn nicht gänzlich unmöglich gemacht wurde.

Einschränkungen

Die Multi-Site Nutzung bringt leider auch einige Schattenseiten mit sich. Zum einen kann man nur eine zentrale robots.txt Datei für alle Projekte gleichzeitig nutzen, da der Suchmaschinen-Bot die robots.txt immer im Hauptverzeichnis erwartet. Diese Einschränkung ist im Normalfall aber kein Problem, da meist die gleichen Verzeichnisse/Dateien ausgeschlossen werden - es ist ja überall die gleiche Software. Wenn von einem Multi-Site Projekt doch ein bestimmtes Verzeichnis ausgeschlossen werden soll, kann man das in der globalen robots.txt aufnehmen. Dieser Eintrag sollte den anderen Projekten nicht schaden. Eine weiterer Hinweis zur Multi-Site Installation muss bezüglich der Sicherheit gemacht werden. Alle Projekte innerhalb dieser Installation können/müssen mit dem gleichen FTP Zugang gepflegt werden. Auch die openbase_dir Einschränkung ist so gesetzt, dass über ein PHP Skript eines Projekt auf alle anderen Dateien der anderen Projekte zugegriffen werden könnte, da für jedes Projekt openbase_dir so gesetzt werden muss, dass auf das Hauptprojekt, welches die Drupaldateien beherbergt, zugegriffen werden können muss.

Tipps

Man sollte versuchen die Anzahl der gemeinsam genutzten Module (im Verzeichnis sites/all/modules) möglichst gering zu halten, um ein schlankes System zu führen, was sich hinsichtlich der Performance positiv bemerkbar machen wird. Wenn ein Modul nur für ein bestimmtes Projekt benötigt wird, dann sollte diese auch im jeweiligen modules Verzeichnis für dieses Projekt installiert werden.

Wenn Module im sites/all/modules Verzeichnis aktualisiert wurden, ist es notwendig, dass man auf jedem einzelnen in der Multi-Site Umgebung befindenden Projekt die update.php Datei ausführt. Durch das Ausführen der update.php werden gegebenenfalls Datenbankanpassungen durchgeführt, die die neuere Modulversion erfordert. Die gleiche Vorgehensweise muss angewendet werden, wenn ein Drupal Core Update durchgeführt wird. (am)

Aktualisiert: