Understanding The Do’s and Don’ts of Magento Web Development

Magento is a boon, no doubt. Right from versatile content management to streamlined third-party integrations, it has almost everything that you, as the potential owner of an online store, can ask for. And apparently, all you need to do is to look for someone who knows Magento web development inside out, and can help you go viral with whatever it is that you offer. Or maybe not! Using this oh-so-great platform to your advantage calls for much more than simply hiring a web developer – it calls for a better understanding of what works and what doesn’t!


Here’s what a Magento website developer should ideally stick to:

Keeping Overriding To a Minimum

Given the fact that the developers have several tools at their disposal, including event listeners and helpers, they should preferably refrain from overriding the core classes, at least for the purpose of forming some of their own. Furthermore, if they can keep the overriding in check, they also do not risk engaging into the typical extension-third-party-add-on conflicts.

Using the Better Alternative(s)

If and when they need to schedule tasks, Magento developers must do so with the help of Cron jobs. It’s a good practice to not to use Daemons for this purpose, and rather take advantage of the cron.php file. Similarly, when they are not sure whether to load multiple models separately or load them all at once using a single SQL query, it is highly recommended that they choose the latter, more so because the former is likely to slow down the code.

Following the Protocols for Mobile Sites

Mobile sites must be considered separate from their desktop counterparts, at least for the purpose of development. On that note, it is important that the developers:

  • only use optimised templates


  • and incorporate images by following the relevant conventions


Minimising the Execution Time

Time is money; the developers should try and save all they can. For instance, if they need a specific result set, they should not use “fetchAll ()”, unless it’s absolutely necessary. Better still, if they resort to the fetch () method, they can easily cut down on the execution time. Likewise, when they need to count the size of an array, they have 2 options to choose from:

  • Doing it on each iteration
  • Doing it outside the loop

The former can be a bit time-consuming, especially if the array contains quite a few items.


These are some of the practices that are better avoided:

Modifying the Core Files

When customising a Magento store to meet a client’s individual requirements, many developers may be tempted to modify the core files. The question is: should they? NO! That’s because modification may render these files useless at a later stage, when the client decides to migrate to a newer version of Magento. Instead, they should try and create a local copy of each of the core files, and then proceed with customisation.


Keeping the Cache Enabled

Cache is a two-edged sword, one that a good Magento website developer should always handle with care. Yes, the cache does come in handy, but only in the production environment. If and when it is left enabled during the development phase, the developer may have a hard time taking a second look at any of the updates done on the website. Chances are that the cached version will still be on display. So, it is better to disable the cache first:


Retrieving Redundant Data

Anybody who undertakes web development should play it safe, but that doesn’t mean they should go ahead and retrieve an entire collection of data, even when they just need a couple of items. This can be a huge mistake, which can only be prevented if the Magento developer is smart enough to apply a limitation to the collection query.


It is imperative for a Magento web developer to realise that every collection is a query, and that if there’s one in a loop, it will eventually play spoilsport. Therefore, all such collections, i.e. the ones that are inside a loop, must be dealt with at the earliest, or they may slow down the website.

Removing Generic Blocks

A developer must understand that what “can” be done may not always be the same as what “should” be done. For instance, when using Magento, they can delete generic blocks from XML layouts, but that doesn’t mean they should. Such blocks are of great use to third-party extensions, and if deleted, may interfere with their working.

Some dos and don’ts, including documentation, must be paid heed to, while undertaking any sort of web development, with Magento being no exception. A documented code is not only easy to work with, especially when faced with a problem, but also enables another Magento developer to take over, without any difficulty.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)