Understanding Magento Requests With Commerce Bug

One common theme I’ve seen with developers new to Magento is not knowing where to start. Magento’s default index.php bootstrap and Mage application class offer few surface clues on how a developer should start working with the system.

Even if a developer is already familiar with Model View Controller (MVC) software architecture, they’re faced with 44 different controllers folders, and 10 additional Controller folders. Unlike traditional rails inspired PHP MCV frameworks, there’s little clue as to how a particular URL is routed to a specific controller file.

Even if a developer starts to piece together the complicated rules through trial, error, and the internet, you’re faced with different rules for different sections of the application. Off the top of my head there’s

1. Default frontend routing

2. Default adminhtml routing

3. A config.xml based rewrite system (depreciated, but still in use)

4. A Magento database/model based rewrite system

5. Custom configured frontNames from 3rd party modules

6. Custom routing via the controller_front_init_routers event

A controller file is the main entry point for a web application. For day to day programming work it’s your main function. It’s where any new feature is born, and where the dissection of existing functionality begins.

While it’s important to lean how a hello world controller works, or how to share a route with a Magento core module, when a developer is just starting out they want to see the basic application flow right away. Spending time creating arcane configurations you can only understand after working through a few projects isn’t a priority, and isn’t the most effective use of your time.

Even for veteran developers (or at least, this veteran developer), Magento’s routing system has too many code paths to keep in your head. Sometimes it’s worse for a veteran, because you come to unconsciously expect standard behavior, but when you’re working on that offshore project, (the one you begged your bosses not to take on), a URL routes somewhere completely unexpected.

This is where Commerce Bug’s Request Tab swoops in to save the day.

The Request Tab

The Request Tab contains information about the request that just happened. For example, if you open a category page

http://store.example.com/electronics/cell-phones.html

you’ll see something like this

The first thing to notice about this tab is the “Controller Class Name” column. This gives you the name of the class, and its location on the file system. (Mage_Catalog_CategoryController)

Instantly, and without looking at single line of configuration, we know where Magento is routing this request. If we open the controller class file, we see it contains three methods

#File: app/code/core/Mage/Catalog/controllers/CategoryController.php
...
protected function _initCatagory()
protected function _applyCustomDesignSettings($category, $update)
public function viewAction()
...

If we’re new to Magento, we can’t be sure which of these methods is the main entry point we’re looking for. If we refer back to Commerce Bug

we can see the “Action Name” is view. This means the action method will be viewAction. Magento generates an action method by appending the string Action to the action name. We can test this by adding some temporary var_dump debugging code to the top of the method

#File: app/code/core/Mage/Catalog/controllers/CategoryController.php
public function viewAction()
{
    var_dump(__METHOD__);
    ...
}

Reload with the above in place, and the top of your page will look like this

As you can see, the var_dumped text is on the top of our screen. We’ve found the main entry point for this page, in this system, and can start tracing system output. What might take a new developer anywhere from a few hours to an entire work day, Commerce Bug does instantly.

Finding ID Parameters

Another common problem developers face with Magento URLs is finding the true paths and parameters when a rewrite is in play. Consider the URL that brought us to this page

http://store.example.com/electronics/cell-phones.html

This may be a category page, but is the category electronics or cell-phones? What’s the category’s ID in the system? Are we sure it’s a category page? Because so many online retail businesses rely strictly on web traffic to drive sales, the “Google friendly” URLs are necessary, but they often obscure what’s going on with the system.

Commerce Bug solves this with the the Path Info column

As you can see, Commerce Bug lists out the “real” path to this page

catalog/category/view/id/449

Meaning we could load the non-friendly URL at

http://store.example.com/index.php/catalog/category/view/id/449

If you try loading that exact URL in your system, you’ll probably get a 404 page. Why? Because in your system the category with an ID of 449 might not exist, or might be a different category. (Cell Phones are typically 8 in the sample data).

This demonstrates the need for Commerce Bug — it tells you exactly what a system is doing regardless of how it’s configured. No mater how crazy those other developers were, you’ll be able to look at a system and know exactly what’s going on.

Finding CMS Pages

The final feature we’ll discuss today is CMS pages. Let’s load the about us page

http://store.example.com/about-magento-demo-store
http://store.example.com/about-magento-demo-store.html

About once a week I’ll get an email like

Hello kind sir. Please help me to gain learning on where Mage keep about-magento-demo-store.html file. Is not on system????

(Pro Tip: If there’s an even number of question marks I’ll answer the question, but I’ll ignore it if there’s an odd number)

As you may already know, Magento has a System Admin section for managing content pages. If we take a look at Commerce Bug’s Request Tab for the about-magento-demo-store page

we’ll find enough information to let us know this is a CMS page as well as the database ID of that page.

First, the Controller Class Name column (Mage_Cms_PageController) and Module Name column (cms) both reveal this request was handled as a CMS page. This save us the fruitless search for a Magento module with a frontName of AboutMagentoDemoStore, and saves us the time consuming folly of tracing routing manually.

Secondly, the CMS Page ID column is set to 3. This tells us the cms_page_id value for the cms/page model, allowing us to quickly find this page in the database, as well as quickly write some code to instantiate a cms/page model

$page = Mage::getModel('cms/page')->load('3');
var_dump($page->getData());

Without having to do any guess work we know where to find this page in the system. Commerce Bug handles all the mental overhead of working with Magento, and lets your concentrate on your job.

Wrap Up

PHP web application architecture has come a long way from the single HTML page with embedded scripts. Regardless of that, the old thought pattern of

This URL equates to this file

is still how most of us think about web applications. Commerce Bug’s Request Tab cuts through the complexity of configurable routing and allows developers to keep this natural mental model. Knowing where to start is your first step into a larger world. Get your copy of Commerce Bug today and start working with Magento instead of against it.