Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Page Controller is a request-handling pattern in which each logical page has its own controller: either the page itself or a separate object responsible for that page. A Front Controller instead sends requests through one central entry point that dispatches them. The two structures are compatible: a central router can send a request to a page-specific controller.

What is the Page Controller pattern in PHP?

Page Controller organizes request handling around logical pages. A page-specific controller handles the input and request logic for its page, then produces the appropriate response. The controller can be the page itself or a separate object corresponding to it; the pattern does not require one PHP file per page.

For example, an application might have a page-specific handler for a greeting page and another for a goodbye page. Each owns the logic particular to its page. This is a way to organize responsibility, not a required file layout or PHP framework.

How is Page Controller different from Front Controller?

The key difference is where dispatch happens. Page Controller associates handling with individual logical pages. Front Controller centralizes incoming request dispatch in a single entry point. Symfony’s documentation illustrates the latter: requests arrive at one public PHP script, which maps URL paths to page scripts.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Aspect Page Controller Front Controller
Dispatch ownership Each logical page has its own controller, which may be the page or a corresponding object. (Martin Fowler, Page Controller) One public entry point centrally dispatches requests. (Symfony, The Front Controller)
URL-to-code relationship Request handling is associated with a logical page; a particular URL mapping method is not required by the pattern. An explicit route map can associate paths with handlers or page scripts.
Adding a page Add or extend the handler for that logical page. Add the handler or template and maintain the central mapping.
Deployment boundary The pattern alone does not prescribe which PHP files the web server exposes. Internal page scripts can be placed outside the public document root when requests enter through the public script. This is a deployment arrangement, not a complete security guarantee. (Symfony, The Front Controller)

These are different architectural dimensions, not always competing choices. A Front Controller can centralize URL dispatch and then invoke Page Controllers that own page-specific request logic.

A small PHP mental model: central routing to page handlers

In a Front Controller design, think of the public script as a traffic director: it obtains a normalized request path, checks an explicit route map, invokes the matching internal handler or template, and returns a not-found response if no route matches. Symfony’s example uses Request::getPathInfo(), a PHP array map, a Response, and a 404 branch. Its later template example buffers rendered output before placing it in the response.

That public script is not itself the definition of Page Controller. It is the centralized dispatch mechanism. The functions or objects it invokes can still be organized as page-specific controllers.

Symfony’s rendered-output example escapes a query-derived name with htmlspecialchars($name, ENT_QUOTES, 'UTF-8'). That is an output-encoding step in the example; it should not be mistaken for a complete application security strategy.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Why use a single public entry script?

When all incoming requests pass through one public script, the web server can expose that entry point while page scripts and other implementation files remain outside the document root. Symfony demonstrates this structure by moving page PHP files out of the web root. It helps define which scripts are directly reachable over the web, but does not by itself secure the application: request validation, authorization, safe output handling, and other controls still matter.

A historical PHP example: multi-page forms

PEAR’s legacy HTML_QuickForm_Controller documentation uses a PageController for multipage forms such as wizards. In that package-specific example, one script processes requests and selects a page or action using GET or POST parameters; an action switch distinguishes operations such as displaying a page and validating input. The documentation also notes that sessions are needed to pass data between pages in a real multipage form.

This illustrates one historical use of the name in PHP, not a recommendation to adopt the package today. The documentation page was last updated on 16 February 2019, and current maintenance status or PHP compatibility is not established here. See PEAR’s HTML_QuickForm_Controller documentation for the package-specific explanation.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Further reading

Martin Fowler’s Page Controller catalog entry, dated 5 March 2003, identifies the pattern as part of Patterns of Enterprise Application Architecture. Current retail availability is not established here.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

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.