How to analyse 3rd party Magento extension

Every now and then client hires us to do a site assessment for his existing Magento powered web shop. One of the reasons for this is the feeling of web store getting slower and more bloated with each new extension or modification they make on Magento.

Based on my experience, I will describe an approach we at Inchoo take for analysing 3rd party Magento extension.

Starting point is always the extensions config.xml file, for example /app/code/community/Company/Extension/etc/config.xml file.

The prime goal of giving the client an assessment, when it comes to 3rd party extensions is to check for possible performance killers and possibly dangerous core logic change. For example, you might rethink the new implementation for the extension that rewrites the Mage_Catalog_Product just to affect the attribute value before save.

With that in mind here is the list of things we prioritize during our sweep of the extension:

• model/class/controller rewrites
• events/observers
• CRON jobs
• layout updates

When it comes to rewrites you should at least take a look into every defined model/class/controller rewrite within your config.xml file. For example, if someone rewrites a block class Mage_Catalog_Block_Product, and its getProduct() method just to add some extra info to the product object he might do it like this:

class Company_Extension_Block_Product extends Mage_Catalog_Block_Product
{
    public function getProduct()
    {
        if (!$this->getData('product') instanceof Mage_Catalog_Model_Product) {
            if ($this->getData('product')->getProductId()) {
                $productId = $this->getData('product')->getProductId();
            }
            if ($productId) {
                $product = Mage::getModel('catalog/product')->load($productId);
                if ($product) {
 
                	$product->setCustomVar1('My value 1');
                	$product->setCustomVar2('My value 2');
 
                    $this->setProduct($product);
                }
            }
        }
        return $this->getData('product');
    }

While the more proper way in this case would be something like this:

class Company_Extension_Block_Product extends Mage_Catalog_Block_Product
{
    public function getProduct()
    {
    	$product = parent::getProduct();
 
    	$product->setCustomVar1('My value 1');
    	$product->setCustomVar2('My value 2');
    	$this->setProduct($product);
 
    	return $this->getData('product');
    }

This might not be the best example, however its important to understand what the class/method you are rewriting does and try to call its logic (if possible) via parent::someMethod(), then execute yours. As I said, the example above might not be the best example, but once you start paying attention to these kind of things you will soon understand whats safe to rewrite and whats not.

Custom defined event observers can be extremely dangerous. I usually tend to break these in two types of events: (1) events before some entity state change/save, (2) events after some entity state change/save. I consider *_save_before events more dangerous than *_save_after events, same goes for *_load_before and *_load_after, as well as for *_predispatch and *_postdispatch events. For example, my five years experience has shown me that usually, although not necessarily, your event observing logic would be safer if observing customer_address_save_after instead of customer_address_save_before. This is due to the usual case where Magento logic triggering customer_address_save_after event will get executed regardless of your observer logic executing successfully or not executing due to the error in your code. When 3rd party extension implements observer for some *_save_before, *_load_before, *_predispatch events you should really pay special attention to it and take a look at the code within those observers and try to understand whats going on.

CRON jobs should also be given a special attention when analysing 3rd party extension for two reasons. First, you will be surprised how many Magento merchants does not have system CRON set up to trigger Magento’s root cron.php file. What this means is that even though this 3rd party extension might define some crucial business logic that needs to be triggered periodically by CRON, it will never be executed because you do not have system CRON set up.

Second, when it comes to CRON jobs defined in config.xml you should really take a look at the code that gets executed when job is triggered. Sometimes developers put resource intensive code (such as iterate and update 5000 products) in the CRON job thinking “what a hell, it runs in the background”. Surely this thinking is not justified as it can introduce serious load on your database server, etc.

Finally, the layout updates. Layout updates are one of those things which I consider “read only change”. What this means is that usually, you should not get any data corruption or something that serious just because some layout update killed certain Magento core blocks on the frontend. However it can be pretty frustrating having your new 3rd party extension installed just to find out that your category navigation menu disappeared on the 2-column-right layout.

Overall, these are the things we pay special attention during our site assessment, that is 3rd party extension analysis. This is by no means a complete list of things we check, just the most important once. Hope it helps.