At the moment, Magento has dozens of module vendors with hundreds of different modules. Each of the vendors have their own methodology and coding standards that often clashes with another module from some other vendor. In order to have a stable environment, there are some steps that you could take before transferring your freshly obtained third party module to the production server.
The first rule of dealing with the modules is that there is no “out of the box and working” installation. Magento is built in a way that gives developers a lot of freedom to shape it as they see fit. The module you have purchased might not have any bugs and most likely will work on the default installation right after you install it, but how will it interact with other previously installed modules? Or some custom code you have added? You’ll most likely agree that this is something that you might want to check.
How NOT to do it
Imagine you have a blank project in front of you. You have defined functionalities you will need to cover and decided to get a certain amount of modules from the market in order to cover them. The worst thing you could do is install them all at once and run the tests afterwards. This is a reliable way to make such a mess with your Magento installation that you will end up with a system that is very difficult, if at all possible, to debug. Yes, it might look as a shortcut that could save you some time you should be spending on proper testing, but you will end up having to wipe everything out and start from scratch much more often than not.
What should be done
If your modules are stored in archives, do not unpack multiple modules directly to your Magento installation at once. The obvious reason is that you will be automatically starting multiple module installation the next time you open admin panel. The not so obvious one: If two modules are using the namespace fallback mechanism to override the same core class, you will be forced either to overwrite a file or cancel extraction. The first option will wreck the first module that used namespace override. The second method will leave you with partially extracted archive and a task to manually pick and delete files that were extracted in order to start over. Ideally, module producers should avoid using the “app/code/local/Mage/…” type of overrides, but sadly it is not the case. Always extract the archives in separate folders somewhere on your computer (other than Magento’s folder) and run a quick check to see if there are direct file conflicts. (Exta tip: use version control system of your choice.)
Install each module separately. Always run through the whole process of module installation, including clearing cache and resetting session by logging out and back in your Magento admin panel after each individual installation. Even if a module is built on best programming practices, chances are that you will not be able to use it until you do this. Having your session and cache clean for the next module installation can prevent unnecessary issues during the installation process.
Get familiar with module’s documentation There are hundreds of modules out there. You are not expected to know the details about each one of them and what they are supposed to do, how are they supposed to do it and what should not be expected as a feature. Knowing the exact intended functionality of a module will help you to better understand how it can be used, how it can be modified to fit your needs and will help you in the potential debugging process. This step will also help you define what exactly should be tested before completing the integration.
Configure the module in the admin panel… repeatedly. This will help you define the exact configuration for the module as well as test different settings. Some modules are built in a way that you will need to find an exact configuration that will allow it to function without clashing with other modules. This step is especially important for modules that are using AJAX calls on the same page in frontend – like some AJAX based layered navigation and AJAX based add to cart with lightbox. It is also important for modules that are playing with URLs. Testing to confirm that each of the module’s key settings are working is also useful, since it will allow you to better pinpoint a bug or a conflict later, during the development.
Perform a quick code and database inspection. Some of the module producers out there are not following the best practices and standards in developing modules for Magento. We have seen situations where even core files are modified by the module, which is something that should be avoided at all costs. These cases are rare and are usually linked to just a few producers, but it will not hurt to check anyway. Take a look at the overwrites in the files and overrides in the config.xml and detect potential conflicts with other installed modules. Do a quick inspection on database modifications done by the module as well.
Write down any potential bugs, missing features, issues and conflicts and add module’s name to the note. You should also remember that even if everything went well during your testing process, code and database inspection and configuration, you might still get some bugs later in development. It’s good to know previous issues you had during the installation and testing of the module as it can help you define the source of the current ones.
Read more about Magento: mage-shop.com, arrowhitech.com
