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

Mar 26, 2014
3 minutes

Magento FrontName Naming and SSL/HTTPS

One of the things that has always been an issue for sites that are based on Magento is that they are slow. Well, to be fair, sites using Magento Enterprise Edition that take advantage of the built-in full-page caching functionality seem to have decent page load times. One way to take care of this slow load time issue is to utilize a third-party full-page caching solution such as what Varnish provides.

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.

Mar 25, 2014
2 minutes

Magento Cache with Cache Disabled

One of the things that I find quite annoying with a web platform is when you configure it to do one thing, and it does something different. Magento is an eCommerce software platform that many of the leading eCommerce websites use for their web stores.

Magento

Magento comes in two different flavors, a paid enterprise edition as well as a open-source community edition. The enterprise edition allows you to utilize the built-in full-page caching mechanism, while the community edition does not include a full-page caching solution.