Here is what I usually do:
- Always develop with
error_reporting
on. - Always develop with
isDeveloperMode
set to true. Just addSetEnv MAGE_IS_DEVELOPER_MODE 1
to yourhttpd.conf
file (or corresponding file for nginx or something else) - If the extension is linked to a core functionality add the
dependency in the declaration file
<depends><Mage_Catalog /></depend>
- 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 - Put your frontend design files in
app/design/frontend/base/default
to make them available for all themes - 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 - Prefix your layout file names and template folder name with the
company name to make it easier to isolate them
easylife_articles.xml
andapp/design/.../easylife_articles
- Put your static resources (js, css, images) in a similar folder as
the template files
easylife_articles/images/doh.png
- 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 - Do not write queries directly in models, blocks or helpers, use a resource model for that
- Do not write queries using the table names directly
Select * from sales_flat_order where ...
. Use aZend_Select
and transform the table names using->getTable('sales/order')
. - 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>
- 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 methodgetProductActicles()
. Right. In your helper addgetProductArticles(Mage_Catalog_Model_Product $product)
- If you override classes put a list of them in a
readme.txt
file - Use the default admin path for the admin section of your module.
Wrong admin url
articles/adminhtml_articles/index
. Right admin urladmin/articles/index
- Add ACL for your admin sections. I may want to restrict access to some of the admins.
- Do not add an other js framework (jquery, mootools, ...) if it's not necessary. write you code in prototype.
- Make you template html W3C valid (this is for OCD developers like myself).
- Do not put images in the
media
folder. Useskin
. Themedia
folder usually is not versioned and this make it harder to move the website on different environments. - Test you extension with flat catalog on and off. In order not to double the dev time use Chaos Monkey
- Test your extension with cache on an off
- 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'.
- Dispatch events in your code to make it easier for developers to alter the functionality
- Follow the same coding standards that Magento uses and comment your code.
- [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";?>
) - Translate your texts using
$this->__
and add the locale translation file with your texts (app/local/en_US/Easylife_Articles.csv
) at least foren_US
language. Not all websites are build in English and the identification of texts to translate it's time consuming. - If you sell an extension offer at least basic support. Or at least answer the support e-mails you receive.
- 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)
- 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.
That't what have so far. I will add more as soon as I thing of something else.