As a Magento solutions integrator, we are constantly changing adapting, and modifying Magento installations to get new different modules to suit custom themes, and to resolve conflicts between modules that need to access the same part of Magento. It doesn’t take long before you find some common elements in every job your doing, even getting the feeling of Déjà vu when chatting about modifications or writing a project scope.
Customization is a significant investment
First and foremost, customization usually involves much more than plug and play functionality. Even if modules exist that do exactly what you’re after, often, your theme needs to be integrated to suit (something that module providers rarely do). This means making sure that your theme will work under all the browsers, and, if it’s responsive, you’ll need to re-code it to work for tablet, mobile, and desktop. All in all, any good solutions engineer will tell you module integration are rarely straightforward, and generally go well above the manufacturer’s installation scope.
Module Installation and Integration are different.
Installation is insuring the module performs the function it’s supposed to. Integration is insuring that the module works as it’s supposed to, disrupt functionality of other modules, and outputs correctly on screen embedded in your theme. Anyone that’s used Magento without a developer knows all to well that “installation” on a manufacturer’s site, often isn’t scoped to allow the module to work within their current environment. It’s a fair point, because some modules alter data moments before save, or extend the core in ways that you might not expect.
Solution integration is Alpha Code
Although it might be stable, every solution integration is essentially hot off the press. With the latest version of Magento 1 and 2, Unit Testing has become available. Provided that you’re installation is up to date, it’s a must. Although, as I’m writing this, it’s not as useful as it could be, very few third party developers write unit tests for their modules, so even though you’ll know if core code breaks, you won’t necessarily know if the new functionality that you’ve added will work as you’re expecting once new modules are introduced.
Performance changes
Each module adds a layer of complexity to the end solution. Hosting requirements for a base Magento installation could be greatly different once a new product type is added, gift registry introduced, or indexing modifications made. In short, a module may be inexpensive as far as the license cost, but there could be ongoing costs should it cause your site to leave a larger memory footprint.
Future updates need to be considered
Modifications will get you the functionality that you’re after, but when they aren’t done to the best practices, updating Magento could; in the best case revert the change, and worst case bring down your installation and lose you sales. Almost every Magento installation deployed today has modifications to at least some of the html markup. I would even guess this is 100%, seeing that we haven’t come across a theme yet that has managed to be completely based in css and javascript only. Nor is it proper to do so, if you’re after frontend performance, and general compliance. But the more modifications that are made, the more that need to be re-made on the update of the core code.
