Wie eine Anfrage in PHP abläuft #

Diese Seite richtet sich an PHP-Entwickler, die wissen möchten, was zwischen dem Moment passiert, in dem der Webserver eine Anfrage an PHP übergibt, und dem Moment, in dem die Seite PHP verlässt. Wenn Sie die Reihenfolge kennen, wissen Sie, wo Ihr Code läuft, was bereits eingerichtet ist, wenn er läuft, und in welche Ereignisse Sie sich einklinken können. Die folgenden Namen sind die echten Klassen und Methoden; öffnen Sie die Dateien neben dieser Seite.

Inhalt #

1. Die Kurzfassung
2. index.php
3. autoload.php
4. ezpKernelWeb: Initialisierung
5. Die Dispatch-Schleife
6. Das Pagelayout und die Ausgabe
7. Herunterfahren
8. Ereignisse unterwegs
9. Die Kommandozeile ist anders

Die Kurzfassung #

index.php
  -> autoload.php                    EXP_ROOT_DIR, phpcompat on PHP < 8.1, phar decision, class map autoloader
  -> new ezpKernel( new ezpKernelWeb() )->run()
       ezpKernelWeb::run()
         requestInit()               settings, siteaccess, session, request/preinput and request/input events
         headers                     defaults plus security headers
         dispatchLoop()              URL alias translation, module and view lookup, policy checks, eZModule::run()
         pagelayout                  eZTemplate with $module_result, unless the view switched it off
         response/output filter      the form token is added to POST forms here
         shutdown()
  -> echo $result->getContent()

index.php #

index.php (der Web-Front-Controller) tut selbst wenig:

1. Setzt eine Standard-Zeitzone, wenn php.ini keine hat, ignore_user_abort( true ) und error_reporting( E_ALL ).
2. Beantwortet den Wartungsmodus aus var/maintenance.json, bevor Einstellungen oder die Datenbank gelesen werden (expMaintenance::check()).
3. Bindet autoload.php ein.
4. Führt eine Anfragefilter-Datei aus, wenn config.php EXP_REQUEST_PREPEND_FILE definiert. Sie läuft bei jeder Anfrage, auch in einem persistenten Worker, in dem config.php selbst nur einmal läuft.
5. Zeigt PHP-Fehler im Browser, wenn eZINI::environment() dev oder test ist (aus EXP_ENV in config.env.php).
6. Führt den Kernel aus: $kernel = new ezpKernel( new ezpKernelWeb() ); echo $kernel->run()->getContent();

autoload.php #

Jeder Einstiegspunkt beginnt hier, im Web wie auf der Kommandozeile:

ezpKernelWeb: Initialisierung #

ezpKernelWeb (kernel/private/classes/ezpkernelweb.php) wird mit der Anfrage konstruiert und bereitet sie vor:

• liest site.ini und ermittelt den Siteaccess (nach Host, Port oder URI), der die geltenden Einstellungen bestimmt;
• startet die Sitzung (sessionInit()) und die Anfrage (requestInit()), die request/preinput und dann request/input meldet (ezpEvent::getInstance()->notify( 'request/input', ... )); die Formular-Token-Prüfung von ezformtoken ist ein Listener von request/input;
• sendet die Standard-Header (Cache-Control, Content-Type, Content-language, die Sicherheits-Header von ezpKernelWeb::securityHeaders()), die sich je Pfad über eZHTTPHeader überschreiben lassen.

Ein POST ohne gültiges Formular-Token endet hier mit einer 403-Seite, bevor irgendein Modul läuft (CSRF-Schutz und ezformtoken).

Die Dispatch-Schleife #

ezpKernelWeb::dispatchLoop() macht aus der Adresse ein Modulergebnis:

1. URL-Übersetzung. Wenn der URL-Übersetzer aktiviert ist, macht eZURLAliasML::translate() aus /about-us content/view/full/<node>, danach werden Platzhalter versucht (eZURLWildcard::translate()).
2. Modulsuche. eZModule::accessAllowed() prüft die Modul- und View-Listen des Siteaccess, eZModule::exists() lädt die module.php des Moduls.
3. Zugriff. Der Benutzer braucht user/login für den Siteaccess, danach prüft hasAccessToView() die functions der View gegen die Richtlinien des Benutzers. Views in [RoleSettings] PolicyOmitList[] überspringen das.
4. Die View. $module->run( $functionName, $params ) führt die View-Datei über eZProcess::runFile() aus, das ihr $Params (mit $Params['Module']) übergibt und $Result zurücknimmt. Eine klassenbasierte View gibt dasselbe Array zurück (Modul-Views als Klassen).
5. Weiterleitungen und Fehler. Eine View kann weiterleiten ($Module->redirectTo()) oder einen Fehler zurückgeben ($Module->handleError( eZError::KERNEL_NOT_FOUND, 'kernel' )), was die Schleife noch einmal durch das Fehlermodul führt.

Das Pagelayout und die Ausgabe #

Sofern die View es nicht ausgeschaltet hat ($Result['pagelayout'] = false; ein Template-Name dort wählt ein anderes Pagelayout), erzeugt der Kernel eZTemplate::factory(), setzt $module_result (Ihr $Result mit content, path und mehr) und rendert das pagelayout.tpl des Siteaccess (View-Ergebnisse und das Pagelayout). Die Ausgabe durchläuft dann den Filter response/output, in dem ezformtoken jedem method="post"-Formular das Token hinzufügt, und wird zu einem ezpKernelResult.

Herunterfahren #

shutdown() schließt die Zeile der Anfrage in den Anfrage-Logs ab (expRequestLog::finish()), führt die mit eZExecution::addCleanupHandler() registrierten Aufräum-Handler aus (eZExecution::cleanup()), markiert das Ende als sauber und speichert die Ablaufzeitstempel (eZExpiryHandler::shutdown()). Eine View, die ihre eigene Ausgabe sendet (einen Download, JSON), endet vorzeitig mit eZExecution::cleanExit(); unter Velocity beendet dieser Aufruf die Anfrage durch eine Exception, die der Server behandelt, also umschließen Sie ihn niemals mit catch ( Exception $e ) (Persistente Velocity-Worker für PHP-Entwickler).

Ereignisse unterwegs #

Wie Sie zuhören: Ereignisse, Listener und Filter.

Die Kommandozeile ist anders #

Kommandozeilenskripte führen ezpKernelWeb nicht aus. Sie beginnen mit autoload.php und dann eZScript: startup(), getOptions(), initialize() (Siteaccess, Erweiterungen, Sitzung, Datenbank) und shutdown(). [Event] Listeners[] werden nur an Webanfragen angehängt; [RunnableSettings] Listeners[] erreichen auch Befehle (Einen Konsolenbefehl schreiben).

Verwandte Seiten #

• Ein Rundgang durch den Quellbaum
• Das Muster Front-Controller
• Kernel-Architektur
• Freie Dokumentation: diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.