Skip to the content
Documentation
Help Start
Reading in:
  • German: 9,059 of 9,059 pages
About the help in other languages
All help pages

Der Lebenszyklus einer Anfrage

Was in Exponential zwischen einer Browseranfrage und der Antwort geschieht, Schritt für Schritt - Wartungs- und Reparatur-Hooks, Autoload, der Konstruktor des Kernels, Siteaccess-Zuordnung, URL-Übersetzung…

Download as PDF

Address: https://doc.exponential.earth/exphelp/viewer/help/software-engineers/request-lifecycle.md

On this page

This page is a translation. Read the English original

Der Lebenszyklus einer Anfrage

Diese Seite folgt einer Webanfrage durch Exponential, von index.php bis zur Antwort, und nennt Klasse und Datei jedes Schritts. Sie ist die Zusammenfassung von Der Lebenszyklus einer Anfrage im Standard zur Kernel-Architektur; lesen Sie diesen Abschnitt, wenn Sie etwas auf diesem Weg ändern.

Inhalt

  1. Vor dem Kernel
  2. Der Konstruktor des Kernels
  3. Die Weiterleitungsschleife
  4. Ausgabe und Herunterfahren
  5. Abkürzungen: wer zuerst antworten kann
  6. Derselbe Code außerhalb einer Webanfrage
  7. Regeln für Änderungen auf diesem Weg

Vor dem Kernel

  1. Wartungs- und Reparatur-Hooks. Existiert var/maintenance.json, kann expMaintenance::check() (kernel/classes/expmaintenance.php) die Anfrage mit der Wartungsseite beantworten. Eine Anfrage mit exp_repair wird an ezpRepairQueue (lib/ezutils/classes/ezprepairqueue.php) übergeben, das eine Installation ohne ihre Composer-Bibliotheken reparieren kann (Reparatur aus dem Browser).
  2. Autoload. autoload.php lädt die erzeugten Klassenzuordnungen: autoload/ezp_kernel.php und die Zuordnung der Erweiterungen, die php bin/php/ezpgenerateautoloads.php -e schreibt.
  3. Kernel-Objekt. new ezpKernel( new ezpKernelWeb() ), dann $kernel->run()->getContent(). ezpKernel ist eine dünne Hülle um einen Handler, der ezpWebBasedKernelHandler implementiert.

Der Konstruktor des Kernels

ezpKernelWeb (kernel/private/classes/ezpkernelweb.php), der Reihe nach:

SchrittWas geschieht
Einstellungenliest i18n.ini und site.ini, setzt Zeitzone und Dateiberechtigungen, initialisiert eZSys
Globale ErweiterungeneZExtension::activateExtensions( 'default' )
SiteaccesseZSiteAccess::match() auf die Anfrage-URI, sofern keiner injiziert wurde, dann eZSiteAccess::change()
Siteaccess-ErweiterungeneZExtension::activateExtensions( 'access' ), und die INI-Instanzen werden zurückgesetzt, damit Siteaccess-Einstellungen gelten

Die Weiterleitungsschleife

run() und dispatchLoop():

  1. Initialisierung von Session und Anfrage (sessionInit(), requestInit()).
  2. Die Events request/preinput und request/input (Events, Erweiterungspunkte und Plugins).
  3. URL-Übersetzung: ein URL-Alias oder -Platzhalter wird zu einer Moduladresse (eZURLAliasML, eZURLWildcard); /About-us wird zum Beispiel zu content/view/full/58.
  4. Die Modulprüfung (eZModule::accessAllowed()), fetchModule(), die Anmeldeprüfung des Siteaccess (die Richtlinie user/login) und die Zugriffsprüfung der View (eZUser::hasAccessToView()).
  5. Anfrageregeln entscheiden, wenn konfiguriert, nach der URL-Übersetzung und der Richtlinienprüfung, ob erlaubt, verweigert, umgeleitet, umgeschrieben oder protokolliert wird (Anfrageregeln).
  6. $module->run( $functionName, $params, ... ) führt die View aus. Eine View kann einen erneuten Lauf mit einer anderen URI oder eine Weiterleitung anfordern (eZModule::STATUS_RERUN, STATUS_REDIRECT); die Schleife behandelt beides.

Ausgabe und Herunterfahren

  • Das $Result der View wird in das Pagelayout gesetzt (pagelayout.tpl, sofern die View kein anderes setzt), durch eZDisplayResult() und die Ausgabefilter response/preoutput und response/output geleitet (kernel/private/classes/global_functions.php).
  • shutdown() schreibt ausstehende Daten. Unter Velocity wird der Worker danach für die nächste Anfrage zurückgesetzt (Persistente Worker von Velocity).
  • Jede Anfrage wird einmal klassifiziert, wie auch immer sie endet, und eine Nicht-gefunden-Antwort oder ein Sondierungsversuch geht in ein eigenes Log (Anfrage-Logs).

Abkürzungen: wer zuerst antworten kann

WerWannKernel gestartet?
Browser oder CDNdie Seite oder Datei ist in deren Cache noch frischgar keine Anfrage
Antwort-Cache von Velocityeine öffentliche Seite liegt im Serverprozess im Cachenein
Rollenbewusster HTTP-Cacheeingeschaltet, und eine gespeicherte Ansicht passt zum Berechtigungskontextnein (ein früher Ausstieg aus config.php unter PHP-FPM)
Wartungs-Hookder Wartungsmodus ist anteilweise (vor dem Kernel)
View-Cache für Inhalteeine zwischengespeicherte Kopie dieser Inhaltsansicht existiertja, aber die Ansicht wird nicht gerendert

Details: Caching-Ebenen für Ingenieure.

Derselbe Code außerhalb einer Webanfrage

Kommandozeilenskripte und Cronjobs verwenden nicht ezpKernelWeb: Sie starten über eZScript. Die Konsole (bin/php/console) findet Befehle; runcronjobs.php führt Cronjob-Teile aus (Konsole, Cronjobs und Hintergrundarbeit).

Regeln für Änderungen auf diesem Weg

  • Eine Änderung muss unter PHP-FPM, Velocity und FrankenPHP weiter funktionieren.
  • Code in ezpKernelWeb sichert neuere Klassen mit class_exists() ab, weil ein langlaufender Velocity-Worker seine Klassenzuordnung geladen haben kann, bevor die Klasse existierte; neue Kernel-Hooks sollten es genauso tun.
  • Zustand je Anfrage darf nicht ohne Zurücksetzen in statischen Eigenschaften liegen.
  • Kein exit zur Ablaufsteuerung, außer über eZExecution::cleanExit().

Verwandte Seiten

Werden Sie Exponential-Partner

Partner teilen ihre Informationen, stellen Mittel bereit, geben Beiträge zurück und entwickeln die Produkte mit uns, und so wächst Exponential. Eine Partner-Website und ein Dashboard sind für Mitte 2027 geplant: Werden Sie noch heute Partner, damit wir schneller wachsen und neue Funktionen früher liefern.

Something wrong on this page? Report an error

Documentation license

This documentation is free documentation, licensed under the GNU Free Documentation License 1.3 or later.

Exponential Copyright © 1998-2026 Exponential Foundation and 7x