The way I see it, there are two type of extensions for Magento (or even any other eCommerce solution):

1. Community Free/Commercial extensions
2. Custom extensions

Community Free/Commercial extensions would be all those extensions that you can either freely download/install trough various websites or official Magento connect or purchase from the developer if they are commercial.

Custom extensions are those which result from custom development work by some freelance developer or development team, specific to project. Usually they tend to be non-general, in terms of not usable on wider range of other Magento projects as they fulfil specific client shop need.

If you ask me, there is a serious “issue” with a way how most of “(1) Community Free/Commercial extensions” extensions are developed. More precisely how they handle the view files in Magento.

Let me give you a simple example, a “Tweet this button”. Even an experienced frontend Magento developer will tell you that most likely he will just open the appropriate view file from theme and copy-paste the twitter button HTML/JS code into it. By “appropriate” we are referring to a view file which renders on a page position where we would like to see our twitter button.

To be a bit more precise in or example, let’s say we need to add this twitter button on the “Product view page”, right under the default “Be the first to review this product” text. Your average (or even experienced frontend developer) would most likely just open the “app/design/frontend/base/default/template/review/helper/summary.phtml” file and copy pasted twitter button code implementation at the very bottom of the file, save it and you are done.

Advanced frontend developer would most likely do one of the two things:

1. Create a new view file somewhere in the theme folder, add the appropriate block entry into the layout xml file, then open the “app/design/frontend/base/default/template/review/helper/summary.phtml” and just add something like “echo $this->getChildHtml(‘twitter_button’)”.
2. Create a static block inside the Magento admin, where he would copy pasted button code, then simply render the content of that static block in the “app/design/frontend/base/default/template/review/helper/summary.phtml” file.
3. Create extension that has it’s own block class, that is set to use special view file, that uses special entry on one of our layout files, that again uses “echo $this->getChildHtml(‘twitter_button’)”.

In my 2 years practice, solution (1) seems like most likely as you just want to get the job than, and you want to do it as fast as possible. And this is OK, if we are talking about environment where you are paid as a developer to implement design as this can be considered, design specific functionality, or custom developer/implemented specifically for this project so no need to do it as extension that will be redistributed later.

Now, there are certainly other approaches one can take besides these 3. However, out of these 3 I would say that the third one presents the biggest challenge since it talks about the “extension development”.

As a backend developer, I am most disappointed with the way how most extensions tend to use existing theme/view/block files to “dump” their content. For the 3rd example above, your twitter extension, no matter how cool, uses “app/design/frontend/base/default/template/review/helper/summary.phtml” file. Even doe this use is minimal, in terms of just one extra line that says “echo $this->getChildHtml(‘twitter_button’)” it is still an issue.

Why is it an issue? It’s just one file? Well, what happens if John Doe writes another cool Magento extension that adds “Google Buzz” on the same place. And the author of that extension decided to use the same “app/design/frontend/base/default/template/review/helper/summary.phtml” file to output its content. Even if his usage is minimal, you now have 2 extensions that use the same view file, summary.phtml. Basically, you now have an issue.

This issue is specially expressed with the “color switcher”, “photo zoom”, or similar type extensions that poke around “Product View Page” trying to add all sort of fancy effects or functionality. And most of them do that by usig “product.view” or “media.phtml” file. So, if you are not careful you can easily screw up your store with installing 2-3 “similar” extensions as they might use same files which then overwrite each other functionality as you install them.

Ok, I see the issue, now what? Well, not sure what “great” advice to give you. I would say that for extension developers it all comes down to few simple questions:

1. How destructive you want to be with your extension?
2. What happens when I remove it (any sql issues, any layout issues, any view file issues)?
3. What happens if someone else installs the “similar” extension?
4. What happens when I do “”System > Configuration > Advanced > Advanced > Disable Modules Output” =>Disable”?
5. What happens and how will you handle the scenario where others want to “interact” with your extension (do you dispatch any events)?

Sadly, at the moment (referring to today’s date 26/11/2010), high number of Magento extension I saw (even some pretty expensive) fail on these questions (saying this figuratively of course, not that I actually interviewed the developers).

What can we do then do code Magento extensions more unobtrusively? Well, you can start by studying the event/observers system. When it comes to Magento there all lot of options you can try out. Images below show what you can do by “observing” the “core_block_abstract_to_html_after” event.

click to see img1, click to see img2, click to see img3, click to see img4, click to see img5

Surely there are lot of sideby quastions one might have applying approach like this. Questions like, how does this relate to block caching functionality, etc. I will leave answers to you, as I simply wanted to get you thinking.

Looking forward to your feedback.

Cheers.