Categories


Archives


Recent Posts


Categories


Magento Startup Events

astorm

Frustrated by Magento? Then you’ll love Commerce Bug, the must have debugging extension for anyone using Magento. Whether you’re just starting out or you’re a seasoned pro, Commerce Bug will save you and your team hours everyday. Grab a copy and start working with Magento instead of against it.

Updated for Magento 2! No Frills Magento Layout is the only Magento front end book you'll ever need. Get your copy today!

There’s no official Magento “startup” event, but the first “safe” event to listen for in Magento is probably the controller_front_init_before event. I say probably, because there are a few events that fire prior to this one. In a stock installation of Magento 1.7 these events are

resource_get_tablename    
core_collection_abstract_load_before
core_collection_abstract_load_after

These are events that fire before Magento’s configuration is entirely loaded and the store object is entirely initialized. Specifically, they fire in the Mage_Core_Model_App’s _initStores method. The resource_get_tablename event comes from initializing the website collection,

#File: app/code/core/Mage/Core/Model/App.php
$websiteCollection = Mage::getModel('core/website')->getCollection()
        ->initCache($this->getCache(), 'app', array(Mage_Core_Model_Website::CACHE_TAG))
        ->setLoadDefault(true);

which uses plain custom SQL called directly through the resource method to load its data.

The pair of core_collection_abstract_load events come from performing a count on the loaded store collection.

#File: app/code/core/Mage/Core/Model/App.php
if ($this->_isSingleStoreAllowed) {
    $this->_isSingleStore = $storeCollection->count() < 3;
}

While you can listen for these events, if you attempt to use any Magento method that relies on configuration data unexpected things will happen. Since Magento hasn’t loaded the configuration yet at best you’ll get invalid data, at worse you’ll get an error. Any attempts to initialize a store object in these three early stage events will result in a 404.

Additionally, because these events fire numerous times you’ll want to take care using them in your own Magento modules. Even if the resource_get_tablename event you want fires after Magento’s pre-configuration event, your code will still run in this pre-configuration state. Make sure your observer method has appropriate guard clause to prevent weird things from happening. The best way I’ve found to do this is something like the following

class Packagename_Modulename_Model_Observer
{
    public function observerMethod($observer)
    {
        $is_safe = true;
        try
        {
            $store = Mage::app()->getSafeStore();
        }
        catch(Exception $e)
        {
            $is_safe = false;
        }
        if(!$is_safe)
        {
            return;
        }     

        //if we're still here, we could initialize store object
        //and should be well into router initialization
    }

}

If you can think of something better please let me know.

Finally, if you understand the risks, understand that Magento may change their store loading at some point and break this, and really want to hook into the first event Magento fires, setup an observer for the resource_get_tablename method that looks something like this

class Packagename_Modulename_Model_Observer
{
    static protected $_hasRun = false;
    public function setup()
    {
        if(Packagename_Modulename_Model_Observer::$_hasRun)
        {
            return;
        }
        Packagename_Modulename_Model_Observer::$_hasRun = true;
        //your code here
    }
}

This uses a static PHP property to ensure this observer code only runs once.

Copyright © Alana Storm 1975 – 2023 All Rights Reserved

Originally Posted: 27th September 2012

email hidden; JavaScript is required