Take the 2-minute tour ×
Magento Stack Exchange is a question and answer site for users of the Magento e-Commerce platform. It's 100% free, no registration required.

Because I had a lot of issues lately with free and commercial extension I've decided to ask this question and answer it with the steps I usually follow when writing an extension. Feel free to edit the answer or add a new one.
In most of the cases when installing an extension or a theme I have to spend a few hours (sometimes more, sometimes less) to make it work on all the environments I need:

  • dev: usually localhost where the project is in a subfolder
  • preprod & live

This has happened even with extensions from large extension providers (that should remain nameless at least until I get really really mad and add their names in here)
So the main question is..what steps should I consider when writing an extension to ensure the quality of the code and and make it easier for a technical and non-technical person to use it and for a technical person to change it?

share|improve this question

3 Answers 3

up vote 48 down vote accepted

Here is what I usually do:

  1. Always develop with error_reporting on.
  2. Always develop with isDeveloperMode set to true. Just add SetEnv MAGE_IS_DEVELOPER_MODE 1 to your httpd.conf file (or corresponding file for nginx or something else)
  3. If the extension is linked to a core functionality add the dependency in the declaration file <depends><Mage_Catalog /></depend>
  4. If the module is for community use, use community as codepool to give the developers the chance to override some classes without modifying the code directly
  5. Put your frontend design files in app/design/frontend/base/default to make them available for all themes.
  6. Put your admin design files in app/design/adminhtml/default/default and do not change the admin theme. I may want to change it in one of my modules.
  7. Prefix your layout file names and template folder name with the company name to make it easier to isolate them. easylife_articles.xml and app/design/.../easylife_articles
  8. Put your static resources (js, css, images) in a similar folder as the template files easylife_articles/images/doh.png
  9. Attach a simple text file with how to uninstall the extension: What files need to be removed, what tables need to be dropped, what config settings need to be removed from core_config_data table.
  10. Do not write queries directly in models, blocks or helpers, use a resource model for that.
  11. Do not write queries using the table names directly Select * from sales_flat_order where .... Use a Zend_Select and transform the table names using ->getTable('sales/order').
  12. Use the base url to include js files in template. Wrong <script type="text/javascript" src="../js/some.js"></script>. Right <script type="text/javascript" src="<?php echo Mage::getBaseUrl('js').'some.js'?>"></script>
  13. Do not rewrite classes unless is necessary. Use observers and if it's not possible use helper methods that receive as parameter and instance of a class that you wanted to override. Wrong: Override Mage_Catalog_Model_Product to add the method getProductActicles(). Right. In your helper add getProductArticles(Mage_Catalog_Model_Product $product)
  14. If you override classes put a list of them in a readme.txt file
  15. Use the default admin path for the admin section of your module. Wrong admin url articles/adminhtml_articles/index. Right admin url admin/articles/index
  16. Add ACL for your admin sections. I may want to restrict access to some of the admins.
  17. Do not add an other js framework (jquery, mootools, ...) if it's not necessary. Write you code in prototype.
  18. Make you template html W3C valid (this is for OCD developers like myself).
  19. Do not put images in the media folder. Use skin. The media folder usually is not versioned and this makes it harder to move the website on different environments.
  20. Test you extension with flat catalog on and off. In order not to double the development time use Chaos Monkey
  21. Test your extension with cache on and cache off.
  22. Avoid using uppercase letter in the module and class names. If not properly tested this may cause issues on different OS. This is more a recommendation, not a 'must'.
  23. Dispatch events in your code to make it easier for developers to alter the functionality.
  24. Follow the same coding standards that Magento uses and comment your code.
  25. [Edited] Do not use php short tags (<? $this->doSomething() ?>). Use full tags (<?php $this->doSomething()?>). Also don't use short echo tags, yet. (<?="D'oh";?>). Use (<?php echo "D'oh";?>)
  26. Translate your texts using $this->__ and add the locale translation file with your texts (app/local/en_US/Easylife_Articles.csv) at least for en_US language. Not all websites are build in English and the identification of texts to translate it's time consuming.
  27. If you sell an extension offer at least basic support. Or at least answer the support e-mails you receive.
  28. Do not make constant calls to your servers through your extension for licence validation. Once, at installation is more than enough (I don't like this approach either, but it's better than to make calls all the time). (Inspired by this question)
  29. Develop with the log activated and from time to time take a look at the var/log/system.log file. The errors listed here are not shown even with developer mode on. If there is at least one error you end up with a large log file after a few months of running the extension.
  30. If your extension affects the checkout process or the orders in some way, make sure it works with multi-shipping, or if it shouldn't work with multi-shipping, make sure it doesn't affect it.
  31. Do not replace the default Admin Notification bar (or feed URL). If I'm interested on what you have to offer I will subscribe to your newsletter. Let me see what Magento has to say. It's more important to me.
  32. If you encrypt your code files with Ioncube (or something else)...well...I just hate you and I hope your business goes bankrupt

That's what have so far. I will add more as soon as I thing of something else.

share|improve this answer
    
I agree with you, it's definitely a good start. For sure, you will also understand that it's not always possible to cover all different kind of configuration and issues, at least it will reduce the possible one. Most of problem I meet with other extensions or people meet with mine are due to conflict with overwriting. –  Sylvain Rayé Sep 23 '13 at 9:26
    
@SylvainRayé. I agree. this will not cover all the possible issues, I also think that the answers to this question may be opinion based from one point forward, but I hope to build a list of common sense steps to follow to make developers lives easier. I also want to say that this question was asked out of rage, because I'm tired of paying for some extensions and spending time in fixing them. I could do something else in that time...like...nothing. –  Marius Sep 23 '13 at 9:30
    
@Marius,sure 1+ from me.it covers most of the cases and scenario what we are facing in development. –  liyakat Sep 23 '13 at 14:23
1  
@ColinM. First of all it's an honor to have your comment here. :). I agree there is a difference, I will modify the answer, but I still think that both of them should be avoided, at least until PHP 5.3 becomes the "new PHP 4". I mean it is still used on a large scale. –  Marius Sep 23 '13 at 16:27
1  
@Marius, your points are very helpful. Till #31 I was seriously focusing on each point, but on #32 I just burst out a loud laugh. +1 specially for point #32 –  MTM Aug 24 at 16:30

I am a big fan of using modman so that I can develop and source control just my extension and leave the core files and folder structure unchanged. It is also makes testing across different installations run smoother.

Oh and one massive tip always try to install your packaged extension locally on a clean install of magento before uploading it to Magento Connect, I have missed out files so many times in the package manager.

share|improve this answer
1  
Good call about the 'install your packaged extension locally'. I think this falls in the category: 'Test your god damn extension top to bottom'. –  Marius Sep 23 '13 at 14:01
    
I've been caught out by this before too. Make sure you test the package on a clean install that is not the same one you packaged it on! –  Joseph Oct 9 '13 at 18:13

Andreas von Studnitz and Dr. Nikolai Krambrock gave a good presentation on code quality on the Meet Magento DE 2014. They distinguish between general code quality and Magento-specific code quality. In short there are following general rules:

  • The use of structure elements - just like classes and methods - should be arranged in middle seizes classes. These elements of structure only make sense when they are used for structuring. Therefore they have to be of medium size. It is regarded to use 100-200 Lines of Code for classes and 3-20 Lines of Code for methods.
  • Because of the use of "if" or "while" the code is indented. If there are more than 3 indentations it is better to revise them. Too many indentations are an evidence for the code's complexity and should therefore be avoided.
  • Dead Code should be avoided and deleted. Static analyses help finding it if one exists.

Even more important are the Magento-specific rules:

  • Modules should work independently. They should only have little dependency on other modules and no dependency on templates. A solution is to use layout-updates (base/default) instead of adaption to template files and a module that covers additional functions of the template.
  • To maintain the ability of updates in Magento core-hacks and hacks of external modules should be avoided. A better way is the use rewriters or observer instead.
  • For changes it is better to use setup scripts instead of direct changes of the database or of the admin. Thanks to them changes have to be done only onetime.

Here are some more details and a video of the presentation: http://www.code4business.de/code-qualitaet-magento/

share|improve this answer
    
Nice and useful information. Thanks for sharing. +1 from me. –  Marius Aug 25 at 8:50
    
But If you had an english version of the link you posted would be even better. –  Marius Aug 25 at 9:00
    
An English version of this presentation is going to be written soon. I will keep you current and I will share the new link as soon as the English version is published. –  user3743859 Aug 25 at 15:08
    
An English version of the presentation is online now. Here is the link to it: code4business.de/code-quality-magento –  user3743859 Oct 1 at 6:57
    
huh? It's still in German. But I just happened to attend this presentation in English at MeetMagentRo about 2 weeks ago. Great stuff. –  Marius Oct 1 at 6:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.