tags:

views:

62

answers:

1

What are the best practices when creating a Magento extension to avoid conflicts with other extensions that get loaded to a store. I know how to code with the override method, observer methods and the details behind how to do that the preferred way. That still doesn't stop you from having conflicts with other modules out there and upgrades.

Alan Storm, if you read this, I also have read your recent post about overrides and upgradability. Is that the best way to think for this type of situation as well? I also see extensions and articles people have created to allow multiple classes extend the same class.

+6  A: 

The best possible way to avoid this problem is to use the Observer pattern built into Magento whenever possible. It's not in nearly enough places, but when you have the option, using it will let you play nicely even with other poorly behaved extensions.

Nextly, try to override the minimum number of classes. It sounds obvious, but there have been times when I've thought it was necessary to override every one of the shipping calculator classes (the code was easy, but needed to be repeated). With some more work, I was instead able to override a single class and save myself some maintenance headache to boot.

When you do this, you may still run into conflicfts with other extensions overriding the same classes you are. This is unfortunately not a solved problem in Magento, and there isn't a great way to resolve it other than contacting the person in question and hashing out a solution.

Finally, to the problem of upgradeability, a common problem I see in people's code is that they, without thinking, override an entire function when it isn't necessary. So you get this:

function doSomethingUseful() {
    // ...100 lines of parent code...
    unset($result['badKey']);
    // ...100 lines of parent code...

    return $result;
}

When you go to upgrade a site, that's 200 more lines of code likely to cause a bug. Bad times! Instead, something like this often works (and is an easy improvement):

function doSomethingUseful() {
    $result = parent::doSomethingUseful();
    unset($result['badKey']);
    return $result;
}

It's faster, it's more readable, it's less error prone, everyone wins!

Hope that helps!

Thanks, Joe

Joseph Mastey
I can't upvote this answer enough. Observer pattern rocks (by far the most powerful and flexible pattern), and `parent::` is sadly underused. Great advice, should be on the front page of the Magento wiki. Unfortunately, sometimes the Mage core doesn't allow use of parent:: because there are commands that don't return control to the calling object, but these are rare.
Jonathan Day
Thanks a lot Joseph, I use the observer pattern, but like you said a lot of times I don't have an event to use, seems weird because there are so many. You kind of reinforced what I was already following and I am sure people will find this post very usefull.
dan.codes
don't forget the generic `<model>_save_before`, `<model>_save_after`, `<model>_load_after`, `controller_action_predispatch`, etc Events that you can Observe and filter to find a more specific Event if you need. These fill in a lot of the gaps where there appear to be missing Events.
Jonathan Day
That's a really good point Jonathan. There are scads of events that get called when saving/loading objects, as well as when every action is called.
Joseph Mastey