Application Lifecycle

Relevant source files

The following files were used as context for generating this wiki page:

• README.md
• source/concepts/appstarter.rst
• source/general/routing.rst
• source/general/filters.rst
• source/general/controllers.rst
• source/outgoing/responses.rst

The CodeIgniter 4 application lifecycle describes the sequence of events that occur from the moment an HTTP request is received until a response is sent back to the client. Understanding this flow is crucial for developers to effectively use routing, filters, controllers, and other framework components. The entire process is designed to be light, fast, and flexible.

Sources: README.md, source/concepts/appstarter.rst

This document outlines the key stages of the request lifecycle, from initial bootstrapping to the final response output. The core of the lifecycle is managed by the CodeIgniter\CodeIgniter class, which orchestrates the various components to handle an incoming request.

Sources: source/concepts/appstarter.rst

High-Level Application Flow

The following diagram provides a simplified overview of the entire application request lifecycle.

This flowchart shows the linear progression from the initial request through bootstrapping, routing, filters, controller execution, and finally sending the response.

Sources: source/concepts/appstarter.rst, source/general/routing.rst, source/general/filters.rst

Detailed Lifecycle Stages

1. Bootstrap

The application is initiated by the front-controller, public/index.php. This script is the single point of entry for all requests. Its primary responsibilities are:

1. Defining essential path constants (FCPATH, ROOTPATH, etc.).
2. Loading the main bootstrap file, system/bootstrap.php.
3. Instantiating the main application class, CodeIgniter\CodeIgniter.
4. Calling the run() method on the application instance to start processing the request.

The bootstrap process sets up error handling, loads helper functions, initializes the autoloader, and prepares the core services required by the application.

Sources: source/concepts/appstarter.rst

2. Routing

Once the application is bootstrapped, the run() method first determines the request's destination via the routing engine.

• The Router service inspects the incoming URI and HTTP method.
• It compares the request against the routes defined in app/Config/Routes.php.
• If a match is found, the router determines the corresponding controller class and method that should handle the request.
• If no route matches, a PageNotFoundException is thrown.

Sources: source/general/routing.rst

3. Filters

Filters provide a mechanism to execute code before and/or after a controller runs. They are configured in app/Config/Filters.php.

Before Filters

• These filters run after routing has determined the controller but before the controller method is executed.
• They are ideal for tasks like authentication, CSRF protection, or rate limiting.
• A "before" filter can stop controller execution by returning a Response object, which is then sent directly to the client.

After Filters

• These filters run after the controller has successfully executed and generated a Response object.
• They can modify the final response, such as compressing output or adding specific headers.

The sequence diagram below illustrates where filters intercept the request-response flow.

This diagram shows how a "before" filter can short-circuit the request, and how an "after" filter processes the response before it is sent.

Sources: source/general/filters.rst

4. Controller Execution

If the "before" filters do not halt execution, the framework proceeds to run the controller.

1. The framework instantiates the controller class determined by the router.
2. The specified method within the controller is called. Any parameters from the URI are passed to the method.
3. The controller performs the main application logic, such as retrieving data from a model, processing input, and loading views.
4. The controller method must return a Response instance, a view, or a string. The framework automatically converts non-Response return types into a Response object.

Sources: source/general/controllers.rst

5. Response Generation

The final stage of the lifecycle is to prepare and send the HTTP response.

• The CodeIgniter application class takes the Response object returned by the controller.
• It passes this object through any applicable "after" filters.
• Finally, the send() method of the Response object is called. This method sends the status code, headers, and body content to the client's browser.

Sources: source/outgoing/responses.rst

Key Configuration Files

The application lifecycle is heavily influenced by configuration files located in the app/Config/ directory.

Stage	Primary Configuration File	Purpose
Bootstrap	app/Config/Paths.php	Defines directory paths for the application, system, and public folders.
Routing	app/Config/Routes.php	Defines the mapping of URIs to controllers and methods.
Filtering	app/Config/Filters.php	Configures filter aliases and rules for which filters run on which routes.
Controller	app/Controllers/BaseController.php	Often used as a base class to load helpers and components for all other controllers.
Response	app/Config/App.php	Contains base URL and other settings that can affect response generation.

Sources: source/concepts/appstarter.rst, source/general/routing.rst, source/general/filters.rst

Summary

The CodeIgniter 4 application lifecycle is a well-defined and logical process. It begins with a single entry point, bootstraps the necessary resources, uses a powerful routing engine to direct traffic, allows for request and response interception via filters, executes business logic in controllers, and finally sends a formatted response back to the user. This structured flow provides developers with clear extension points for building robust and maintainable web applications.

Sources: source/concepts/appstarter.rst, source/outgoing/responses.rst