Request lifecycle

A request passes through the entry point, route resolution and the templates or handler needed to produce a response.

Entry point

The web server's rewrite rules send application requests to index.php. It establishes the request path and framework search paths, loads environment and request support, applies trusted-proxy handling, registers error and statistics handling, escapes request input and calls run_uri().

Route resolution

The runtime checks a matching subdomain folder before the ordinary application routes. Static templates are resolved directly. Dynamic routes use the router and route.inc, which validates matched values and calls router_accept() or router_deny(). A static route must not have route.inc.

If no code-owned route matches, the optional managed-pages module can resolve a configured data-backed page. Otherwise the runtime serves the not-found response.

Page composition

An HTML route normally calls [#html#]. The shared HTML template loads site settings, determines language and resolves page metadata. It renders the header, main and footer with the page's configured templates and includes assets and authorized editing controls.

Templates invoke smaller templates and shortcodes. Libraries are discovered when called. Resource access uses the framework data layer, with indexes and caching where configured. Request handling also includes shared support; saying that a request executes only its route would omit that work.

Other responses

API and text routes can produce JSON or text instead of composing an HTML page. Authorization is still required before protected operations or data access. The REST API reference describes the resource interface.