Magento's preDispatch Observer

One of the decisions that always seems to arise when adding functionality to a Magento website is what the best strategy is for doing so. Should you override the controller or function, edit it in place, or use an observer to listen for a particular event to occur.

It just so happens that if you want to make sure that you have some sort of validation logic that runs before a particular controller action is executed, the easiest way to implement it is via a preDispatch observer. The other aspect of preDispatch controllers is that they can be configured to listen only for preDispatch events from a particular module, or they can listen for preDispatch events from every module, allowing you to add some password expiration policies to the adminhtml side of your website, for example.

To get started, you will need to update your module’s config.xml file to include a section like is shown below:

<global>
    <events>
        <controller_action_predispatch_routename_product_view>
            <observers>
                <yourmodule_capcpv>
                    <class>YourCompany_YourModule_Model_Observer</class>
                    <method>catalogProductViewPredispatch</method>
                </yourmodule_capcpv>
            </observers>
        </controller_action_predispatch_routename_product_view>
    </events>
</global>

The important thing to notice above is that this will only listen to preDispatch events for the /routename/product/view controller address. In addition, it will call the catalogProductViewPreDispatch function on the YourCompany_YourModule_Model_Observer class. This also requires that you have a file named Observer.php in the app/code/local/YourCompany/YourModule/Model folder.

Once you have this setup, you are able to perform any action you would like to in the observer function. One thing to note is that if you would like to make sure that the /routename/product/view controller action is never executed, you can simply make a call to exit() within the catalogProductViewPredispatch function. It is a messy and inelegant way to accomplish this, but it works without issue.

Related Posts

Apr 24, 2014
2 minutes

Optimize Magento Time To First Byte

When looking at the performance of your site, waterfall charts are one of the first places you should investigate. The first thing that is represented on these charts is that the HTML for the website is the first resource that is downloaded every time.

As a result of being the first resource downloaded every time, this is the logical first place to look to improve the performance of your Magento website. There are a few ways to make sure that the page downloads more quickly, and they all involve making sure that the file size is as small as possible.

Jun 18, 2014
3 minutes

Orphaned Attribute Data in Magento

Its always entertaining to look at the source of an application that originates from outside your organization. It frequently highlights ways of using technology I was not familiar with beforehand, and sometimes leaves me shaking my head in disgust. I initially started looking at a relatively new third-party module thinking that I would find some sort of major bug that was causing the issues the site was experiencing, but was surprised to find that was not the case.

Apr 14, 2014
One minute

Varnish and Magento Performance Mystery

One of the things that you think you will solve when you implement a Varnish caching server in front of a Magento website is performance problems. However, this is not necessarily the case.

When I set Varnish up to cache content in front of my Magento website, I get what seems to be much improved performance. If I run a few tests in the developer tools of Chrome, it seems that the waterfall chart makes sense and the data is loaded appropriately and in a timely manner with the main HTML being downloaded in about 300ms.