Könnte jemand einen architektonischen Überblick über den Kontrollfluss von Drupal 7 geben? Vielleicht im Sinne eines Flussdiagramms darüber, wie eine Seite generiert wird. Welche zusätzlichen Ressourcen würden Sie empfehlen, in Bezug auf die Funktionsweise von Drupal zu konsultieren?
Antworten
Zu viele Anzeigen?Drupal kann in dieser Hinsicht verwirrend sein, teilweise weil es einen relativ tiefen Funktionsstapel hat. Obwohl es sich um prozedurales PHP handelt, ist es in seiner Architektur rein ereignis- bzw. listenergesteuert, und es gibt keinen einfachen "Fluss" im Haupt-PHP-Skript, den Sie durchschauen können. Ich habe kürzlich einen Vortrag zu diesem Thema und die Folien sind auf Slideshare veröffentlicht, aber eine kurze Zusammenfassung könnte nützlich sein.
- Die index.php-Datei von Drupal fungiert als Frontside-Controller. Alle Seiten werden durch sie geleitet, und die "tatsächliche" URL/der Pfad, den der Benutzer angefordert hat, wird als Parameter an index.php übergeben.
- Das Pfad-Router-System von Drupal (MenuAPI) wird verwendet, um den angeforderten Pfad mit einem bestimmten Plugin-Modul abzugleichen. Dieses Plugin-Modul ist für die Erstellung des "primären Inhalts" der Seite verantwortlich.
- Sobald der primäre Seiteninhalt erstellt ist, ruft index.php theme('page', $content) auf, das den Inhalt an das Theming/Skinning-System von Drupal übergibt. Dort wird er in Sidebars/Header/Widgets/etc. verpackt.
- Die gerenderte Seite wird dann an den Apache zurückgegeben und an den Browser des Benutzers zurückgeschickt.
Während dieses gesamten Prozesses lösen Drupal- und Plugin-Module von Drittanbietern Ereignisse aus und warten darauf, dass sie reagieren. Drupal nennt dies das "Hook"-System, und es wird mit Hilfe von Funktionsnamenskonventionen implementiert. Das "Blog"-Modul zum Beispiel kann "user"-bezogene Ereignisse abfangen, indem es eine Funktion namens blog_user() implementiert. In der Drupal-Sprache heißt das hook_user() .
Es ist ein bisschen klobig, aber aufgrund einer PHP-Eigenheit (es behält eine interne Hashtable aller geladenen Funktionen), erlaubt es Drupal, schnell nach Hörern zu suchen, indem es einfach eine Liste der installierten Plugins durchläuft. Für jedes Plugin kann es function_exists() für das entsprechend benannte Muster aufrufen und die Funktion aufrufen, wenn sie existiert. ("Ich feuere das Ereignis 'login' ab. Existiert die Funktion 'mymodule_login'? Ich rufe sie auf. Existiert 'yourmodule_login'? Nein? Wie wäre es mit 'nextmodule_login'?" usw.) Auch hier ist es etwas klobig, aber es funktioniert ziemlich gut.
Alles die in Drupal passieren, passieren, weil eines dieser Ereignisse ausgelöst wird. Die MenuAPI weiß nur, welche URLs/Pfade von verschiedenen Plugin-Modulen bearbeitet werden, weil sie das Ereignis "menu" (hook_menu) auslöst und alle Metadaten sammelt, mit denen Plugin-Module antworten. ("Ich kümmere mich um die URL 'news/recent', und hier ist die Funktion, die aufgerufen wird, wenn die Seite aufgebaut werden muss...") Der Inhalt wird nur gespeichert, weil die FormAPI von Drupal für den Aufbau einer Seite verantwortlich ist und das Ereignis "Ein Formular wurde eingereicht" auslöst, auf das ein Modul reagieren kann. Die stündliche Wartung erfolgt, weil hook_cron() ausgelöst wird, und jedes Modul mit mymodulename_cron() als Funktionsname wird seine Funktion aufrufen.
Alles andere sind letztlich nur Details - wichtige Details, aber Variationen des Themas. index.php ist der Controller, das Menüsystem bestimmt, was die "aktuelle Seite" ist, und viele Ereignisse werden beim Aufbau dieser Seite ausgelöst. Plugin-Module können sich in diese Ereignisse einklinken und den Arbeitsablauf ändern/zusätzliche Informationen bereitstellen/etc. Das ist auch einer der Gründe, warum sich so viele Drupal-Ressourcen auf die Erstellung von Modulen konzentrieren. Ohne Module macht Drupal eigentlich nichts anderes, als zu sagen: "Jemand hat nach einer Seite gefragt! Existiert sie? Nein? OK, ich werde eine 404 anzeigen.
Um zu verstehen, wie Drupal funktioniert, müssen Sie den Page-Serving-Mechanismus von Drupal verstehen.
Kurz gesagt, alle Aufrufe/Urls/Anfragen werden von index.php bedient, die Drupal lädt, indem sie verschiedene Include-Dateien/Module einschließt und dann die entsprechende Funktion aufruft, die im Modul definiert ist, um die Anfrage/Url zu bedienen.
Hier ist der Auszug aus dem Buch Pro Drupal Development, der den Bootstrap-Prozess von Drupal erklärt,
Der Bootstrap-Prozess
Drupal bootet sich bei jeder Anfrage selbst, indem es eine Reihe von Bootstrap-Phasen durchläuft. Diese Phasen sind in bootstrap.inc definiert und laufen wie in den folgenden Abschnitten beschrieben ab.
Konfiguration initialisieren
In dieser Phase wird das interne Konfigurations-Array von Drupal aufgefüllt und die Basis-URL festgelegt ($base_url) der Website. Die Datei settings.php wird mittels include_once() geparst, und alle dort festgelegten Variablen- oder String-Überschreibungen werden angewendet. Weitere Informationen finden Sie in den Abschnitten "Variable Overrides" und "String Overrides" in der Datei sites/all/default/default.settings.php.
Frühzeitiger Seiten-Cache
In Situationen, die ein hohes Maß an Skalierbarkeit erfordern, muss ein Caching-System möglicherweise aufgerufen werden, bevor überhaupt eine Datenbankverbindung versucht wird. Die frühe Seiten-Cache-Phase ermöglicht Sie (mit include()) eine PHP-Datei einbinden, die eine Funktion namens page_cache_ fastpath() enthält, die den Inhalt an den Browser zurückgibt. Der frühe Seitencache wird aktiviert, indem die Variable page_cache_fastpath auf TRUE gesetzt wird, und die einzubindende Datei wird definiert, indem die Variable cache_inc auf den Pfad der Datei gesetzt wird. Siehe das Kapitel über Caching für ein Beispiel.
Datenbank initialisieren
Während der Datenbankphase wird der Datenbanktyp bestimmt und eine erste Verbindung hergestellt. hergestellt, die für Datenbankabfragen verwendet werden soll.
Hostname/IP-basierte Zugangskontrolle
Drupal erlaubt die Sperrung von Hosts auf einer Pro-Hostname/IP-Adressen-Basis. In der Phase der Zugriffskontrolle Phase wird kurz geprüft, ob die Anfrage von einem gesperrten Host kommt; wenn ja, wird der Zugriff verweigert.
Initialisierung der Sitzungsbehandlung
Drupal nutzt die Vorteile von PHPs eingebauter Sitzungsbehandlung, überschreibt aber einige der Handler mit seinen eigenen, um eine datenbankgestützte Sitzungsbehandlung zu implementieren. Sessions werden initialisiert oder in der Session-Phase wiederhergestellt. Das globale $user-Objekt, das den aktuellen Benutzer wird hier ebenfalls initialisiert, obwohl aus Gründen der Effizienz nicht alle Eigenschaften verfügbar sind (sie werden bei Bedarf durch einen expliziten Aufruf der Funktion user_load() hinzugefügt).
Late Page Cache
In der späten Seitencache-Phase lädt Drupal genügend unterstützenden Code, um festzustellen, ob oder ob eine Seite aus dem Seitencache ausgeliefert werden soll oder nicht. Dazu gehören das Zusammenführen von Einstellungen aus der Datenbank in das Array, das während der Initialisierungsphase der Konfiguration erstellt wurde, und das Laden oder Parsen von Modulcode. Wenn die Sitzung anzeigt, dass die Anfrage von einem anonymen Benutzer gestellt wurde und das Seiten-Caching aktiviert ist, wird die Seite aus dem Cache zurückgegeben und die Ausführung angehalten.
Bestimmung der Sprache
In der Phase der Sprachermittlung wird die mehrsprachige Unterstützung von Drupal initialisiert und eine Entscheidung getroffen, welche Sprache für die aktuelle Seite auf der Grundlage der Site- und Benutzereinstellungen verwendet werden soll. Drupal unterstützt mehrere Alternativen zur Bestimmung der Sprachunterstützung, wie z. B. Pfadpräfix und Sprachaushandlung auf Domänenebene.
Pfad
In der Pfadphase wird der Code geladen, der Pfade und Pfad-Aliasing behandelt. Diese Phase ermöglicht lesbare URLs aufgelöst werden und verwaltet Drupal-interne Pfad-Caches und Nachschlagen.
Vollständig
In dieser Phase wird der Bootstrap-Prozess abgeschlossen, indem eine Bibliothek mit allgemeinen Funktionen geladen wird, Thema Unterstützung, und Unterstützung für Callback Mapping, Dateiverarbeitung, Unicode, PHP Image Toolkits, Formular Formularerstellung und -verarbeitung, E-Mail-Bearbeitung, automatisch sortierbare Tabellen und Paging von Ergebnismengen. Der benutzerdefinierte Fehlerhandler von Drupal wird eingestellt und alle aktivierten Module werden geladen. Schließlich löst Drupal den Init-Hook aus, damit die Module die Möglichkeit haben, benachrichtigt zu werden, bevor die offizielle Verarbeitung der Anfrage beginnt.
Sobald Drupal das Bootstrapping abgeschlossen hat, sind alle Komponenten des Frameworks verfügbar. Nun ist es an der Zeit, die Anfrage des Browsers an die PHP-Funktion weiterzuleiten, die bearbeiten wird. Die Zuordnung zwischen URLs und Funktionen, die sie bearbeiten, wird durch eine Callback-Registrierung, die sich sowohl um die URL-Zuordnung als auch um die Zugriffskontrolle kümmert. Module registrieren ihre Rückrufe mit Hilfe des Menü-Hakens (weitere Einzelheiten finden Sie in Kapitel 4).
Wenn Drupal festgestellt hat, dass es einen Callback gibt, zu dem die URL des Browsers Anfrage erfolgreich zugeordnet werden kann und dass der Benutzer die Erlaubnis hat, auf diesen Callback zuzugreifen, wird die Kontrolle an die Callback-Funktion übergeben.
Bearbeitung einer Anfrage
Die Rückruffunktion erledigt alle Aufgaben, die zur Verarbeitung und Sammlung der für die Erfüllung der Anfrage erforderlichen Daten erforderlich sind. Zum Beispiel, wenn eine Anfrage für Inhalte wie http://example.com/ q=node/3 empfangen wird, wird die URL auf die Funktion node_page_view() in node.module abgebildet. Bei der weiteren Verarbeitung werden die Daten für diesen Knoten aus der Datenbank abgerufen und in eine Datenstruktur eingefügt. Dann ist es Zeit für das Theming.
Theming der Daten
Beim Theming werden die abgerufenen, bearbeiteten oder erstellten Daten umgewandelt in HTML (oder XML oder ein anderes Ausgabeformat). Drupal verwendet das Thema, das der Administrator das der Administrator ausgewählt hat, um der Webseite das richtige Aussehen und Gefühl zu geben. Die resultierende Ausgabe wird dann an den Webbrowser (oder einen anderen HTTP-Client) gesendet.
Die Antwort von Eaton gibt einen guten Überblick. (Ich bin neu hier, daher kann ich ihn nicht ändern, daher der Kommentar).
Der brutale "Aha"-Moment für mich war die Erkenntnis, dass alles durch index.php und dann durch den Wasserfall von Modulen (Kern zuerst, dann nach Standort) geschieht. Um die Kernfunktionalität zu erweitern, muss sie nicht neu geschrieben werden. Kopieren Sie stattdessen das Modul in /sites/all/modules/ oder /sites/ [Ihre Seite] /modules und erweitern THAT, oder erstellen Sie ein neues Modul an diesen Stellen. Dasselbe gilt für Themes. Modulverzeichnisse können auch Anzeigecode in Form von tpl, css usw. enthalten.
Wenn Sie an striktere MVC-Frameworks wie Rails, Django usw. gewöhnt sind, wird das alles ein wenig verwirrend. Module können in eine Menge von Display-Code zu mischen, und wenn Sie auf jemand anderes Module oder Vorlagen suchen Sie schließlich am Ende zu Fuß rückwärts durch den Stapel. Das ist das Schöne/Schmerzhafte an der Arbeit in PHP.
Ironischerweise ist "einfach eine App bauen" vielleicht der schlechteste Weg, dies zu lernen. Drupal tut so viel aus der Box, die einfach obskur ist, bis Sie herausfinden, den Kontrollfluss. Es gibt nichts in einer tpl-Datei, die Ihnen sagt, woher eine Funktion mit einem lustigen Namen wie l() kommt, zum Beispiel.
Es hängt davon ab, wie tief das Verständnis Sie suchen; wenn Sie eine gute Kenntnis von php haben, würde ich vorschlagen, durch den Code selbst zu lesen, beginnend mit index.php, und dann weiter zu den includes/bootstrap.inc, und dann einige der anderen Skripte in diesem Verzeichnis.
Die wichtigsten Include-Dateien:
- menu.inc ist sehr wichtig, um zu verstehen, wie das gesamte System funktioniert, da es einen großen Teil der impliziten Zuordnung von URLs zu Inhalten übernimmt.
- common.inc enthält die meisten der sonst so geheimnisvollen Funktionen, die die Grundlage der API bilden.
- module.inc behandelt die von Eaton erwähnten Hook-Aufrufe
- form.inc befasst sich mit der Anzeige, Übermittlung und Verarbeitung von Formularen
- theme.inc übernimmt die Präsentation.
Es gibt auch einige wichtige Funktionen im Verzeichnis modules/; insbesondere modules/node/node.module bildet die Grundlage des Node-Systems, das im Allgemeinen zur Kapselung von Website-Inhalten verwendet wird.
Der Code ist im Allgemeinen sehr gut kommentiert und klar. Die Verwendung von Doxygen-Markup innerhalb der Kommentierung bedeutet, dass der Code tatsächlich die kanonische Dokumentation ist.
Es ist auch hilfreich, dies mit einem Editor zu tun, mit dem man schnell zur Definition einer Funktion springen kann. Die Verwendung von vim in Kombination mit ctags funktioniert bei mir; Sie müssen ctags anweisen, .inc-, .module- usw. Dateien als php-Dateien zu indizieren.
Diese (für Drupal 6) & este (für Drupal 7) ist ein ziemlich guter Überblick über die Architektur von Drupal. Wenn Sie mehr Details wollen, dann würde ich anfangen, etwas zu schreiben Die meisten der Dokumentation ist gut. Der Versuch, es auf einer hohen Detailstufe zu lernen, ohne etwas Konkretes zu erreichen, wird viel schwieriger sein, als etwas auszuprobieren.
- See previous answers
- Weitere Antworten anzeigen