http://www.divisionlab.com/solvingmagento/n normally includes the names of a controller and its action (command). The path can be first checked for a URL-rewrite, for example, in web applications that use human- or SEO-friendly URLs. In this case the routing information is extracted from a resource, which contains URLs matched to controller and action names. Once the controller is found, the command dispatcher instantiates it and calls the matched action.

Magento also features a front controller. If you take a look into the root folder of your application you find only a handful of *.php files and among them index.php.
In Magento index.php is the entry point for every incoming request. This is ensured by Apache’s module mod_rewrite and rewrite rules in the root folder’s .htaccess file:

These rules mean that unless a physical file or directory can be located, the request will be sent to the index.php file.

However, index.php is not a front controller. Magento’s front controller is implemented in a class that is instantiated in the early stages of the request processing. Before that the index.php instantiates the main Magento hub class, Mage. The application is started with the calling of the Mage::run() function. After loading configuration, establishing a database connection, and performing other common routines, the front controller is launched. The front controller is implemented in class Mage_Core_Controller_Varien_Front. Its centerpiece is the Mage_Core_Controller_Varien_Front::dispatch function, which is responsible for matching a URL and dispatching the request. But first, the front controller has to be initialized.

Gets the current store’s router configuration (under the node stores/default/web/routers, details). By this time Magento has already loaded all the module config XML files (more on extending the Magento router configuration). Once loaded the $routerInfo variable contains an array of two routers: admin and standard. Having this information, the system begins iterating through these routers and collect information from the module configurations, which extend them, by looking up the frontName nodes. This is achieved by calling Mage_Core_Controller_Varien_Router_Standard::collectRouters. The admin router will contain routing configurations for the administration back end part of the website, while the standard will be comprised of configurations for the front end.

Thus, the front controller initialization includes reading the router configuration from the system configuration objects and arranging the module routing extensions into four routers: admin, standard, cms, and default. This means that whatever router rewrites you have specified in your modules are now available to the front controller. The dispatch() function is now ready to go. It does the following:

Checks if the request URL matches the base URL, which is set in the shop configuration. If not, the system performs a redirect to the base URL. The redirect code is set in the configuration node web/url/redirect_to_base and can be null (in which case the further check is not performed), or 301, or 302.

Performs URL rewrites by searching for a URL in the core_url_rewrite table. This is done by function Mage_Core_Model_Url_Rewrite::rewrite. This function loads all entries from table core_url_rewrite that match the path info string (the URI path, the part between the host name and the query string, e.g. if the URL is http://www.test.com/sony-vaio-notebook-pc.html?showID=1 then the path info would be sony-vaio-notebook-pc.html). The found entries contain the target_path (e.g. catalog/product/view/id/144) that is used to locate the controller and action to which the request must be be dispatched. If no match is found, the rewrite function will return false and the router matching will use the original path info. Otherwise, the found target_path will be used as a new path info. It will be amended with a query string, if such was provided with the request.

Processes configuration rewrites. The front controller uses its function rewrite to retrieve configuration nodes under path global/rewrite. If such configuration entries are found, the front controller rewrites the path info property of the request object accordingly.

Finds a router match. As we have established, there are already 4 routers known to the front controller: admin, standard, cms, and default. These will be iterated through to match the controller and action parameters parsed from the URL. The loop, in which it is done, is nested.

The upper loop will iterate until either a request is matched or the loop count exceeds 100. It is done because some routers can be rewritten multiple times. In this case the inner loop will break and fall back to the external loop to match a rewritten request again. The limit of 100 iteration is set to avoid erroneous recursive rewrites, which otherwise would lead to an infinite matching circle. Upon reaching the iteration limit the system throws the “Front controller reached 100 router match iterations” exception.

The inner loop will go through all 4 routers. If a match is found, i.e. there is a valid controller class that has a callable action, the request is dispatched – the request is processed by the found controller. If no match is found in the first 3 routers, the request is transferred to the last, default, router that generates a noRoute output that is a 404 error page.

The matched request is now dispatched. Before outputting the generated HTML (or any other form of output: XML, JSON) the front controller sends a controller_front_send_response_before event. After the response is sent, a controller_front_send_response_after is dispatched.

As you can see the Magento’s front controller encapsulates the request processing from the moment after the application is initialized and until the output is ready to be sent back to the client. The router matching and request dispatching to a controller is a demonstration of a command-based pattern: a command is recognized from the request and executed. You can add new commands (create new controllers) without altering the front controller. Compared to their complexity the front controller is relatively simple, and its tasks are narrow: routing and dispatching.

Readers who read this post also read these:

Symbolic LinksIt is surprising how many people don't know about symbolic links and do not realize how useful they can be. For instance you are running a test server with multiple instances of out shop configured...

Quick Tip: Magento Catalog Price Rules Don’t WorkIn this post you’ll find a list of likely reasons to why your catalog price rules do not have any effect on prices of products they are supposed to control. The problems listed below are most likel...