Rule number one in Magento extension development

3 Comments 11th DEC 2009 | Posted by Branko Ajzele in Magento

Rule number one in Magento extension development

Recently one of our clients noticed some buggy behavior around its tier pricing. Clients demands were such that he needed an extra bit more functionality on top of the existing tier pricing feature, which is understandable. To comply to the request we went trough the discussion of either building such features ourself or reusing one of the existing extensions free/commercial.

Finally we decided to go with the existing extension. I will not name the specific extension we used, as I do not wish to trash other people work.

Few weeks after the site went live and numerous successful orders were made, client noticed this buggy behavior that miscalculates the final tier price on the Bundle product type. This is a big issue when you look at it, cause it reflects on the sale process and imposes loss for the client.

Interesting thing was that this extension comes with the following support note: “Our services include 30-day moneyback, 6 months of free support and bug fixing since module purchase date.”.

Thus, my initial thought was: “OK, lets not waste my and our client time on trying to debug this, let the extension developers try to resolve this.”.

After contacting the extension support here is the answer we got: “Please disable the module and re-save your bundle product to restore correct discount (10%). The module does not work with bundle products, so please let me know if you need a refund. Best regards.”.

So, my question is: “How do we ‘re-save’ all products in lets say shop that might have 20-30 000 products?”. -Not so easily, because what if its not just matter of re-saving, what if its a matter of re-assigning certain values to certain input fields as well.

Luckily in this particular situation, shop has “only” few bundle products that should not be hard to re-edit and re-save manually.

As I said, I will not go into the details of which extension is it or which company is it. My intention is to set up a rule number one that each of Magento extension developers should follow:

Your extension, no matter how good or bad, how big or small it is… it should always be uninstallable without any consequence to the later system stability and functionality!“.

We are not talking about some blog system here, we are talking about eCommerce business, web shops… money. Thus, please be careful when you code your extension, cause removing it one day can cost “significant” amount of money.

cc image credit

If you like what you read, please share it.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Yahoo! Bookmarks
  • Reddit
  • Technorati
  • Twitter
  • StumbleUpon
  • LinkedIn
  • Netvibes
  • NewsVine
  • Sphinn
  • Tumblr
  • Posterous

To post code in comments, place your code inside [code] and [/code] tags.

There are 3 comments (Add Yours +)

  • I completely agree with you. I’ve been in similar situation couple of times this year… well… probably even worse one as one of the extensions was free, so I had to fix it myself.
    Everyone has to remember that it’s quite possible to break his store or even mess up DB (mine assploded 2 weeks after launch) when mixing various 3rd party plugins, so test… test… test (crying like a baby or smashing something also helps;) !

  • I think extension developers should also state known bugs as a warning on product download pages on or Magento-Connect. If it wasn’t known before, it is now… and there is still no warning there.

  • I also completely agree. Extension developers must also give tutorials for uninstallation.

Leave a Comment

Please wrap all source codes with [code][/code] tags.
Magento Design and Development | Magento SEO | iPhone Application Development Web Application Development with ZEND | WordPress Ecommerce | WordPress development
Sitemap

Inchoo - webappsolutions | 2009