Architecture overview #

This page is the engineer's map of an Exponential installation: which layer does what, where it lives on disk, and which architectural decisions shape everything else. The authoritative description, with a rule for each building block, is Kernel architecture; this page summarizes it and adds the reasoning.

Contents #

1. The layers
2. The directory layout
3. Five architectural decisions
4. Where state lives
5. What the architecture does not have

The layers #

 Browser / CLI / cron
        |
 Server: Apache or nginx + PHP-FPM  |  Velocity (qbix)  |  FrankenPHP
        |
 Entry points: index.php  /  bin/php/console  /  runcronjobs.php
        |
 Kernel: ezpKernel -> ezpKernelWeb   settings -> extensions -> siteaccess -> session -> module
        |
 Modules and views: eZModule::run() -> view class  (kernel/<module>/, extensions)
        |
 Domain: kernel/classes  (content, users, roles, datatypes, workflows, caches)
        |
 Libraries: lib/ezdb (eZDB), lib/eztemplate (eZTemplate), lib/ezutils (eZINI, eZSys, ...)

The directory layout #

From the installation book (1.2 The parts of an installation):

kernel/, lib/      the kernel: modules, classes, the template engine, the database layer
autoload/          the kernel's class map (autoload/ezp_kernel.php)
extension/         extensions: your application lives here
design/            designs: templates, stylesheets, images
settings/          shipped settings; settings/siteaccess/ and settings/override/ hold yours
var/               runtime: caches, logs, storage, the SQLite database
bin/php/console    one entry point for every command
cronjobs/          the scripts runcronjobs.php runs
index.php          the front controller

Five architectural decisions #

1. One front controller, one dispatch loop. Every web request goes through index.php and ezpKernelWeb::run(); there is no second web entry point for normal pages. Special entry points exist for REST (index_rest.php), the tree menu (index_treemenu.php) and clustered file serving (index_cluster.php).
2. The siteaccess is the unit of configuration. A siteaccess is a named configuration selected per request (a site, the administration, a language); most behavior differences are settings, not code (Siteaccesses and configuration).
3. Everything pluggable is named in settings. Modules, datatypes, workflow events, template operators, cronjob parts, notification handlers, login handlers and cluster file handlers are found through INI lists, so an extension plugs in by shipping a class and an .ini.append.php file (Events, extension points and plugins).
4. A runtime-defined content model. Content classes are data, not code: administrators add classes and attributes without a deployment, and datatypes give each attribute storage, validation and templates (The content model for engineers).
5. All cache files through the cluster file handler. Caches are written through eZClusterFileHandler, so the same code runs on one disk or on shared storage for several web nodes (Scaling and clustering).

Where state lives #

What the architecture does not have #

• No dependency injection container of its own. Classes are found through the class map and settings; singletons such as eZINI::instance() and eZDB::instance() are the norm. When the kernel runs inside Symfony, ezpKernel::hasServiceContainer() and getServiceContainer() give access to Symfony's container.
• Upgrade steps and migrations, from the console. Kernel and extension database updates are upgrade steps that exp:upgrade applies and records; a site's own changes are migrations that exp:migration:migrate runs in order and records in exp_migration (Schema changes and migrations, Migrations).
• No message broker in the kernel. Background work runs as cronjob parts, content jobs and the expqueue extension (Console, cronjobs and background work).
• No Symfony in the kernel. The Symfony platform products embed the kernel through the legacy bridge (Symfony and the legacy bridge).

Related pages #

• The request lifecycle
• Kernel, lib and extensions: the layering
• Architecture for application creators
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.