A front controller gives a PHP application one shared entry point instead of letting separate URLs execute separate PHP pages. The web server sends application requests to that entry script, which bootstraps the app and passes the request to routing and application logic. That separation makes shared request setup easier to manage while leaving route selection and page behavior to the router and handlers.
What a front controller does
A front controller is a section of code through which an application’s requests pass. Rather than expose a different PHP script for every URL, the server directs application requests to one PHP file. That file starts the application and hands the request onward; it need not contain the application’s business logic.
A typical request flows like this:
- The web server receives a request and directs it to the application entry point.
- The front controller loads shared setup and passes the request to a router or framework kernel.
- Routing identifies the matching handler and supplies route information.
- The handler produces a response, which the application returns to the client.
This arrangement avoids duplicating common setup across many entry scripts. It does not, by itself, guarantee better security or performance; those depend on the code and server configuration around it.
Front controller, router, kernel, and controller: the difference
- Front controller: The shared entry point that bootstraps the application and hands off the request.
- Router: The component that matches a request, usually by path and possibly other request details, to a route and its parameters.
- Kernel: In a framework such as Symfony, the central component that coordinates the request-to-response lifecycle, including routing and controller execution.
- Controller or handler: The callable selected for a route; it performs the work for that request and returns or helps build a response.
In a very small application, the entry script can do simple path checks itself. For example, Symfony’s fundamentals documentation demonstrates returning a response for a home path, a contact path, and an unknown path. As routes and shared behaviors grow, a router and framework kernel make the responsibilities easier to separate than an expanding collection of conditionals in index.php. Symfony’s fundamentals example returns a not-found response when no path matches.
#1 Best Overall
How Symfony handles a web request
In the Symfony skeleton, public/index.php is the first PHP script run for a web request. It creates the Kernel, asks it to handle the request, and returns the resulting response. The entry point stays focused on setup and handoff; it does not need to contain each route’s application behavior. Symfony’s setup documentation describes this entry-point role.
The HttpKernel lifecycle adds structure around that handoff. Request listeners can initialize data or provide an early response. Routing can attach the matched controller and route parameters to request attributes. If no listener has already supplied a response, a controller resolver finds the callable and the controller runs. Later kernel events can modify or finalize the response, while exception handling can convert failures into responses. Exact mechanics depend on the framework configuration and application. Symfony’s HttpKernel documentation describes the lifecycle and its extension points.
Rank #2
The practical distinction is that the front controller is where the web request enters, while the kernel coordinates what happens after entry. The router decides which handler applies; the controller handles that application-specific work.
When a minimal dispatcher is enough—and when to use a kernel
| Consideration | Small hand-written dispatcher | Framework-backed kernel |
|---|---|---|
| Route growth | Simple to inspect for a tiny set of paths; a large set of conditionals becomes harder to maintain. | Uses routing and a defined request lifecycle as application behavior grows. |
| Shared concerns | Common setup and checks must be organized deliberately in the small application. | Provides lifecycle extension points for request handling, errors, and response processing. |
| Response handling | Must establish a consistent response approach as the app expands. | Coordinates a request-to-response process around framework request and response objects. |
| Dispatch testing | Can be straightforward for a tiny dispatcher, but tight coupling between path checks and behavior makes isolation harder. | Routing, kernel lifecycle, and handlers have clearer boundaries, though framework dependencies add operational complexity. |
For a small exercise or narrowly scoped application, direct path checks can be clear and adequate. If route matching, error handling, and other shared request concerns are accumulating, use a routing component or framework rather than turning the front controller into the whole application. Symfony describes its kernel as flexible enough to support a full-stack framework or an advanced CMS, while its fundamentals guide also illustrates a minimal dispatcher.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Keep the public entry point at the deployment boundary
Where possible, set the web server’s document root to the application’s public directory. Keep configuration, source code, and other non-public files outside the served tree so they are not directly exposed as web files. Configure server rewrites to send application paths to public/index.php; rewrite syntax differs by web server, so follow instructions for the server actually used. The PHP manual’s Yaf quick start demonstrates this public-directory structure and routing requests to the entry point.
Use PHP’s built-in server for local development only
PHP’s built-in web server can be useful for local development and controlled demonstrations, but the PHP manual says it is not full-featured and should not be used on a public network. Its router-script feature can run a script for each request; returning false allows the server to serve a requested static resource as-is. This convenience does not make the built-in server a production deployment choice. See the PHP manual’s built-in web server documentation.
Quick Recap
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
