Module extern lagern

(Sub-)Domains sind keine Pfade in einem Dateisystem... *kratzamkopf*

So lange dir selbst nicht ganz klar ist, was du da genau fragen willst, ist es etwas anstrengend zu diskutieren.

Die Multisitefähigkeit von Drupal ist dir aber schon bekannt?

Das mit der Subdomain war vielleicht ein schlechtes Beispiel.

an sich hätte ich die Frage auch so formulieren können, ob es möglich ist, auf Module extern zuzugreifen.

Der Core wäre quasi auf Domain A gehostet und die Module liegen ganz woanders.

Dabei wäre dann natürlich zu klären, wie dieses woanders für Domain A zugreifbar sein müsste.

Um Multisitefähigkeit geht es hier, soweit ich das verstanden habe, nicht.

Bei Multisite geht es, soweit verstanden, darum, alles auf einem Websspace in verschiedenen Verzeichnissen zu lagern. Meine Idee ist es aber es quasi umgekehrt zu machen, nämlich eine Seite über verschiedene Webspaces zu verteilen.

Zunächst mal das babylonische Sprachgewirr etwas entheddert:
"Auf Domains" hostet man nicht. Eine Domain ist nichts weiter als ein Verweis, eine Zuordnung von Domainnamen zu einer IP-Adresse. Mit Webspace, den du eigentlich meinst, hat eine DOmain erstmal gar nichts zu tun.

Was das Splitting von Drupal über mehrere Webspaces angeht:
Geht so nicht. Via HTTP kannst du auf die Dateien nicht als PHP Quellcode Dateien zugreifen, da der Webserver bei einer Anforderung diese Dateien automatisch ausführt und du nur den Output geliefert bekommst.
Desweiteren wäre es performancetechnisch Overkill für jeden Seitenaufruf x Files von y Servern zusammenziehen zu müssen.

Im Grunde dreht es sich aber um die Frage: Wozu sollte ein solches Konstrukt gut sein?

Was auch gerne vergesen wird:
Die Ausfallwahrscheinlichkeit eines Systems steigt mit er Anzahl an Komponenten.

Ok, vielen Dank dafür, dass ich mich ungenau ausgedrückt habe und Du Dir die Zeit nahmst, dieses zu korrigieren.

Dass der Webserver die Dateien ausführt ist allerdings nicht wirklich korrekt. Man kann einen Server auch so konfigurieren, dass bspw der Plaintext gestreamt wird. Aber nur so nebenbei.

Und dass .module Dateien automatisch ausgeführt werden wäre mir komplett neu;) Aber das Offensichtliche hast Du in Deinem Bestreben mich zu Belehren wohl komplett vergessen.

Aber das kann jedem passieren. Deshalb hast Du wohl auch überlesen, was ich eigentlich meinte. Aber das ist in Ordnung. Jetzt weiss ich zumindest, dass Du ein Freund der Kleinkrämerei bist und unter Umständen dem üblichen Forenverhalten zu fröhnen gedenkst und einfach nicht helfen willst oder kannst.

----
Nun noch einmal die Frage für alle diejenigen, die gerne mal was probieren wollen und Interesse an Tüftelei haben:

Webspace A, Domain A: Drupal Core
Webspace B, Domain B: die Module (das sites/all/modules Verzeichnis)

Dass es möglich den Core aus A mit den Modulen aus B zu nutzen, sollte über die Möglichkeit von externen Includes und temporären Datein möglich sein. Aber gibt es dafür Ansätze? (Wenn nein, kann ich mir denken warum: Keine Lust...)

MfG
Passer

PS.
Bitte keine Besserwissereien mehr. Ich bin mir durchaus im Klaren, dass so etwas die Performance drückt. Ausserdem find ich Besserwissereien bzgl Kleinigkeiten eh doof. Das bringt niemanden weiter und kostet beide Seiten einfach nur Zeit.

Vielen Dank.

PPS.
Dass sich sowas in Foren nicht gänzlich vermeiden lässt weiss ich auch ;) Leider wollen viele nicht helfen, sondern sich einfach nur profilieren. Auch weiss ich, dass Ideen und Ansätze generell nicht gern gesehen sind (Wer braucht schon Autos, Storm oder gar das Internet ;)

Du willst keine Besserwisserei? D.h. du wünschst dir Antworten von denen, die es auch nicht besser wissen als du?

Da ist ja Gehaltvolles zu erwarten. Ich wünsche viel Spaß zu haben :-)

Es würden mir schon Antworten auf die Frage reichen.

Deine Antworten waren nicht auf die Frage bezogen, sondern dienten lediglich dazu, Dein Ego etwas aufzuwerten.

Mit der letzten Antwort hast Du diese Meinung weiterhin bestätigt.

Danke dafür, dass Du es nichtmal versucht hast.

MfG
Passer

PS.
Du weisst es auch nicht besser als ich, sonst hättest Du ja wahrscheinlich was hilfreiches geschrieben ;)

PPS.
Frag Dich mal, warum Du antwortest, obwohl Du keine Antwort weisst, vielleicht bringt Dich das menschlich weiter.

Ich erlaube mir den Luxus mir primär um Dinge Gedanken zu machen deren Nutzen auf der Hand liegt. Nach einem solchen fragte ich, bekam keine Antwort und daher gibts von meiner Seite kein Investment. Mit deinen Spitzen kannste vielleicht unseren gesperrten Tattoo-Holländer aus Berlin necken. Wünsche dir viel Glück, während ich andernorts nun meiner unermesslichen Geltungssucht fröhne. Schick mir mal ne Ansichtskarte, wenn du in Absurdistan angekommen bist. Porto zahl ich dir zurück. Ehrensache. :p P.S.: Ohne Tiernamen geht bei mir gar nichts.

Danke für Deine Zeit, dich nicht mit dem Thema zu beschäftigen.

Beiträge zu sammlen scheint Dir echt wichtiger zu sein, als zu helfen.

MfG
Passer

PS.
Denk einfach über voriges PPS nach. BRauchst auch nicht zuzugeben, wenn Dus verstanden hast. Ich wünsch Dir halt, dass es was bringt.

PPS.
Hoffentlich meldet sich die Tage jemand, der wirklich ne gute Idee zu dem Thema hat...

Das ist sehr aufwändig. Das Problem ist, das .module-Dateien über include_once Dateien einbinden, deren Namen zur Laufzeit in einer Variablen dynamisch generiert werden.

Die einzige Möglichkeit, aus einem Programm den Wert zu ermitteln, den eine Variable zu einem gewissen Zeitpunkt hat, ist, das Programm auszuführen. Du brauchst also eine virtuelle Systemumgebung, die dir das ermöglicht.

Erst wenn du den Wert der Variable kennst kannst du ihn so umbiegen, das ein include_once sich die Datei von einem externen Server hohlt. Die so erhaltene Datei musst du natürlich ersteinmal nachbearbeiten, damit sie nicht selbst unkontrollierte include_once-Anweisungen ausführt (die sich auch vielleicht ein einem eval() verstecken?).

Egal welcher Nutzen damit verbunden sein soll, es gibt bessere Ansätze. Über eine Ansichtskarte würde ich mich trotzdem freuen :-)

--

Bessere Ansätze...

Welche das sind würde mich interessieren.

Was diesen Ansatz betrifft:
Was das includieren angeht, hatte ich an eine Durchführung a la
hole txt-Datei mit Verzeichnisstruktur (und Pfaden).

Ohne Frage wäre ein Laden der Module zur Laufzeit Wahnsinn in Punkto Performance, aber für ein Update doch durchaus denkbar:
1) Hole Liste
2) identifiziere Updates
3) Lade Updates nach files/updates
4) Fordere user auf sites/all/modules rekursiv auf 777 zu setzen
5) Warte
6) Merke, welche Module aktiviert sind
7) kopiere Module von files/updates nach sites/all/modules
8) Fordere user auf sites/all/modules rekursiv auf 755 zu setzen
9) Führe DBUpdate durch

Fertig wäre das Update
Das ganze könnte man natürlich hier und dort noch verfeinern.

Das kommt auf das Problem an, das du mit dem externen Laden von Modulen erschlagen willst.

Wenn ich Updates automatisieren wollte, dann würde ich mir ein passendes Script schreiben, das ich von der Schell ausführe. update-status speichert alle für ein Update nötigen Informationen in der Datenbank: aktuelle Version des Moduls, empfohlene Version des Moduls, weitere verfügbare Versionen, jeweils inklusive URL. Download, entpacken und update.php kann man leicht automatisieren. Das hat den Vorteil, das man dort auch den Code für die Backup-Erstellung unterbringen kann.

Mit 666 erreichst du schon die Hölle. Mit 777 erreichst du eine Körperöffnung des Hausherren.

--

Das würdest Du machne, aber nur mal angenommen, man will die Wartungsarbeit vermindern und einen Shell Lösung ist nicht möglich...

Dann sollte man es trotzdem tunlichst vermeiden, irgendeinem Prozess sämtliche Schreibrechte auf das Drupal-Verzeichnis zu geben und dann noch Code von externen Quellen nachzuladen. Da könntest Du auch gleich das Admin-Kennwort des Servers/Accounts auf die Startseite schreiben.
Also: mal abgesehen davon, ob das überhaupt machbar ist, würde das Verlagern von Code-Teilen in externe Quellen ein riesiges Sicherheitsloch öffnen. Solltest Du das bei einem Hoster tun, musst Du damit rechnen, kurzzeitig keine Kontrolle mehr über Deinen Account zu haben oder Deine Seite woanders hosten zu müssen. Solltest Du das auf Deinem eigenen Server machen wollen; ok. Dann hast Du aber auch Shellzugriff und möchtest drush verwenden.

 Stefan

PS: und nein, es macht keinen Sinn, Module auf andere Server auszulagern.

Bevor du Aktualisierungen an deiner Live-Site vornimmst musst du die Aktualisierung auf einer Test-Site testen. Dann fällt ein manuelles Herunterladen und Entpacken nicht mehr ins Gewicht.

--