Magento: why complex doesn’t mean good

Salvatore Zappalà
5 min readApr 21, 2015

Just a little bit of background before I get started. I’m a Web Developer born in Catania, a city in the middle of the mediterranean that in her own small way it’s becoming a growing IT hub with startups, incubators and so on.

A couple of months ago I accepted a job offer from a company based in London. I packed my backpack and I took this chance to move to this beautiful city, looking for a new adventure.

I ended up working on the rebuild of a medium-sized e-commerce website based on Magento, the popular e-commerce platform. Brand new team, interesting people to work with, brand new city. Exciting!

But the fun ended as long as I started to look at the codebase. Magento is an incredibly complex platform, with more than 8,000,000 (millions!) lines of code. This complexity is often flaunted from Magento developers as a source of pride, but unfortunately complex doesn’t necessarily means good.

Magento is famous among developers as a source of frustration in the first months of development

Let’s see some of the things that I don’t like about Magento.

Complete lack of documentation

Yes, that’s it. You will find yourself reverse-engineering the code wasting hours and hours of your time because Magento business model is based on extremely expensive tech support and formation, so they want to keep it that way.
That’s one of the reason why good Magento developers are well payed and a scarce resource.
This goes against one of the values I embraced as a developer, that is perfectly explained in Apprenticeship Patterns:

A belief that it is better to share what we know than to create scarcity by hoarding it. This is often connected to an involvement in the Free and Open Source Software communities.

A lot of configurations in XML files

Convention over configuration is a design pattern that is used in almost all modern web frameworks. It basically means that you don’t have to configure the behaviour of your software platform, you just follow the rules instead. In this way you keep your focus on the core problems that you want to solve and not on the infrastructure (i.e. more abstraction).

Magento does this the opposite way: configuration over convention. To build anything (like a block, controller or a module) you have to edit one or more XML files, adding several entries. This means that you have to remember to do this every time: it makes more room for annoying bugs and it makes your code less concise and more difficult to debug.

A magento project can have hundreds (if not thousands) of these XML files, and they are merged all together at runtime. This means that any rule can be placed in any XML file and that is a perfect recipe for a long lasting headache.

Lack of unit testing

Magento doesn’t support unit testing out of the box. This could have been acceptable 5 or 10 years ago but it isn’t anymore.
I found some libraries that add support for unit testing and I will try them anytime soon, but I guess it’s no picnic.

It’s built the old way

  • No Composer, it actually doesn’t have a package manager at all.
  • It has badly written Javascript using Prototype.js. It will eventually have a modern (sarcasm) Javascript framework such as JQuery in the new 2.0 version that it’s still in development from ages now.
  • It doesn’t have a modern templating engine like Twig, it uses PHTML instead.

It’s slow

Magento has several cache layers that can hide this issue, but caching is not meant to be a solution for not optimized code. Again, magento is extremely complex (remember the eight millions line of code?) so to serve a web page in a normal server it can take up to several seconds.
This is due to the parsing of the configuration files and to the querying of the thatabase containing huge EAV tables, among the other things.

EAV means Entity-Attribute-Value, it is a way to store dinamically structured data in a database (e.i. the structure can change at runtime). In other words:

EAV gives you enough rope to hang yourself, and in this industry things should be designed to the lowest level of complexity, because the guy replacing you on the project will likely be an idiot.

So make sure that you keep your cache in a good shape and that you throw a good amount of money on your hosting platform, or your store will be slow.

Community code is low quality code

I found myself refactoring a lot of code from third-party extensions. Often times there are antipatterns, lack of conventions, bad practices, even bad code formatting.


They are willingly shipping, since three months now, a vurnerable version of Magento that can lead to the complete compromise of the webstore.

Their response on the issue:

Due to our lack of automated tests, we have no possibility for a quick release cycles.

They already released a patch file, but they keep the Magento tarball unpatched. This looks like an irresponsible and lazy behaviour to me. Also I wonder about the testing of this patch, after they said (unsurprisingly) that they don’t have automated testing.

You can find more info on this vulnerability here. If you have a Magento store, please make sure to patch it.


Magento is the de-facto standard for the e-commerce platforms and it’s getting old.
I personally think that it fails in the first place in making the developers life easier (if this was a goal at all), and now it is also outdated.

The thing is though, it seems that there is not an obvious successor.
We’ll see how the e-commerce scene will develop in the future.

Did you like this post? Do you agree or disagree? Feel free to join or start the discussion.

You can also find me on twitter at @salvozappa

Thank you for reading this far.

Salvatore Zappalà

Software Engineer based in London. Opinions expressed here are mine.