Unlike good old WordPress that “every kid in the block” knows how to create a plugin for, Magento is a whole new system. It requires extensive knowledge of OOP, ORM’s, MVC, and few other stuff. This is why not “every kid in the block” can write a module for Magento, and this is why I love it. However, unlike WordPress, Drupal and other community driven systems out there who keep in mind backward compatibility things with Magento things are a bit different.
One of the things that caught my eye and made me wonder about the consequences is the Observer and override functionality that probably most of the serious custom made Magento modules will utilize. Utilizing Observers enables you to observe and execute some action inside the “customer work flow” or even some admin stuff. Such functionality is heavily known is systems like WordPress and it’s called “hooks”. Besides hooking, another useful an very powerful feature which is actually related more to the OOP concept itself is the overriding. Personally i find the combination of observers and overrides to be the coolest and most powerful stuff in Magento module development.
So where is the issue? As of time of this writing, the latest Magento version is 1.3.1. Let’s look at the previous “major” release prior to that one, version 1.2.1.2. Here is a prepareForCart method signature from app/code/core/Mage/Catalog/Model/Product/Type/Abstract.php (line 239, Magento version 1.2.1.2):
public function prepareForCart(Varien_Object $buyRequest)
And here is the same method signature in Magento version 1.3.1
public function prepareForCart(Varien_Object $buyRequest, $product = null)
Notice the difference? Although this might not look like “that big of a deal” suppose you had implemented override functionality like
|
1
2
3
4
5
6
7
8
9
|
public function prepareForCart(Varien_Object $buyRequest){parent::prepareForCart($buyRequest);$product = $this->getProduct();if ($buyRequest->getcpid()) {$product->addCustomOption('cpid', $buyRequest->getcpid());}return array($product);} |
In the above code, we override the prepareForCart method to to some custom stuff for us. This peace of code would work perfectly fine in version 1.2.1.2, but when client decides to upgrade the shop to 1.3.1 or newer he would get the error like
Strict Notice: Declaration of SomeClassOfMine::prepareForCart() should be compatible with that of Mage_Catalog_Model_Product_Type_Abstract::prepareForCart() in /app/code/community/MyCompany/MyModule/Catalog/Model/Product/Type/Simple.php on line 3
The issue itself is resolved by adding missing parameters to function we are overriding like
|
1
2
3
4
5
6
7
8
9
|
public function prepareForCart(Varien_Object $buyRequest, $product = null){parent::prepareForCart($buyRequest, $product);//$product = $this->getProduct();if ($buyRequest->getcpid()) {$product->addCustomOption('cpid', $buyRequest->getcpid());}return array($product);} |
To me, stuff like this is a serious downside towards building advanced modules. Changing core files and core functionality can have serious impact on custom made modules each Magento upgrade. Therefore, one should keep an eye open on what modules he will throw into the shop. Personally I consider online stores very serious and have strong feelings about each store owner having somewhat of dedicated developer that will be in charge even for stuff like adding new modules.
Just consider the financial loss for a store owner of any more serious web shop if he decides to download the and install module himself just to realize that for incompatibility reasons this new module made his shop fully nonfunctional.
Source: inchoo.net
