Startseite
  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche
Startseite › Forum › Drupalcenter.de › Anfängerfragen ›

Fragen zum Aufsetzen von neuen Multisites

Eingetragen von Don Pedro (19)
am 29.12.2021 - 17:31 Uhr in
  • Anfängerfragen
  • Drupal 9.x

Hi zusammen!

Erstmal zu mir:

  • Ich habe mich grade erst im Forum angemeldet und dies ist mein erster Post. Daher, wenn ich noch etwas falsch machen sollte, bitte Rücksicht, Entschuldigung, Korrektur!
  • Ich bin seit Ewigkeiten in der IT als Programmierer tätig. Von html, CSS, bash, Linux, LAMP, usw. habe ich also schon ein wenig Ahnung, auch wenn zu meinen Jobs bisher nicht das Erstellen von Webseiten gehört hat. Aber vor Tech-Speak habe ich keine Angst.

Worum geht's?

  • Ich habe zwei private Webseiten bei einem Hoster, den ich wechseln will, erstellt mit einem CMS, dass ich auch wechseln will (ein Aufwasch, wenn schon, denn schon). Der Transfer des Inhalts soll per C&P geschehen, hier nicht Diskussionsgegenstand.
  • Ich habe Webspace bei einen Shared Hoster verfügbar, die Domains sind allerdings noch nicht transferiert. Die sollen erst mal weiter auf die alte Site zeigen, bis die neuen fertig sind. Akuter Druck ist also nicht da.
  • Ich habe zusätzlich eine weitere, dritte Domain registriert, die in diesem Zug neu erstellt werden soll. Später kommt evtl. noch eine weitere hinzu, daher der Ansatz unten.
  • Ich habe mir verschiedene CMS angeschaut und bin bei Drupal hängen geblieben.
  • Für das Vorgehen habe ich angedacht, das Ganze als Drupal Multisite, Multilanguage unter dem aktuellen Drupal 9 aufzusetzen. Als Anfänger gleich eine Multisite aufzusetzen hört sich nun ein wenig sportlich an, aber ich denke besser gleich richtig, statt erst mal halbherzig gefolgt von Bastelei. Außerdem scheint mir das nicht prohibitiv komplex zu sein (kann sein, dass ich naiv bin :-) )
  • Zum "gleich richtig machen" gehört auch, dass ich plane auf dem Webspace eine Staging-Area für jede Webseite aufzusetzen und lokal auf meinem heimischen Rechner ein dev-System (als LAMP).
  • Der Hoster bietet Drupal nur in einer veralteten 8er Version zur 1-Click-Installation an, das habe ich gleich mal ausgelassen und stattdessen das aktuelle 9er per SFTP draufgeschoben.

Jetzt meine Fragen:

  • Die Erstinstallation via SFTP ist OK und macht den Umstieg auf Composer nicht unnötig kompliziert? Oder muss/sollte das auch schon via Composer erfolgen? Wie ist das dann zu tun? Der Webspace ist ja noch nackt. SSH-Zugriff wird angeboten, sollte also kein Problem sein.
  • Ich habe schon eine ganze Menge über ein Multisite gelesen, eine ganze Menge an Informationen zu Drupal scheint mir aber auf die Versionen vor 9 bezogen zu sein. Z. B. wie sieht die Directorystruktur aus? Gefunden habe ich natürlich das hier: Multisite Folder Structure, das scheint mir aber nicht mehr für 9 gültig zu sein, man lese sich diesen Thread durch: Webhoster Installation von D8 zu D9 Upgraden - Fragen....
  • Wenn ich das Forum richtig verstehe, gilt die bisherige Directorystruktur /drupal/sites/default usw. nicht mehr? Wie sieht das dann aus? Es wird von "/web" gesprochen? Ich will natürlich nicht gleich zu Anfang Altlasten einbauen, sondern das korrekt aufbauen.
  • Meine derzeitige Struktur sieht so aus, dass ich Drupal selbst in einen Unterordner /web/drupal geschoben habe (ich mag keine zugemüllten Basefolders) und die Sites unter /web/drupal/sites/site1, site2, usw. angeordnet habe. Lieber würde ich aber die Drupal-Installation und den Ordner für die Webseiten aber ganz separat anordnen. Geht das (wie?) und ist das sinnvoll?
  • Bei den Installationsanleitungen ist immer wieder die Rede vom Ordner "sites/default", in der man die erste/primäre/whatsoever Webseite installieren müsse. Auch das gefällt mir nicht 100%, IMHO sollten alle Webseiten gleich aufgezogen sein und nicht eine anders sein. Muss es einen Ordner "Default" mit einer Website geben, oder ist das auch anders möglich? Zur Not würde ich eine Dummy-Site "Default" einrichten und meine eigentlichen Webseiten alle als sekundäre aufziehen. Macht das Sinn?
  • Die Verlagerung der Basisordners könnte geschehen, wenn ich in sites.php für das Array $sites absolute Pfade angeben könnte. Geht das? Die Dokumentation spricht jedoch dafür, das immer und unveränderlich in einem Unterordner von /drupal/sites gesucht wird.
  • Müssen/sollten die Sites mit Composer angelegt werden, oder kann eine frische Installation initial auch per SFTP erfolgen?
  • Die alte Heimat der Webseiten hat ein Scheet via CSS hinterlegt, das ich gerne mitnehmen möchte. Wenn ich das richtig habe muss dazu in Drupal 9 ein selbsgemachtes Theme installiert werden, was das CSS, Grafiken, etc. enthält. Ist das korrekt? Gibt es einen guten Link ala "Importieren eines bestehenden Scheets in ein Theme"? Mit den Standardthemes werde ich vmtl. nicht erreichen, was das alte Sheet erzielt hat, TDB, deswegen der Gedanke an ein selbst gebautes Theme für jede Website.

VG und Danke

Don

‹ Übersetzung im Drupal Version 8.9.9. funktioniert nur Abschnittsweise Fragen zum Aufsetzen von neuen Multisites ›
  • Anmelden oder Registrieren um Kommentare zu schreiben

Hallo und herzlich willkommen

Eingetragen von Sammelzwerg (350)
am 29.12.2021 - 19:22 Uhr

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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Hallo Sammelzwerg,danke für

Eingetragen von Don Pedro (19)
am 29.12.2021 - 20:53 Uhr

Hallo Sammelzwerg,

danke für eine sehr schnelle Antwort!

Sammelzwerg schrieb

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.

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.

Sammelzwerg schrieb

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.

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.
Sammelzwerg schrieb

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.

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Zitat:Das gilt auch für eine

Eingetragen von Sammelzwerg (350)
am 29.12.2021 - 21:14 Uhr
Zitat:

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, 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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Sammelzwerg schrieb Zu den

Eingetragen von Don Pedro (19)
am 30.12.2021 - 18:46 Uhr
Sammelzwerg schrieb

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Das klingt natürlich auch

Eingetragen von Sammelzwerg (350)
am 30.12.2021 - 21:52 Uhr

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?

  • Anmelden oder Registrieren um Kommentare zu schreiben

Sammelzwerg schriebDas

Eingetragen von Don Pedro (19)
am 31.12.2021 - 00:56 Uhr
Sammelzwerg schrieb

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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Ein paar Antworten

Eingetragen von schmittrich (119)
am 31.12.2021 - 11:30 Uhr

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Zu den Multisites habe ich

Eingetragen von Sammelzwerg (350)
am 31.12.2021 - 14:30 Uhr

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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

MariaDB ist vom selben

Eingetragen von wla (9210)
am 31.12.2021 - 20:07 Uhr

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.

.
Werner
drupal-training.de
Moderator und Drupal Trainer
* - - - - - - - - - - - - - - - - - - - - - - - - - - - *

  • Anmelden oder Registrieren um Kommentare zu schreiben

Frohes Neues erst mal

Eingetragen von Don Pedro (19)
am 01.01.2022 - 21:48 Uhr

Frohes Neues erst mal allerseits!

schmittrich schrieb

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

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.

schmittrich schrieb

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

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

schmittrich schrieb

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.

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?

schmittrich schrieb

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.

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Ich habe jetzt nochmal neu

Eingetragen von Don Pedro (19)
am 01.01.2022 - 23:13 Uhr

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:

/web/drupal/site1/vendor/...
/web/drupal/site1/web/sites/default

  • 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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Du stehst auf dem Schlauch

Eingetragen von wla (9210)
am 02.01.2022 - 01:45 Uhr

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.

.
Werner
drupal-training.de
Moderator und Drupal Trainer
* - - - - - - - - - - - - - - - - - - - - - - - - - - - *

  • Anmelden oder Registrieren um Kommentare zu schreiben

wla schrieb Du stehst auf dem

Eingetragen von Don Pedro (19)
am 02.01.2022 - 17:37 Uhr
wla schrieb

Du stehst auf dem Schlauch :-)

Ja, das glaube ich mittlerweile auch :-)

wla schrieb

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)...

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?
wla schrieb

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.

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

SELECT * INTO xxx_bak FROM xxx // Backup der Tabelle zur Sicherheit
SELECT * FROM xxx WHERE yyy LIKE '%Alter/Pfad%' // Zur Kontrolle ob auch nur die Datensätze ausgewählt wurden, die geändert werden sollen
UPDATE xxx SET yyy = 'Neuer/Pfad' WHERE yyy LIKE '%Alter/Pfad%' // Jetzt passierts!

und dann ggf. für mehre Tabellen ist da schon etwas anspruchsvoller. Und wehe man hat sich unglücklich vertippt, der SQL-Interpreter frisst das trotzdem und man hat kein Backup... :-)

VG

Don

  • Anmelden oder Registrieren um Kommentare zu schreiben

wla schrieb Du stehst auf dem

Eingetragen von Don Pedro (19)
am 02.01.2022 - 17:38 Uhr
wla schrieb

Du stehst auf dem Schlauch :-)

Ja, das glaube ich mittlerweile auch :-)

wla schrieb

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)...

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?
wla schrieb

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.

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

SELECT * INTO xxx_bak FROM xxx // Backup der Tabelle zur Sicherheit
SELECT * FROM xxx WHERE yyy LIKE '%Alter/Pfad%' // Zur Kontrolle ob auch nur die Datensätze ausgewählt wurden, die geändert werden sollen
UPDATE xxx SET yyy = 'Neuer/Pfad' WHERE yyy LIKE '%Alter/Pfad%' // Jetzt passierts!

und dann ggf. für mehre Tabellen ist da schon etwas anspruchsvoller. Und wehe man hat sich unglücklich vertippt, der SQL-Interpreter frisst das trotzdem und man hat kein Backup... :-)

VG

Don

  • Anmelden oder Registrieren um Kommentare zu schreiben

Vorsicht, dem composer sind

Eingetragen von wla (9210)
am 02.01.2022 - 19:56 Uhr

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.

.
Werner
drupal-training.de
Moderator und Drupal Trainer
* - - - - - - - - - - - - - - - - - - - - - - - - - - - *

  • Anmelden oder Registrieren um Kommentare zu schreiben

wla schrieb Vorsicht, dem

Eingetragen von Don Pedro (19)
am 02.01.2022 - 21:28 Uhr
wla schrieb

Vorsicht, dem composer sind die Multisites völlig egal. Der installiert eben Module nach web/modules/contrib/, Themes entsprechend nach web/themes/...

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.

wla schrieb

Du siehst daran auch, daß die Unterstützung für die Multisite nicht mehr so ist wie noch zu Zeiten von Drupal 7...

Ich versuch mich mal an einer "konventionellen" Installation.

VG

Don

  • Anmelden oder Registrieren um Kommentare zu schreiben

Ich mache das immer so: Ich

Eingetragen von Sammelzwerg (350)
am 02.01.2022 - 21:38 Uhr

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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Sammelzwerg schrieb Ich mache

Eingetragen von Don Pedro (19)
am 03.01.2022 - 00:57 Uhr
Sammelzwerg schrieb

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Don Pedro schrieb The

Eingetragen von Sammelzwerg (350)
am 03.01.2022 - 02:39 Uhr
Don Pedro schrieb

The provided host name is not valid for this server.

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:

/**
* Trusted host configuration.
*
* Drupal core can use the Symfony trusted host mechanism to prevent HTTP Host
* header spoofing.
*
* To enable the trusted host mechanism, you enable your allowable hosts
* in $settings['trusted_host_patterns']. This should be an array of regular
* expression patterns, without delimiters, representing the hosts you would
* like to allow.
*
* For example:
* @code
* $settings['trusted_host_patterns'] = [
*   '^www\.example\.com$',
* ];
* @endcode
* will allow the site to only run from www.example.com.
*
* If you are running multisite, or if you are running your site from
* different domain names (eg, you don't redirect http://www.example.com to
* http://example.com), you should specify all of the host patterns that are
* allowed by your site.
*
* For example:
* @code
* $settings['trusted_host_patterns'] = [
*   '^example\.com$',
*   '^.+\.example\.com$',
*   '^example\.org$',
*   '^.+\.example\.org$',
* ];
* @endcode
* will allow the site to run off of all variants of example.com and
* example.org, with all subdomains included.
*/

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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Sammelzwerg schriebDas kommt

Eingetragen von Don Pedro (19)
am 04.01.2022 - 21:56 Uhr
Sammelzwerg schrieb

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.

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...

Sammelzwerg schrieb

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.

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Wenn deine Seite von 2

Eingetragen von Sammelzwerg (350)
am 04.01.2022 - 22:49 Uhr

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:

ServerName www.site1.com
  
ServerAlias hier.eine.lange.url.com

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

ServerName hier.eine.lange.url.com

Redirect "/" "https://www.site1.com/"

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. :-)

  • Anmelden oder Registrieren um Kommentare zu schreiben

Sammelzwerg schriebWenn

Eingetragen von Don Pedro (19)
am 04.01.2022 - 22:53 Uhr
Sammelzwerg schrieb

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:

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. :-/

  • Anmelden oder Registrieren um Kommentare zu schreiben

Achso, dann mit .htaccess,

Eingetragen von Sammelzwerg (350)
am 04.01.2022 - 22:50 Uhr

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Don Pedro schrieb Aber

Eingetragen von Sammelzwerg (350)
am 04.01.2022 - 22:56 Uhr
Don Pedro schrieb

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. :-/

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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Sammelzwerg schrieb Achso,

Eingetragen von Don Pedro (19)
am 04.01.2022 - 23:01 Uhr
Sammelzwerg schrieb

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

Falls du das meinst:

Zitat:

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

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Sammelzwerg schrieb Achso,

Eingetragen von Don Pedro (19)
am 04.01.2022 - 23:01 Uhr
Sammelzwerg schrieb

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

Falls du das meinst:

Zitat:

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

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Jetzt mal zum Verständnis,

Eingetragen von Sammelzwerg (350)
am 04.01.2022 - 23:08 Uhr

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?

  • Anmelden oder Registrieren um Kommentare zu schreiben

Sammelzwerg schriebJetzt mal

Eingetragen von Don Pedro (19)
am 04.01.2022 - 23:39 Uhr
Sammelzwerg schrieb

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Ok, also hast du vom Hoster

Eingetragen von Sammelzwerg (350)
am 05.01.2022 - 00:03 Uhr

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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Ok, also hast du vom Hoster

Eingetragen von Sammelzwerg (350)
am 05.01.2022 - 00:05 Uhr

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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Sammelzwerg schriebOk, also

Eingetragen von Don Pedro (19)
am 05.01.2022 - 00:45 Uhr
Sammelzwerg schrieb

Ok, also hast du vom Hoster das Verzeichnis .../web, richtig?

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

Sammelzwerg schrieb

Da drin legst du für jede Seite einen Ordner an, der kann beliebig heißen, nehmen wir mal Site1 als Beispiel.

Ja, so habe ich das schon getan!

Sammelzwerg schrieb

Habe ich das richtig verstanden, daß der Composer, also das Programm Composer, jeweils für das Verzeichnis installiert wird?

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.

Sammelzwerg schrieb

Bei mir ist der global in /usr/local/bin, aber das geht vielleicht bei dir nicht.

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.

Sammelzwerg schrieb

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.

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.

Sammelzwerg schrieb

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.

  • 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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Zitat: Soll ich mal sites.php

Eingetragen von Sammelzwerg (350)
am 05.01.2022 - 00:47 Uhr
Zitat:

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

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Sammelzwerg schriebJa, oder

Eingetragen von Don Pedro (19)
am 05.01.2022 - 10:27 Uhr
Sammelzwerg schrieb

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Hast du schon die Caches

Eingetragen von Sammelzwerg (350)
am 05.01.2022 - 10:31 Uhr

Hast du schon die Caches geleert?

  • Anmelden oder Registrieren um Kommentare zu schreiben

Sammelzwerg schrieb Hast du

Eingetragen von Don Pedro (19)
am 05.01.2022 - 18:41 Uhr
Sammelzwerg schrieb

Hast du schon die Caches geleert?

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

VG

Don

  • Anmelden oder Registrieren um Kommentare zu schreiben

Sorry dass es so lange

Eingetragen von Don Pedro (19)
am 12.01.2022 - 23:54 Uhr

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Ich wüsste da jetzt sonst

Eingetragen von Sammelzwerg (350)
am 13.01.2022 - 23:47 Uhr

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Benutzeranmeldung

  • Registrieren
  • Neues Passwort anfordern

Aktive Forenthemen

  • entity print - pdf template Seitennummern
  • Webform - kleiner Einleitungstext vor dem Formular.
  • migrate: legacy-db-key in settings.php, wie?
  • Konto löschen, wie? (Drupalorg/Drupalcenter)
  • Wie 'saubere' Dateinamen bei Upload erzwingen?
  • Modul lässt Website anstürzen
  • Showroom
  • rename admin paths - Probleme mit Modul - Alterantive?
  • Probleme mit Installation voa COMPOSER
  • Drupal- Vor- und Nachteile
  • Text Editor verschwunden
  • Wie URL Alias für Entity in Drupal 9 erstellen?
Weiter

Neue Kommentare

  • Du könntest einen
    vor 2 Tagen 10 Stunden
  • Das findet man in diesem
    vor 4 Tagen 11 Stunden
  • Hallo, bitte löscht meinen
    vor 6 Tagen 9 Stunden
  • Schau mal hier
    vor 6 Tagen 15 Stunden
  • Das Modul ist ja ganz schön,
    vor 1 Woche 2 Tagen
  • Modul Purge
    vor 1 Woche 3 Tagen
  • Nö
    vor 1 Woche 3 Tagen
  • Manuell aus der Datenbank löschen
    vor 1 Woche 3 Tagen
  • Bots ... auf Abstand
    vor 1 Woche 4 Tagen
  • Cache vs Browser
    vor 1 Woche 4 Tagen

Statistik

Beiträge im Forum: 247807
Registrierte User: 19542

Neue User:

  • Dvkah
  • Dhev
  • Chrisvek

» Alle User anzeigen

User nach Punkten sortiert:
wla9210
stBorchert6003
quiptime4972
Tobias Bähr4019
bv3924
ronald3845
md3717
Thoor3678
Alexander Langer3416
Exterior2903
» User nach Punkten
Zur Zeit sind 0 User und 4 Gäste online.

Hauptmenü

  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche

Quicklinks I

  • Infos
  • Drupal Showcase
  • Installation
  • Update
  • Forum
  • Team
  • Verhaltensregeln

Quicklinks II

  • Drupal Jobs
  • FAQ
  • Drupal-Kochbuch
  • Best Practice - Drupal Sites - Guidelines
  • Drupal How To's

Quicklinks III

  • Tipps & Tricks
  • Drupal Theme System
  • Theme Handbuch
  • Leitfaden zur Entwicklung von Modulen

RSS & Twitter

  • Drupal Planet deutsch
  • RSS Feed News
  • RSS Feed Planet
  • Twitter Drupalcenter
Drupalcenter Team | Impressum & Datenschutz | Kontakt
Angetrieben von Drupal | Drupal is a registered trademark of Dries Buytaert.
Drupal Initiative - Drupal Association