Considered to be one of the most powerful eCommerce based CMS tool today, the journey hasn’t been a smooth sailing. The content below throws light on the path taken by Magento over the years to reach where it is today.
For years people had been using a modified Zen Cart codebase which worked well, something that was easily hackable but constantly frustrated web administrators with bad system design, poor templates, low standards compliance and a weak development community. It was something people had to live with and overcame these shortfalls by making few custom modifications. Magento appeared on the scene at a time when everyone was criticizing over Web 2.0. It was a time of shiny new applications, short & brandable urls, gradients and buttons. At first it seemed too good to be true; an MVC approach (using Zend framework), latest technology, well thought out features, upgrading platform, company backed and developers not afraid to use the latest versions of PHP and MySQL. Those who tried Magento loved its features but not much was known about it’s codebase. It was really strange, it had a lot of files, a lot of directories, a completely OOP and an unusual use for XML. Those who tried this took it as a learning experience and went about using it in small real time projects to see its results. Even though a lot of this depends on several external factors like people who use it, application and its purpose, and so on it was more about ensuring the right technology is used at the right place.
With features such as product filtering, high numbers of orders, one page checkout and many such add-ons, a lot was required in terms of hacking into Zen Cart, so due to its advanced features people started using Magento. But there was one hurdle which most web developers faced. People could not understand what decision process resulted in thousands of directories and tens of thousands of files (a lot of which contain empty class declarations). Figuring out the pattern of where the code went and what the abstract folders called “Convert”, “Entity”, “Layer”, “Resource” etc. are for. The naming convention for folder names, model names etc. didn’t sink in – sometimes you needed lower case, sometimes camel case and sometimes one capital letter. To make things worse, documentation was very sketchy and not many resources were available to find out answer for the problems. Due to the Zend/OOP/MVC influence on Magento it was impossible to follow the code. Classes are referenced dynamically, various aspects are contained in XML files and there is no clear flow that you can just debug through. The sheer volume of files and folders makes finding something unbelievably tedious. Even the database is a minefield. In Magento, the use of EAV means that data is split amongst hundreds of abstract tables. Again, it doesn’t flow and it doesn’t make sense without a great deal of time developing a solid understanding of what they have done.
Hence to conclude, Magento is an advanced system which requires a lot of learning and re-learning. Once the rules are learnt and understood these application design decisions make sense.
Magento development services requires a lot of learning and re-learning. Once the rules are learnt and understood these application design decisions make sense.