For the last year or so I have been actively involved in online store development based on Magento ECOMMERCE platform. Everyone involved in Magento development can tell you that Magento extensively uses OOP approach. Although not everyone will agree, I like the way platform has been architectured in the backend. Layouts and config files enable you great deal of power without even writing a line of PHP code. Its not perfect, but what is. I believe most of you heard the “cliche”: “With great power comes great responsibility”. Let’s discuss this in regards to Magento.
There is a plain and simple message I wish to shout to current and future owners of Magento powered online stores: “Get serious, focus on what matters the most!“.
Now what exactly did I have (and still have) in mind with statement like this? Unlike WordPress and Drupal (no offense, I use them, I respect them) not everyone can develop quality modules (extensions) for Magento. Platform itself requires developer a decent amount of knowledge from PHP OOP and other fancy object related concepts. As mentioned in one of my previous articles, Observers and “overrides” are among my favorite concepts (approaches) in Magento module development.
One of the projects I was assigned few weeks ago had a great amount of products, total of 46 268 to be more precise. Most of these are simple products with “Visibility”:”Nowhere” and are used strictly as Associated products in some Configurable products. Configurable products are for the most part shown to the user on frontend. All in all, there is a handful of Configurable products in the system, each holding couple of thousands Associated product.
There are two issues here. First and most annoying issue I came across in this “WTF” configuration is the performance. Complete collapse of any reasonable execution time. Loading a page that holds this kind of Configurable product takes from 3-9 minutes, both on frontend and backend. I’m talking about 3-9 minutes on local machine with maximum resource settings for PHP and MySQL. Second issue here is obvious misunderstanding of Magento product types and how to use them.
I have already done Magento project with the approximately same total number of products in system. Number of products itself does not impose that much noticeable performance drop if the products are used the “smart way”. By “smart way” I think in terms where you have wast amount independent Simple products. Magento can handle that quite well. However, having large amount of relations like those Configurable Products > Associated Products can kill your store to “usability equals zero”.
Here is where I draw the line on developers part. If you are lucky enough to get working on a new Magento related project from scratch you are obliged to recognize these kind of issues and react on time. Change the approach to the way how products need to be presented in the system and so on. It is unacceptable to create thousands of Associated products just to make them affect the final price of Configurable product. If you need to come up with solution like this, try developing a custom module to work around the issue not go with it. Performance drop is guarantied in cases like above. So if the client comes with the idea like “I have a lot of products that kind of fall into the category of Configurable products that can use this and that as Associated product to stay dynamic in that and that selection…” you need to stop, think twice how this will affect store as whole and then propose the solution. No need to blindly go with clients (owners) suggestions. His prime wish is to get his store working and selling with least amount of budget as possible.
Sure it looks great, its looks cool but the real question is “How much will it improve your selling?”. I realize the usability can be as much as important as functionality. By now, there are even some color switcher modules you can buy. However, most of magento modules require additional work to be properly implemented in order to fit the owners wishes. Due to the complexity of Magento platform, sometimes even the smaller changes require lot of time and effort on developer part. This would all be great and shinny if everything would work after the upgrading Magento store when the new version appears. All this leaves entire development process focused on the “little things”. I say, why not style the theme to the end with the default Magento page setup. Why change the output of product view page? Why not leave it default, just fully style it to match your design. This kinf of approach would be far more safer in terms of upgrades and in terms of bringing the project to the end in as much as possible short timing.
What I’m trying to say, Magento comes extremely feature rich out of the box. Development time is not free, and to my opinion it should be focused on either building fresh, new features for the store or at other parts of the system like Promotions, Catalog price rules, Shopping cart price rules, Customer groups. The latter one seem to be relatively ignored in the big picture.
Adding features like “color switcher” could be left for latter phase of development, the one after the site goes live. The one you are sure your store is working the way it should, its stable, nicely styled, optimized for best performance, and quite well structured so its relatively bullet prof on updates. Then you can start adding modules, fancy usability tweaks and so on.