Magento custom development and freelance programming


3): ?>
Srdjan picture

My name is Srdjan Bajic, and I’m a 26 year old Magento freelance developer from Sombor, Serbia (Srbija). My programming roots start with Simon’s Basic back in Commodore 64 era. I’ve been into PHP development since I was 18, finishing first serious project with a friend – school website. After finishing high school, tried to become an IT graduate on University of Technical Sciences in Novi Sad, but dropped out after 2 years, to embark on a web development career. Started of as a freelancer before obtaining a developer position at Implementek, Belgrade, in June 2008.

Implementek based it’s business on e-commerce and made a visionary move to migrate from osCommerce to Magento in Dec 2008. Since then, I’ve been involved with development and management of many Magento projects for various clients worldwide. In May 2010, Implementek and myself decided to go our own ways, and I chose the way of freelance Magento custom development.

Spring of 2011 found me in beautiful island of Mauritius, working as a Senior developer at Navipartner. This company, among other things, does a brilliant job of combining Microsoft Navision and Magento. I sticked around for 9 months, before returning to my original freelance profession to further sharpen my Magento skills.

3): ?>


The problem: In the last year or so, I’ve had a lot of fireman-type projects where I was asked to stabilize a poorly built Magento store. More often than not, my clients were merchants without a dedicated technical team, who paid 5 digit fees for their websites, and more often than not, their stores were built by taking base Magento, applying a poorly tailored template to it, and stuffing it with 30 obscure modules from the market. Not long after the delivery, the store would start to fall apart – load times would go over 10 seconds, orders got lost, sessions disappeared, and content management and upgrade options were next to none. Store owners would then start paying the same team for support, until the point were they could no longer sustain their shop or decided to start from scratch with a different team. And what’s even worse, they blaimed Magento for it – I often had to go through a lot of talk to convince them that Magento is a very solid platform and it was the modules’ poor build quality that caused all the issues. It gives me the creeps to even think about all the code horrors I saw in such stores.

In my opinion, one of the reasons for these scenarios is the “there’s an app a module for that” kind of thinking, where the developers (often because they were instructed to do so) would buy an obscure or a popular but spaghetti-coded module from the market for even the smallest customizations.

This approach also affects those development houses who tend to keep their code clean, well structured and bug-free, because their modules are being cast aside or not able to break through the sea of similar-purpose, crap-quality modules from various obscure development companies. Store owners are then not able to distinguish between the stable and unstable modules and simply buy whatever fits the description.

If this trend continues, we will probably witness a growing numbers of unstable Magento shops, that would in turn affect Magento’s reputation as a stable platform. Magento started out as a perfect solution for small to medium sized merchants, but will in turn become a safe investment only for those who can cash out six digits for their shops.

The solution: Granted, not everyone can afford a 100€ph team who would build all the cool stuff from scratch, or a high profile agency with it’s own portfolio of production-tested, stable modules. But what they can do is choose only those modules that have passed a quality test by Magento’s own “ISO” team. In an approach similar to Certified Developer, Magento would create a team that would “audit” modules from the market and put it through a series of criteria to determine it’s build quality. Criteria such as following Zend programming conventions, Magento’s customisation recommendations, module’s impact on the overall performance etc. The team would not necessarily gurantee that the module works as described (although that can also be part of the process), but that it’s simply built according to established coding practices. Such modules would then get a “certified” badge on their Connect page.

Of course, this would not come for free. Every developer that wishes to certify their module would pay a fee (in example twice the sales price) to have it inspected. This would only apply to commercial modules, so free modules would somehow be exempt from the entire procedure (although could pay a flat fee to be part of it if they wish).

By doing this, Magento can help promote those addons that retain the overall build quality, stability, extendability, upgradeability and all the other “abilities”  of base Magento.

Actually, the store owners from this story remind me of myself when visiting a doctor, or a dentist. You can only hope that the doctor has your best interest at hearth and knows what they’re doing, cause when the work is done, there’s very little you can do about it.

I have opened this idea for discussion here, so please if you wish to discuss it, use the board instead of comments on this page. If you wish to support it at it’s current state, you can sign the petition here.


It’s a very common requirement to remove the zeros if price is round itself, but to leave it with two digits if it’s not.

So, in example, if the price is €480.00 , it should be rounded to €480, but if it’s €480.67, .67 should remain.

A quick fix for this is to rewrite Mage_Directory_Model_Currency::formatTxt() in this way:

    public function formatTxt($price, $options=array())
        if (!is_numeric($price)) {
            $price = Mage::app()->getLocale()->getNumber($price);
         * Fix problem with 12 000 000, 1 200 000
         * %f - the argument is treated as a float, and presented as a floating-point number (locale aware).
         * %F - the argument is treated as a float, and presented as a floating-point number (non-locale aware).
        $price = sprintf("%F", $price);
	if ((int)$price == (float)$price) {
		$options['precision'] = 0;
        return Mage::app()->getLocale()->currency($this->getCode())->toCurrency($price, $options);
select all


I just finished Magento Certified Developer exam and here’s my thoughts on the certification process. Hopefully, it will serve to someone asking themselves how tough is it and how well you need to prepare.

Well, it’s tough :) I’ve been a Magento developer for 4.5 years now, working with Magento every single day in the office. I’m a backend developer, specializing in developing custom modules. I did zero preparation. I originally planned to prepare for about a week, but when I saw the material I realized that it’s either no preparation or a month long study. So about the questions. You get multiple choice questions, some of them multiselect, some of them radio. Questions are tough and very precise, in example, asking you if object’s resource class is called by getResource() or getResourceModel(). Details really. I scored 42/70, with 37 being the threshold. I knew for a fact only a handful of questions, maybe 7 or 8, and the others I answered intuitively, relying on my experience or by deducting the wrong answers.

So, bottom line, if you don’t have at least 3 years under your belt, or are a genius, don’t bother taking the exam without solid preparation.


If you try running any default PHP datetime functions from Magento, you will notice that you always get UTC (GMT+00) timezone values, regardless of your apache/web server/php settings. This is because Magento needs to maintain support for multiple stores (which might be in different time zones), and therefore converts all the times to UTC. Hence, all PHP functions such as date(), time(), strtotime(), will always return UTC. So instead of using PHP functions, you need to use Magento’s datetime functions. Here’s a snippet of how you can do that:

    protected function _getWeekday($time,$short=true) //time is int timestamp
        $locale = Mage::getSingleton('core/locale');
        $format = ($short) ? Zend_Date::WEEKDAY_SHORT : Zend_Date::WEEKDAY;
        return strtolower($locale->storeDate(null,$time,true)->get($format));
select all

Basically, you need to do some Zend_Date research, and look into core/locale magento class.


Did you ever have to specify a $_GET parameter for url in cms block or page, in admin? URL-s in admin usually look like this:

{{store url="my-url"}}
select all

You can do it by adding a _query parameter:

{{store url="my-url" _query="parameter1=true"}}
select all

Archive: ') ?>