Fragen zum Aufsetzen von neuen Multisites

Hallo und herzlich willkommen bei Drupal!

Ich will mal versuchen, ein paar Deiner Fragen zu beantworten.

Installieren solltest Du nur über den Composer, der ist quasi ein Paketmanager für Drupal, Module, Themes und Libraries. Benötgte Abhängigkeiten werden so automatisch mitgezogen. Und gleich richtig anzufangen, bedeutet mit Composer.

Zu den Multisites: Sollen die alle die gleichen Module und Themes haben, oder ist das dann sehr unterschiedlich? Im zweiten Fall würde ich mich gar nicht mit den Multisites aufhalten, sondern für jede Seite eine eigene Drupalinstallation anlegen. Macht vielleicht auch spätere Fehlersuchen einfacher, und die anderen Seiten funktionieren weiter, auch wenn eine ein Problem hat.

Für richtig individuelles Design ist eine eigenes Theme sicher am besten, es gibt einige bei denen man recht einfach Subthemes anlegen kann und das dann entsprechend anpassen.

Hallo Sammelzwerg,

danke für eine sehr schnelle Antwort!

Das gilt auch für eine frische Installation von Drupal selbst? Also ich habe bisher keine Module, Themes, etc. dazu installiert, nur das slitterfasernackte Drupal per SFTP hochgeladen. Module, etc. würde ich natürlich gleich schon mit Composer machen.

Ja, richtig. Ich habe schon einiges über das Für und Wieder von Multisites gelesen und mich damit auseinander gesetzt, ob Multi oder nicht-Multi sinnvoller ist. Also bei mir ist folgendes:

• Shared Hoster mit limitiertem Platz. Ich will daher, wenn es geht, den nicht an eine mehrfache Installation verschenken.
• Module: Können für alle Seiten identisch sein, sollen sie sogar auch, wenn möglich.
• Themes: Sollen natürlich je nach Seite verschieden sein, unterscheiden sich aber nicht sehr stark (hier mal eine Zusatzgrafik im Header eingeblendet, da mal ein list-style-image: url('nerd.gif');, etc.).
• Update: Ist bei der geringen Anzahl zwar nicht entscheidend, ich habe aber vor, den Softwarestand wenn möglich immer auf dem gleichen, aktuellen Stand zu halten. Den core und die Module zu aktualisieren und dann für jede Site das update-Skript anzuschmeißen klingt mir doch recht sauber. Ob ich für die angedachten dev-Versionen ein separates Drupal aufsetze, um das Update vorher auf Nebeneffekte zu prüfen, oder ob ich das erst lokal prüfe, ist noch nicht ausdiskutiert. Und als Programmierer ist git natürlich ein alter Bekannter, das ist auch noch eine Option, wenn irgendwas schief ruf ich halt einen alten Stand ab und gut iss.

Mit Themes muss ich mich mal separat befassen. Aber alles der Reihe nach, erst mal muss Drupal selber an den Start und der alte Content herübergezogen werden.

VG

Don

Ja, auf jeden Fall. Von Anfang an alles mit Composer.
Auf https://getcomposer.org/ gibt es Download und Anleitung.
Zu den Shared Hosting: Ich würde da lieber einen Virtual Server vorziehen, bei shared Hosting hast du halt immer das Risiko daß die Resourcen zu wenig sind. Und volle Root Kontrolle ist nicht zu verachten. Darf ich fragen was für ein Hoster und Paket das wäre? Zum Vergleich: Ich habe einen VPS bei 1blu mit 8 Cores, 24 GB Ram und 600 GB SSD für 12,90 pro Monat.

Ja klar darfst du das! Der Shared Hoster ist manitu, das Paket ist das "'M". Das ist zwar nicht der billigste, aber bekanntlich, wer billig kauft, kauft zweimal. Ich habe im Vorfeld verschiedene Hoster kontaktiert, all-inkl z. B. bietet für Shared Hosting kein IPV6 an, das wird aber erst auf Nachfrage hin rausgerückt. Ich halte so etwas für ein KO-Kriterium für die heutige Zeit, Fremdschäm! Viele Shared Hoster bieten auch Pakete an, bei denen der Space in den kleinen Paketen äußerst knapp bemessen ist. Hauptsache billig halt, und wenn der Kunde das später realisiert ist die Hemmschwelle nochmal den Hoster zu wechseln für viele zu groß. Da wird dann halt zwangsweise ein größeres, teureres Paket genommen und fertig.

Ein vServer hat Vor- und Nachteile. Ein root-Zugriff ist natürlich nett, agree. Aber man ist nicht nur für die Aktualität der Website und des CMS verantwortlich, sondern für den ganzen Server, Apache, php, usw. Mit apt unattended-upgrades (man merkt, ich bin ein Freund von debian und Forks davon) lässt sich zwar vieles automatisieren, aber ein regelmäßiges Auge drauf behalten muss man trotzdem. Ein vServer ist auch deutlich teurer als ein Shared Space und man sollte sich überlegen, ob man nicht mit den sprichwörtlichen Kanonen auf Spatzen schießt.

manitu hat mir auch auf Nachfrage zwar nicht mitteilen wollen, auf welcher physikalischen Hardware das läuft und wie viele Spaces sich einen Server teilen müssen (kann ich verstehen, aber fragen kostet nichts). Aber der Server scheint die aufgebürdete Last ganz gut handhaben zu können und ist bisher nicht unerträglich langsam. Auch das kann bei einem Billig-Will-Ich-Angebot schnell anders sein, ein anderer Aspekt zusätzlich zum zu knappen Webspace. Und später von einem Shared- zu einem vServer-Angebot zu wechseln, wenn ersteres mal nicht mehr ausreicht, sollte kein Problem sein, wer weigert sich schon mehr Geld einzunehmen? Hab ich tatsächlich zwar auch schon erlebt (Facepalm!), aber das ist die absolute Ausnahme und im dem Fall kündige ich halt und wechsle, die Frist beträgt ja nur einen Monat, kein Problem. Und Drupal von a nach b zu wechseln sollte auch schnell erledigt sein, die Einarbeitungphase hat man ja nur einmal.

VG

Don

Das klingt natürlich auch alles plausibel, später wechseln sollte ja auf jeden Fall problemlos klappen. Wichtig ist ja erstmal der SSH Zugang, zur Not würde es aber auch gehen die Seite lokal mit Composer zu entwickeln und dann einfach mit FTP hochzuladen.
Klappt es den ansonsten mit dem Composer?

Danke der Nachfrage! Ja, SSH-Zugang ist eingerichtet (ich vermisse den mc den ich auf meinen anderen Systemen habe, bin halt ein Freund von OFM), Composer habe ich installiert und testweise eine Drupal-Installation der Multisite abgeschlossen. Ich habe dann festgestellt, dass die MariaDB Version die der Hoster zur Verfügung stellt für Drupal 9.3 nicht ausreicht. Wieder ein Argument pro vServer. Mit MySQL ging es dann, die Version war hoch genug. Es erschien zwar ein Hinweis, dass MySQL nur ausnahmsweise genutzt werden soll und man bitte MariaDB nehmen solle, aber was soll ich tun? Alternativ wird noch Postgre angeboten, habe ich noch nicht ausprobiert. Hast du Erfahrung mit der Performance der verschiedenen DBs?

Vielleicht installiere ich Drupal doch nicht als Multisite, sondern für jede Website separat, nochmal überlegen und die Vor- und Nachteile abwägen. Noch kann ich das ja ohne großen Aufwand ändern.

Hallo Don Pedro,

ich kann mich Sammelzwerg nur anschließen. Composer ist Pflicht, und zwar bereits ab der initialen Installation des Drupal Core.

Zum Thema vServer: Es gibt auch vServer, die vom Hoster gemanagt werden. Das erspart jede Menge Stress :-)

Zum Thema Multisite generell: Wenn Deine Websites alle mit den gleichen Modulen arbeiten und vielleicht auch dasselbe Basis-Theme haben, spricht das für eine Multisite-Installation. Der langfristige technische Pflegeaufwand ist bei Drupal nicht zu unterschätzen. Mit einer Multisite-Lösung könntest du künftige Updates für alle Websites in einem Aufwasch einspielen.

Ich würde dir auch empfehlen, lokal zu entwickeln und dein Deployment auf den Live-Server mittels Versionsverwaltung (git) zu bewerkstelligen. Mein Workflow sieht so aus, dass ich eine lokale dev-Umgebung habe, die ich per git zunächst auf eine stage-Umgebung (Live-Server) deploye, dort nochmal teste und erst danach den master-Branch auf die Live-Site deploye. Dabei deploye ich (neben custom Modulen und custom Themes) nur die composer.json und die composer.lock. Auf dem Live-Server lasse ich bei Updates nur noch den Befehl composer install ausführen, damit übernimmt Composer dann alle Updates und die Updates der Abhängigkeiten 1:1 wie in meiner lokalen Umgebung. Damit es hier nicht zu Fehlermeldungen kommt, muss die PHP-Version in beiden Umgebungen identisch sein, auch auf cli-Ebene.

Gruß
Christian

Zu den Multisites habe ich hier https://www.1xinternet.de/de/blog/multisite-vs-mehrere-websites eine Übersicht mit Vor- und Nachteilen gefunden, vielleicht hilfreich zur Entscheidungsfindung.

Zu den verschiedenen Datenbanken kann ich nichts sagen, ich verwende immer MySQL und habe die anderen nie ausprobiert. Die Geschwindigkeit war bisher immer mehr als ausreichend. Woher kam denn der Hinweis, MariaDB zu nehmen? Ist das ein Rat vom Hoster? Von Drupal her ist mir das noch nie aufgefallen, vielleicht habe ich es aber auch übersehen.

MariaDB ist vom selben Entwickler wie Mysql und für mich sind die beiden austauschbar. In manchen Unix Distributionen wird MariaDB der Vorzug gegeben, da neuer. Es hängt also auch vom Provider ab, welche Datenbank-Engine zur Verfügung steht.
Ich bin im Übrigen von Multisites weggegangen und bevorzuge Einzelinstallationen. Wenn man einmal eine einzelne Installation aus so einem System herausnehmen will, schleppt man zu viel von der Multisite Struktur mit.

Frohes Neues erst mal allerseits!

Aktuell kein Prob, da die Seite noch nicht aufgesetzt ist. Ich kann das per SFTP draufgezogene Zeug ja nochmal löschen und nackt neu anfangen.

Danke für den Hinweis, ist ggf. ein nützlicher Kompromiss!

So in etwa hatte ich das gedacht, ja. Ich höre raus, du hast bereist ein wenig Erfahrung mit Multisites? Kannst du was zum Default-Verzeichnis sagen? Muss die erste Site da hinterlegt sein?

Dass dein Branch noch "master" und nicht "main" heißt, zeugt ja davon, dass du git schon eine Weile nutzt :-)
Erst wenn man drüber nachdenkt, an wie vielen Stellen wo man es gar nicht auf Anhieb erwartet irgendein rassistischer Dünnpfiff immer noch sein Unwesen treibt, wird einem dass bewusst. Ob es heißt "Zigeunersauce", "master" oder Schaumküsse früher mal das N-Wort beinhalteten.
Aber, back to the records. eine lokale Testumgebung mit git im Hintergrund hatte ich auch vor, ein Linux-System was ansonsten den Videorekorder spielt und minidlna betreibt, sollte das locker auch noch wuppen. Letztlich das Non-Plus-Ultra. Ob auf dem Server eine Staging-Umgebung existieren soll, ist noch nicht ganz sicher, letztlich ist es immer noch eine private Homepage und man kann auch Overkill betreiben.

VG

Don

Ich habe jetzt nochmal neu angefangen, komme aber mit den Verzeichnissen des Installers und der Multisite nicht ganz zurecht :-/

Mein Setup sieht so aus, ich hoffe das ist halbwegs verständlich:
/web -> da soll alles drin liegen, was irgendwie mit dem Webservice zu tun hat. Das ist vom Hoster so vorgegeben und ist ja auch kein Problem. Wie das Webroot heißt ist ja Schall und Rauch.
/web/site1, /web/site2, /web/site3 -> Da sind die einzelnen Webseiten vom Hoster vorgesehen, das kann ich aber per VHost ändern wo die registrierten Domains drauf zeigen sollen, kein Problem.
/web/drupal -> Das Verzeichnis habe ich für drupal vorgesehen und da habe ich auch Composer drin installieren lassen.

Nun ist lt. Doku ein composer create-project drupal/recommended-project my_site_name_dir angesagt, ich führe das also mit my_site_name_dir -> site1 aus. Mir wird dann eine Struktur wie folgt erstellt:

• Das ist aber zum einen nicht was ich will. "site1" sollte eigentlich an dieser Stelle des Pfades ganz verschwinden, weil das verwirrt. "site1" muss der Teil aber heißen, weil die Default-Website auf diesen Namen lauten soll? Sie soll auf jeden Fall nicht "default" oder "drupal" heißen!
• Die Doku sagt:
  "Your 'my_site_name_dir' will contain files that should be outside of your web root and not accessible by the web server. The web root will be 'my_site_name_dir/web'."
  Ich müsste damit also für dir erste Site /web/drupal/site1/web als VHost setzen.
• Zum anderen setzt das noch kein Multisite. Das muss ich dann von Hand machen?
• Aber wie sieht das dann aus? Wenn ich site1, site2, usw. als Domains haben möchte, kann ich ja nicht /web/drupal/site1/web als VHost für alle setzen, müsste das aber lt. Doku tun.
• Und was muss ich im Browser aufrufen, damit die anderen Sites initial aufgesetzt werden?
• Wenn ich vom Multisite mal weggehe, könnte ich natürlich ein
  
  composer create-project drupal/recommended-project site1
composer create-project drupal/recommended-project site2
composer create-project drupal/recommended-project site3
...
  
  aufrufen, das würde dann gehen.

Oder steh ich jetzt total auf dem Schlauch und hab irgendwas gar nicht geblickt? Ist mit auch schon passiert - Facepalm :-o

VG

Don

Du stehst auf dem Schlauch :-)
composer create-project drupal/recommended-project my_site_name_dir. Das ist die oberste Ebene aller Multisite-Installationen und oberhalb der eigentlichen Drupal-Installation. Die liegt nämlich in my_site_name_dir/web (das hat jetzt mit web von Deinem Provider nicht zu tun).
In web liegt sites und das besagt, das es dort auch mehr als eine (= default) geben kann. Dazu kopierst Du das default-Verzeichnis in Deine Domain um (z.b. heißt dann das neue Verzeichnis in sites my_domain.de) etc. Der Einstiegspunkt für jede Domain (= DocumentRoot) ist dann my_site_name_dir/web. Welches Verzeichnis genutzt wird, ist dann über den Domain-Namen festgelegt. Wenn der passende Domainname nicht als Verzeichnis gefunden wird, wird default genommen. Darin befinden sich die settings.php (d.h. die Info über die Datenbanksnbindung) für die Seite und das files-Verzeichnis zu dieser Domain. Die Installation geht dann über den Aufruf der Domain im Browser.

Ich würde über das Unternehmen Multisite noch einmal gründlich nachdenken. Du sparst zwar etwas Plattenkapazität, aber das ist in meinen Augen den möglichen Ärger nicht wert. Wenn Du eine einzelne Domain später herauslösen möchtest klebst Du Immer an der Struktur web/sites/domain. Das liegt an den Pfaden zu den in files liegenden Dateien in der Datenbank und ist nicht "mal eben" geändert.

Ja, das glaube ich mittlerweile auch :-)

Also ich schreibe dann mal das Vorgehen für meinen Fall in Form eines Kochrezeptes auf, so wie ich es nun verstanden habe:

• Löschen der bisherigen Installation/Files.
• Fall 1, Multisite:
• Installation von Composer nach /web (mein /web, nicht das von Drupal, ggf. kann das natürlich auch anders heißen). Also das übergeordnete Verzeichnis zur Installation von Drupal.
• composer create-project drupal/recommended-project drupal ausführen. Es wird dann einmal Drupal im Verzeichnis /web/drupal mit entsprechenden Unterverzeichnissen installiert.
• Installation von Modulen via Composer. Die landen im Ordner /web/drupal/modules. Analog für Themes.
• Anlegen der Ordner site1, site2, usw. parallel zu default
• Kopieren des Ordners default in alle oben angelegten Ordner.
• Setzen aller(!?) VHost auf /web/drupal/web? Ich weiß nicht, ob das Setzen aller VHost auf ein Verzeichnis zugelassen wird! /web/drupal/web/site1, /web/drupal/web/site2, usw. fände ich auch "schöner".
• Aufruf von https://default, https://site1, usw. und Installation der jeweiligen Site in Drupal.
• Bzw. einige Domains sind noch nicht transferiert, https://site1 ist also nicht aufrufbar, sondern derzeit nur unter https://hier/eine/lange/url/site1 zugänglich. Ich würde daher in sites.php entsprechende Aliases aufsetzen (müssen). Das ist ja auch wichtig für die korrekten URLs in der DB, siehe dein Kommentar unten. In sites.php der jeweiligen Site müsste also folgendes stehen:
  $sites['site1'] = 'site1'; // Nicht klar ob das nötig ist, Alias auf sich selbst ist unlogisch!
$sites['site1.url.lange.eine.hier'] = 'site1';
  
  Und wenn eine Staging-Site noch dazu kommt:
  $sites['stage.site1.url.lange.eine.hier'] = 'stage/site1';
  
  Analog für site2, usw. Richtig so?
• Fall 2, mehrmals Singlesite:
• Installation von Composer nach /web (mein /web, nicht das von Drupal, ggf. kann das natürlich auch anders heißen). Also das übergeordnete Verzeichnis zur Installation von Drupal.
• composer create-project drupal/recommended-project site1, composer create-project drupal/recommended-project site2, usw. ausführen. Es wird dann jeweils Drupal im Verzeichnis /web/site1, /web/site1, usw. mit entsprechenden Unterverzeichnissen installiert.
• Installation von Modulen via Composer. Die landen im Ordner /web/site1/modules, /web/site2/modules, usw. Analog für Themes.
• Setzen der VHost auf /web/site1/web, /web/site2/web, usw.
• Aufruf von https://site1, https://site2, usw. und Installation der jeweiligen Site in Drupal
• Bzw. einige Domains sind noch nicht transferiert, https://site1 ist also nicht aufrufbar, sondern derzeit nur unter https://hier/eine/lange/url/site1 zugänglich. Ich würde daher in sites.php entsprechende Aliases aufsetzen (müssen). Das ist ja auch wichtig für die korrekten URLs in der DB, siehe dein Kommentar unten. In sites.php der jeweiligen Site müsste also folgendes stehen:
  $sites['site1'] = 'site1'; // Nicht klar ob das nötig ist, Alias auf sich selbst ist unlogisch!
$sites['site1.url.lange.eine.hier'] = 'site1';
  
  Und wenn eine Staging-Site noch dazu kommt:
  $sites['stage.site1.url.lange.eine.hier'] = 'stage/site1';
  
  Analog für site2, usw. Richtig so?

Ich weiß was du meinst! Das Editieren von ein paar ini-Dateien kriegt noch ein relativ Unversierter hin. Das Ersetzen von Werten in einer SQL-DB hingegen eher nicht. Ein

VG

Don

Ja, das glaube ich mittlerweile auch :-)

Also ich schreibe dann mal das Vorgehen für meinen Fall in Form eines Kochrezeptes auf, so wie ich es nun verstanden habe:

• Löschen der bisherigen Installation/Files.
• Fall 1, Multisite:
• Installation von Composer nach /web (mein /web, nicht das von Drupal, ggf. kann das natürlich auch anders heißen). Also das übergeordnete Verzeichnis zur Installation von Drupal.
• composer create-project drupal/recommended-project drupal ausführen. Es wird dann einmal Drupal im Verzeichnis /web/drupal mit entsprechenden Unterverzeichnissen installiert.
• Installation von Modulen via Composer. Die landen im Ordner /web/drupal/modules. Analog für Themes.
• Anlegen der Ordner site1, site2, usw. parallel zu default
• Kopieren des Ordners default in alle oben angelegten Ordner.
• Setzen aller(!?) VHost auf /web/drupal/web? Ich weiß nicht, ob das Setzen aller VHost auf ein Verzeichnis zugelassen wird! /web/drupal/web/site1, /web/drupal/web/site2, usw. fände ich auch "schöner".
• Aufruf von https://default, https://site1, usw. und Installation der jeweiligen Site in Drupal.
• Bzw. einige Domains sind noch nicht transferiert, https://site1 ist also nicht aufrufbar, sondern derzeit nur unter https://hier/eine/lange/url/site1 zugänglich. Ich würde daher in sites.php entsprechende Aliases aufsetzen (müssen). Das ist ja auch wichtig für die korrekten URLs in der DB, siehe dein Kommentar unten. In sites.php der jeweiligen Site müsste also folgendes stehen:
  $sites['site1'] = 'site1'; // Nicht klar ob das nötig ist, Alias auf sich selbst ist unlogisch!
$sites['site1.url.lange.eine.hier'] = 'site1';
  
  Und wenn eine Staging-Site noch dazu kommt:
  $sites['stage.site1.url.lange.eine.hier'] = 'stage/site1';
  
  Analog für site2, usw. Richtig so?
• Fall 2, mehrmals Singlesite:
• Installation von Composer nach /web (mein /web, nicht das von Drupal, ggf. kann das natürlich auch anders heißen). Also das übergeordnete Verzeichnis zur Installation von Drupal.
• composer create-project drupal/recommended-project site1, composer create-project drupal/recommended-project site2, usw. ausführen. Es wird dann jeweils Drupal im Verzeichnis /web/site1, /web/site1, usw. mit entsprechenden Unterverzeichnissen installiert.
• Installation von Modulen via Composer. Die landen im Ordner /web/site1/modules, /web/site2/modules, usw. Analog für Themes.
• Setzen der VHost auf /web/site1/web, /web/site2/web, usw.
• Aufruf von https://site1, https://site2, usw. und Installation der jeweiligen Site in Drupal
• Bzw. einige Domains sind noch nicht transferiert, https://site1 ist also nicht aufrufbar, sondern derzeit nur unter https://hier/eine/lange/url/site1 zugänglich. Ich würde daher in sites.php entsprechende Aliases aufsetzen (müssen). Das ist ja auch wichtig für die korrekten URLs in der DB, siehe dein Kommentar unten. In sites.php der jeweiligen Site müsste also folgendes stehen:
  $sites['site1'] = 'site1'; // Nicht klar ob das nötig ist, Alias auf sich selbst ist unlogisch!
$sites['site1.url.lange.eine.hier'] = 'site1';
  
  Und wenn eine Staging-Site noch dazu kommt:
  $sites['stage.site1.url.lange.eine.hier'] = 'stage/site1';
  
  Analog für site2, usw. Richtig so?

Ich weiß was du meinst! Das Editieren von ein paar ini-Dateien kriegt noch ein relativ Unversierter hin. Das Ersetzen von Werten in einer SQL-DB hingegen eher nicht. Ein

VG

Don

Vorsicht, dem composer sind die Multisites völlig egal. Der installiert eben Module nach web/modules/contrib/, Themes entsprechend nach web/themes/...
Du siehst daran auch, daß die Unterstützung für die Multisite nicht mehr so ist wie noch zu Zeiten von Drupal 7.
Der Einstiegspunkt liegt wie damals im Verzeichnis der gemeinsamen Drupal-Installation. Dort wird die index.php ausgeführt, die die weiteren Abläufe regelt.
Dem Apache sollte es eigentlich egal sein, wenn mehrere Vhosts dasselbe DocumentRoot Verzeichnis benutzen.
Die Multiste Installation funktioniert eben nur wie oben beschrieben. Du duplizierst das default-Verzeichnis in web/sites, nennst die Kopie wie Deine Domain und startest die Installation im Browser.

Kleine Korrektur?
Wenn ich das richtig habe: Composer weiß nicht nur von Multisites nichts, sondern auch nichts über Drupal. Ist halt eine php-Anwedndung und liest aus irgendeiner Datei im Paket was es wie tun soll, so wie irgendein anderer Paketmanger auch. Von daher liegt die "Schuld" weniger bei Composer, sondern bei Drupal. Sprich das muss nicht so bleiben, sondern könnte auch verbessert werden.

Ich versuch mich mal an einer "konventionellen" Installation.

VG

Don

Ich mache das immer so: Ich navigiere zu dem Ordner, wo der Composer sitzen soll, bei mir ist das /var/www/html/NAME DER SEITE.
Darin dann composer create-project drupal/recommended-project ./, das legt dort unter anderem composer.json, composer lock und das Unterverzeichnis web an, in dem dann alle Drupal Dateien enthalten sind, /var/www/html/NAME DER SEITE/web ist dann auch der Webroot für Apache in /etc/apache2/sites-available.
Dasselbe dann für weitere Seiten. So sind die alle unabhängig, können getrennt gesichert (wird per Cronjob erledigt) und wenn nötig wiederhergestellt werden. Und jede Seite bekommt natürlich ihre eigene Datenbank.

Das habe ich zwar nicht exakt so gemacht, aber ziemlich ähnlich! Das Ergebnis ist im Wesentlichen gleich. Das funktioniert auch auf Anhieb mit der Domain die bereits registriert ist. Benutze ich jedoch die lange URL (bei den noch nicht registrierten Domains habe ja ich noch keine andere Wahl), dann kommt immer ein 403. Offenbar verhaut er sich noch beim Pfad. Als VHost habe ich angelegt /web/site1/web/ und in sites.php steht drin
$sites['hier.eine.lange.url.site1'] = 'site1';

Hänge ich testweise an die URL noch ein /web an, so kommt ein Fehlermeldung The provided host name is not valid for this server. Was ist hier noch falsch? Muss in $sites[...] noch ein .web angehängt werden?

VG

Don

Das kommt vielleicht von der Funktion Trusted Host Patterns, das soll verhindern daß Scripte mit gefälschten Absenderadressen ausgeführt werden können. Da musst du in der settings.php einen entsprechenden Eintrag machen.
Hier der Abschnitt, wo es erklärt wird:

Die sites.php brauchst du glaub ich gar nicht, die ist nur für Multisites und wenn ich das richtig verstanden habe ist es ja jetzt keine. Ich habe da jedenfalls noch nie etwas eingetragen, bzw die noch gar nie angelegt.

Danke. Ja, das war es tatsächlich! Ich hatte - weil das ja sinnvollerweise auch im Statusreport genannt wird - in Trusted Host Patterns schon site1 usw. rein geschrieben, aber nicht richtig bzgl. der zweiten Adressen gedacht. Und die lauten halt nicht https://hier.eine.lange.url . site1, sondern https://hier.eine.lange.url / site1! Und damit ist eine separate regex nötig, damit das klappt. Ich muss zwar noch ein extra /web an die URL anhängen, das macht bei einer nur zur Wartung genutzten Adresse aber nichts.

Auch die Bretter vor dem eigenen Kopf können die Welt bedeuten, Facepalm...

Korrekt, jetzt habe ich das nicht als Multisite aufgesetzt. Die sites.php habe ich wg. der langen Domainnamen geändert, die lauten ja https://hier.eine.lange.url/site1/web. Aber das kann ich natürlich nicht in der DB gebrauchen, sondern da soll stehen https://site1. Und wenn ich das richtig verstanden habe, kann eine passende Angabe in sites.php ja genau das machen, eine Site wird unter zwei verschiedenen URLs zur Verfügung gestellt, in der DB steht aber das "richtige". Ich hoffe das stimmt so und ich bekomme saubere Einträge in der DB. Ich guckt mir nach der Einrichtung von Drupal mal die DB an, bevor ich jede Menge Inhalt ablade, den Fehler erst viel zu spät merke und dann das "fröhliche" Löschen anfange.

VG

Don

Wenn deine Seite von 2 verschiedenen URLs aufgerufen werden soll, kannst du in der NAME_DER_SEITE.conf in /etc/apache2/sites-available einfach einen alias anlegen:

Wenn du stattdessen willst, daß in der Adresszeile immer site1 steht, kannst du eine hier.eine.lange.url.com.conf anlegen, mit einem redirect:

oder einen extra Ordner für die lange URL mit nur einer .htaccess drin mit
Redirect 301 / https://www.site1.com/

Mit Einträgen in der DB hat das nichts zu tun, und "fröhliches Löschen" würde ich nicht empfehlen, das führt sonst recht leicht zum "fröhlichen Backup einspielen", falls hoffentlich vorhanden. :-)

Gute Idee, aber Shared Hoster => auf /etc habe ich keinen Zugriff (zumindest nicht schreibend)!

Aber irgendwas stimmt noch nicht. Wenn Editiere und z. B. von "bearbeiten" auf "Ansicht" gehe, wird immer die URL geschrottet. Statt https://site1/impressum bekomme ich https://site1/site1/web/impressum. Rufe ich die richtige URL auf, wird alles wie beabsichtigt angezeigt, aber die Links sind kaputt. :-/

Achso, dann mit .htaccess, hab ich gerade oben noch angefügt

Das kann normal nur von den Einträgen in der sites.php kommen, oder möglicherweise ist das php Modul mod_rewrite nicht aktiviert. Das sollte aber eigentlich nicht sein.

Falls du das meinst:

dann ist das derzeit noch nicht zielführend. Ich muss die URLs nutzen, weil die Domains noch nicht umgezogen sind. Ich möchte aber natürlich, dass die ganzen Links, etc. passen. Nach dem Transfer sind mir die langen Adressen relativ egal, vorher möchte ich aber die neue Heimat mit Inhalt beladen.

VG

Don

Falls du das meinst:

dann ist das derzeit noch nicht zielführend. Ich muss die URLs nutzen, weil die Domains noch nicht umgezogen sind. Ich möchte aber natürlich, dass die ganzen Links, etc. passen. Nach dem Transfer sind mir die langen Adressen relativ egal, vorher möchte ich aber die neue Heimat mit Inhalt beladen.

VG

Don

Jetzt mal zum Verständnis, wieviele verschiedene Seiten sollen es werden, und wieviele URLS sollen da jeweils draufzeigen? Und kannst du da verschiedene Seiten in dem einen Webspace anlegen, oder sind das dann mehrere davon?

Sorry für die Verwirrung, tut mir leid!

Also:

• Es werden insgesamt drei Sites.
• Eine davon ist neu, da habe ich schon eine registriert Domain.
• Zwei davon sollen umgezogen werden. Da habe ich auch jeweils eine Domain für, die zeigen aber natürlich noch auf den alte Hoster. Das soll auch so bleiben, bis die Seiten beim neuen Hoster befüllt sind.
• Für alle Sites habe ich zusätzlich vom neuen Hoster eine interne Adresse bekommen, damit ich die Seiten auch bei noch nicht transferiertem Namen mit Inhalt befüllen kann. Das ist ein Behelf, der nach dem Umzug natürlich keine Rolle mehr spielt.
• Die zwei Seiten mit noch ausstehenden Transfer müssen derzeit über diese "Behelfsadresse" beladen werden, da die spätere, öffentliche Adresse noch zum alten Hoster zeigt.
• Egal ob mit oder ohne umgezogenen Namen und egal über welche der beiden Adressen das CMS aufgerufen wurde, die Links innerhalb der Site müssen natürlich alle stimmen.
• Ich habe einen Webspace gekauft, der alle drei Seiten aufnehmen kann und soll. Intern unterschieden werden die über den VHost. Damit kann ich für jede Domain einen individuellen root setzen, der als Wurzel für www.site1.de usw. dient. Den Folder der jeweils genutzt werden soll, kann ich einstellen.

So, ich hoffe jetzt ist das klarer.

VG

Don

Ok, also hast du vom Hoster das Verzeichnis .../web, richtig?
Da drin legst du für jede Seite einen Ordner an, der kann beliebig heißen, nehmen wir mal Site1 als Beispiel.
Habe ich das richtig verstanden, daß der Composer, also das Programm Composer, jeweils für das Verzeichnis installiert wird? Bei mir ist der global in /usr/local/bin, aber das geht vielleicht bei dir nicht.
Falls also lokal, dann in jedes Verzeichnis einen Composer, dann jeweils composer create-project drupal/recommended-project ./ und den Webroot auf .../web/Site1/web zeigen lassen.
Wenn dann die Seiten mit der richtigen Adresse freigeschaltet werden sollen, einfach den Vhost auf dasselbe Verzeichnis zeigen lassen, das macht intern für Drupal überhaupt keinen Unterschied.

Ok, also hast du vom Hoster das Verzeichnis .../web, richtig?
Da drin legst du für jede Seite einen Ordner an, der kann beliebig heißen, nehmen wir mal Site1 als Beispiel.
Habe ich das richtig verstanden, daß der Composer, also das Programm Composer, jeweils für das Verzeichnis installiert wird? Bei mir ist der global in /usr/local/bin, aber das geht vielleicht bei dir nicht.
Falls also lokal, dann in jedes Verzeichnis einen Composer, dann jeweils composer create-project drupal/recommended-project ./ und den Webroot auf .../web/Site1/web zeigen lassen.
Wenn dann die Seiten mit der richtigen Adresse freigeschaltet werden sollen, einfach den Vhost auf dasselbe Verzeichnis zeigen lassen, das macht intern für Drupal überhaupt keinen Unterschied.

Ja! Ich kann auch das ändern, aber lassen wir das mal Beiseite und nehmen den Default "/web".

Ja, so habe ich das schon getan!

Nein, den habe ich global für alle Sites installiert. Hierzu bin ich per SSH in das anfangs genannte Verzeichnis /web gewechselt und habe dort Composer mit dem php-Skript auf Command-line installation installiert.

Habe noch nicht ausprobiert, würde mich aber wundern wenn ich dort irgendwas hinschieben könnte! Aber dann liegt Composer halt ein Verzeichnis oberhalb der Webseiten.

Ich habe halt aus /web composer create-project drupal/recommended-project site1 aufgerufen, das Ergebnis sollte identisch sein. Jedenfalls wird dann in /web/Site1 die Seite erstellt und den VHost habe ich auf /web/Site1/web zeigen lassen. Das passt ja auch alles, www.site1.de im Browser ruft den Drupal-Installer auf und ich kann danach die neue Seite sehen und mich einloggen.

• Die Seiten liegen auch genau da wo sie sollen, sowohl im Dateisystem auf dem Webserver, wie auch im www.
• Wenn ich aber in der Seite auf einen Link klicke, zeigt der nicht auf https://www.site1.de/unterseite, sondern auf https://www.site1.de/www.site1.de/web/unterseite und da findet er natürlich nichts (das doppelte "www.site1.de" ist kein Schreibfehler!)
• Das passiert auch intern, wenn ich in Drupal z. B. auf einen Editlink klicke.
• Ich kann das korrigieren, wenn ich in der URL in der Adressleiste das Lösche was zu viel ist. Die Seite die er eigentlich ansteuert sollte existiert also genau da, wo sie sein sollte. Aber die Korrektur bei jedem Klick zu machen ist unendlich mühsam!

Soll ich mal sites.php löschen und schauen, was sich ändert?

VG

Don

Ja, oder erstmal umbenennen, z.B old.sites.php oder so

Hab ich gemacht, ändern tut sich allerdings nichts, die Links sind immer noch unsinnig :-/

Ich würde mal die Datenbank einer der Websiten leeren und den Installer neu starten. Vielleicht ändert das was.

VG

Don

Hast du schon die Caches geleert?

Nein! Stimmt, das könnte ich mal machen! Ich werde berichten...

VG

Don

Sorry dass es so lange gedauert hat! Ich war ein wenig beschäftigt.

Die Antwort lautet: Leider nein, das Leeren der Caches hat keine Änderung gebracht, es sind immer noch die kaputten Verlinkungen hinterlegt! :-/

Noch was ausprobieren, bevor ich aus Verzweiflung die Tabellen lösche?

VG

Don

Ich wüsste da jetzt sonst nichts, wenn da eh noch kein relevanter Inhalt drin ist wirds wohl das einfachste sein.