The request lifecycle #

This page follows one web request through Exponential, from index.php to the response, and names the class and file of each step. It is the summary of The request lifecycle in the kernel architecture standard; read that section when you change anything on this path.

Contents #

1. Before the kernel
2. The kernel constructor
3. The dispatch loop
4. Output and shutdown
5. Short cuts: who can answer first
6. The same code outside a web request
7. Rules for changes on this path

Before the kernel #

1. Maintenance and repair hooks. If var/maintenance.json exists, expMaintenance::check() (kernel/classes/expmaintenance.php) may answer the request with the maintenance page. A request carrying exp_repair is handed to ezpRepairQueue (lib/ezutils/classes/ezprepairqueue.php), which can repair an installation without its Composer libraries (Repair from the browser).
2. Autoload. autoload.php loads the generated class maps: autoload/ezp_kernel.php and the extension map written by php bin/php/ezpgenerateautoloads.php -e.
3. Kernel object. new ezpKernel( new ezpKernelWeb() ), then $kernel->run()->getContent(). ezpKernel is a thin wrapper around a handler implementing ezpWebBasedKernelHandler.

The kernel constructor #

ezpKernelWeb (kernel/private/classes/ezpkernelweb.php), in order:

The dispatch loop #

run() and dispatchLoop():

1. Session and request initialization (sessionInit(), requestInit()).
2. The events request/preinput and request/input (Events, extension points and plugins).
3. URL translation: a URL alias or wildcard becomes a module address (eZURLAliasML, eZURLWildcard); /About-us becomes, for example, content/view/full/58.
4. The module check (eZModule::accessAllowed()), fetchModule(), the siteaccess login check (the user/login policy) and the view access check (eZUser::hasAccessToView()).
5. Request rules, when configured, decide after URL translation and the policy check whether to allow, deny, redirect, rewrite or log (Request rules).
6. $module->run( $functionName, $params, ... ) runs the view. A view can ask for a rerun with another URI or a redirect (eZModule::STATUS_RERUN, STATUS_REDIRECT); the loop handles both.

Output and shutdown #

• The view's $Result is placed into the pagelayout (pagelayout.tpl unless the view sets another), passed through eZDisplayResult() and the output filters response/preoutput and response/output (kernel/private/classes/global_functions.php).
• shutdown() writes pending data. Under Velocity the worker is then reset for the next request (Velocity persistent workers).
• Every request is classified once, whichever way it ends, and a not-found answer or a probe goes to its own log (Request logs).

Short cuts: who can answer first #

Details: Caching layers for engineers.

The same code outside a web request #

Command line scripts and cronjobs do not use ezpKernelWeb: they boot through eZScript. The console (bin/php/console) discovers commands; runcronjobs.php runs cronjob parts (Console, cronjobs and background work).

Rules for changes on this path #

• A change must keep working under PHP-FPM, Velocity and FrankenPHP.
• Code in ezpKernelWeb guards newer classes with class_exists(), because a long-running Velocity worker may have loaded its class map before the class existed; new kernel hooks should do the same.
• Per-request state must not live in static properties without a reset.
• No exit for flow control except through eZExecution::cleanExit().

Related pages #

• Architecture overview
• Modules, views and access control
• Concurrency, statics and long-lived processes
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.