Fertiges Drupal-Projekt in Multidomain-Projekt umwandeln

... an Einstellungen rumzufummeln, ohne sie vorher auf einer Testumgebung zu testen.

Das glaube ich dir nicht. Wo ist deine settings.php? Welches Verzeichnis wird für hochgeladene Dateien verwendet?

Indem du weitere Installationen zu deiner Installation hinzufügst:

1. Datenbank für neue Site anlegen.
2. Verzeichnis sites/example.com anlegen.
3. sites/default/default.settings.php nach sites/example.com/settings.php kopieren.
4. http://example.com aufrufen um die Datenbanktabellen und sonstige Einträge für die neue Site anzulegen.

--

Es wird danach 2 ganz gleichwertige Projekte in der einen Installation geben (später 3).

Du meinst also, man kann das erste Projekt in
sites/all
belassen und das zweite Projekt in
sites/domain2.de
anlegen?

Jedenfalls schreibst Du nichts davon, das bestehende Projekt von
sites/all
nach
sites/domain1.de
zu migrieren. Muss man das nun oder nicht?

Brauchst du nicht, solange du meine obigen Fragen unbeantwortet lässt.

--

Zu den obigen Fragen:

Die settings.php ist in
sites/default

Und die wird dann einfach kopiert und in
sites/domain1.de
für diese Domain und dazugehörige Datenbank angepasst. Richtig?

Alle hochgeladenen Files (sehr viele) befinden sich in
sites/default/files
und diese zu verschieben ist fast unmöglich, weil die Pfade ja auch in der Datenbank gespeichert sind.

Daher ist die Frage, ob man nun das erste, bereits bestehende Projekt in
sites/default/files
und
sites/all
belassen kann und die 2 weiteren Projekte mit je eigener zusätzlicher Domain in
sites/domain1.de
sites/domain2.de
anlegen kann und ob das so zusammenspielt.
Danke.

Und dieses Verzeichnis ist es auch, das du am ehesten als Verzeichnis des Projektes bezeichnen kannst. Löse dich von dem Gedanken, das sites/all alleine der jetzigen Website gehört, sites/all gehört allen Websites, die du mit der Codebase anbietest.

Das ist sehr schön. Dann kommen sich die Dateien der alten Site und die Dateien der neuen Site nicht in die Quere.

Richtig. Deshalb auch der Warnhinweise auf der Seite zur Konfiguration der Dateisystemeintelllungen.

Jetzt musst du nur noch wie in meiner ersten Antwort beschrieben vorgehen und dabei darauf achten, das die Konfiguration deiner bestehenden Site immer noch gefunden wird. Hierzu ein Auszug aus der INSTALL.txt:

--

Danke, das klingt irgendwie logisch und ich werde es so versuchen.

Noch eine Detailfrage: Wenn man es ganz genau machen will, müssten eigentlich Module, welche nicht von allen Projekten, sondern nur vom ersten (bereits bestehenden) Projekt genutzt werden, von

Eine Multisite-Installation wird ja deshalb verwendet, damit sich mehrere Sites den Quellcode teilen können. Diesen Vorteil verspielst du wenn du die Module von sites/all/modules nach sites/default/modules verschiebst. Ich würde es ersteinmal so lassen wie es ist. Performance kostet das lediglich auf index.php?q=admin/build/modules.

Der einzige Grund, das gleiche Modul foo sowohl in sites/site1/modules als auch in sites/site2/modules zu haben, ist folgendes Szenario:

• In sites/all/modules ist foo-6.x-1.0 installiert.
• site1 verwendet bar-6.x-1.0, welches foo-6.x-1.0 verwendet.
• site2 verwendet baz-6.x-1.0, welches ebenfalls foo-6.x-1.0 verwendet.
• Es wird das Sicherheitsupdate bar-6.x-1.1 veröffentlicht. Diese läuft aber nur mit foo-6.x-1.1.
• foo-6.x-1.1 ist inkompatibel mit baz-6.x-1.0, es gibt aber keine Version von baz, die kompatibel mit foo-6.x-1.1 ist.

Erst in so einem Falls würde es Sinn machen, foo-6.x-1.0 nach sites/sites2/modules zu verschieben und foo-6.x-1.1 nach sites/sites1/modules zu installieren. Das kannst du aber machen wenn es aktut wird (falls es überhaupt irgendwann akut wird).

--

Ja, danke, deine Erklärung betrifft einen Sonderfall.

Aber ich nehme an, Du hast meinen Text nicht genau gelesen, denn ich schrieb:

Eine anderer Punkt:

Was ist eigentlich bei der Konfiguration des Webservers zu beachten, wenn die 2. Domain und dann die 3. Domain draufgeschaltet wird, um diese beim Multidomain-Projekt zu aktivieren?

• Müssen sie nicht,
• können sie aber,
• sollen sie aber nicht.

Du kannst in der .htaccess nur einen Wert für RewriteBase angeben. Wenn das aufgrund deines Setups nicht ausreicht, dann musst du RewriteBase stattdessen in der Konfiguration des Virtual Hosts angeben.

--

Mal von vorne:

Derzeit existiert ein normales Drupal-Projekt mit deiner Domain.

Nun soll eine zweite Domain draufgeschaltet werden. Einfach die DNS-Konfiguration so machen, dass das jetzige Projekt über beide Domains erreichbar ist? Sonst noch was?

Dann wird Drupal um das 2. Projekt erweitert in
sites/domain2.de

Und was muss nun noch alles sowohl bei der Serverkonfiguration/Domainkonfiguration als auch bei Drupal gemacht werden, damit www.domain2.de das 2. Projekt zeigt und www.domain.de wie bisher das 1. Projekt zeigt?

Ja, klar.

Kommt auf die Konfiguration des Webservers an.

Wenn die neue Site die gleiche IP-Adresse wie die alte Site hat, dann musst du die neue Site als namensbasierten VirtualHost einrichten. Wenn du für die alte Site bereits einen namensbasierten Virtual Host verwendest, dann reicht dazu ein ServerAlias in der Konfiguration des Virtual Host. Wenn du im Moment keinen namensbasierten Virtual Host einsetzt, dann musst du einen namensbasierten Virtual Host anlegen. Das DocumentRoot muss dann gleich dem der existierenden Site sein.

Wenn die neue Site eine andere IP-Adresse als die alte Site hat, dann musst du einen IP-basierten Virtual Host anlegen.

Ja. Wenn du aber an der Konfiguration des Webservers etwas geändert hast, dann musst den Webserver dazu veranlassen, die Konfiguration neu einzulesen (z.B. durch einen Neustart des Webservers).

Eben hast du noch von domain2.de gesprochen. Du solltest dich entscheiden, ob du nun www.domain2.de oder domain2.de haben willst. Den anderen Hostnamen solltest du dann auf die von dir präferierte Site weiterleiten lassen.

--

Ich will überall alles mit www.domainX.de ansprechen, also immer mit www. Damit keine Seiten ohne www aufrufbar sind, kann ich auch in der page.tpl.php entsprechende Umleitungen mit header() realisieren, aber darum geht es hier ja gar nicht.

Virtuelle Hosts werden bereits verwendet.

Also ist nichts anderes zu tun, als die Domain auf den gleichen Webspace zeigen zu lassen, entsprechend einen VirtualHost-Eintrag für die zusätzliche Domain machen und die DocumentRoot auf das gleiche Verzeichnis zeigen lassen.

Ist das wirklich alles?

Brauchst du aber nicht. Es reicht wenn du sicherstellst, das sich kein Webserver angesprochen fühlt.

--

Klar, aber ich habe keinen Zugriff auf die Serverkonfiguration, also mache ich das lieber selbst in PHP, jedenfalls das was möglich ist und dieser Punkt ist gut machbar in PHP.

Wenn nun die 2. Domain (domain2.de) noch nicht verfügbar ist (kann erst später verwendet werden) und ich aber das gesamte Verhalten von Drupal schon jetzt testen und das 2. Projekt bereits anlegen und ein Theme dafür erstellen will, kann ich das ganze dann auf diese Art simulieren?

Ich erstelle vorerst das 2. Projekt als Subprojekt
sites/domain1.de/sub2

Sprich auf www.domain1.de/sub2 erscheint dann, wenn ich es richtig in den settings.php anlege, mein 2. Projekt, welches später umgestellt wird (bevor es wirklich online geht) auf www.domain2.de und
sites/domain2.de

Kann man das so testen und simulieren?

Ich möchte nämlich wissen, wie man unterschiedlie Menüs einrichtet für jedes der Projekte und wie andere Dinge getrennt oder eben nicht getrennt ablaufen (z. Bsp. Cronjob, etc).

Das funktioniert nicht. Drupal schaut dort nicht nach einer settings.php. Dazu habe ich in meiner dritten Antwort einen Ausschnitt aus der INSTALL.txt zitiert. Wenn du es so machen wolltest, dann müsstest du sites/domain1.de.sub2 als Konfigurationsverzeichnis verwenden. Außerdem müsstest du einen Alias von deinem derzeitigen DocumentRoot auf die URL http://www.domain1.de/sub2 anlegen, was du aber sowieso nicht kannst, da du ja keinen direkten Zugriff auf deine Webserverkonfiguration hast.

Außerdem gibt es beim umschalten auf das Live-System natürlich Probleme mit dem Umstricken der URLs in der Datenbank.

Besser ist es, während der Entwicklung in der HOSTS-Datei des Clients dem beabsichtigten Hostnamen die IP-Adresse der jetzigen Site zuzuordnen. Unter MS-Windows heißt die Datei meistens C:\Windows\system32\drivers\etc\hosts.

Da bei Multisite-Installationen lediglich der Code wiederverwendet wird, sieht es (sobald die richtige settings.php gefunden wurde) für Drupal so aus, als ob die jeweils aktuelle Site die einzige wäre, die vberwendet wird.

--

Sorry, habe mich schon wieder mal vertippt, ich meinte natürlich

Damit sollte ein Test doch funktionieren, ohne einen Alias im Webserver zu benötigen.

Kann ich da nicht über www.domain1.de/sub2 das 2. Projekt aufrufen?

Und ich könnte ja eventuell im Ordner /sub2 per FTP eine Art Umleitung auf / einrichten. Gibt es da eine Lösung, das allein mit FTP zu machen, ohne Serverkonfiguration ändern zu müssen?

Nein. Nach der Umleitung weiß der Webserver nicht mehr, das du ursprünglich www.domain1.de/sub2 haben wolltest. Wenn der Webserver es nicht weiß, dann kann er diese Information auch nicht an Drupal weitergeben. Drupal behandelt die Anfrage also so als ob von vornherein www.domain1.de gefragt wäre.

--

Und was ist, wenn ich in /sub2/index.php ein
include("/index.php");
einbaue?

Dann befindet man sich doch weiterhin in /sub2, genau das will doch Drupal. (Ist nur mal für Testwecke, wird natürlich später alles ordentlich gelöst)

Das geht leider nicht, Drupal selbst verhindert das mit einer Fehlermeldung:

Gibt es keine andere Möglichkeit, das zu testen/simulieren? Geht das vielleicht mit einer RewriteRule in der .htaccess?

Edit: Mit einer RewriteRule funktioniert es auch nicht, da erscheint einfach die normale /index.php, so als wäre man nicht im Unterverzeichnis.

Gute Idee falsch umgesetzt :-)

Das liegt nicht an Drupal. Das liegt an deiner PHP-Konfiguration und an deiner falschen include-Anweisung. Vielleicht würde aber folgende index.php funktionieren:

--

Was macht eigentlich chdir(dirname(dirname(__FILE__))) ?

Das scheint zu funktionieren, beim Aufruf von domain1.de/sub2 erscheinen lauter Fehlermeldungen, da die Datenbank-Tabellen mit dem Prefix in der konfigurierten Form noch nicht existieren.

Jetzt muss man doch domain1.de/sub2/install.php aufrufen.
Das geht natürlich nicht.

Habe noch eine /sub2/install.php mit folgendem Inhalt erzeugt:

Dann beginnt die Drupal-Installation! Es scheint wirklich zu gehen, allerdings sind alle Pfade zu den css-Dateien falsch, die Installationsseiten werden also ohne Design angezeigt, weil die css-Dateien nicht gelesen werden können.

Funktioniert also nur so halb, an dieser Stelle habe ich mal abgebrochen.

Denn wie sollen da suchmaschinenfreundliche URLs funktionieren? Geht ja dann auch nicht, das sieht man jetzt schon.

Das Arbeitsverzeichnis wechseln, genau so wie cd auf der Kommandzeile. __FILE__ ist der Name der aktuellen Datei, dirname liefert dir den Pfad zum Verzeichnis einer Datei, die du per Name übergibst.

--