Magento is a great platform with fantastic flexibility and potential to build whatever your heart desires. At one point, this was Magento’s motto – “Platform For Growth”. However, with great flexibility often comes great responsibility. Developing a Magento site can come with a steep learning curve in terms of fully understanding best practices and how one should even begin to make changes. We see this manifesting when we audit existing Magento websites where there are developers, who maybe aren’t trained in Magento and have taken several wrong turns. This kind of issue spills out into the Magento Connect marketplace as well, where we see a plethora of extensions advertised and each doing a special task.
The main issue with Magento Connect is not the actual feature, but the review process. Anyone, anywhere, can create a Magento extension and publish it on Magento Connect. Although this is exciting in that there exists code that you don’t need to write to achieve certain results, we often find extensions either lacking in quality, flat out not working, or the worst, malicious code in the hopes that someone unsuspecting will install it. This also makes it difficult for clients when they say, “but this extension says it does this why won’t you install it?” but that is a entire separate post. This is why evaluating magento extensions before installation is important
I should note that at Demac Media we do not use the Connect Installer which comes with Magento in the administrative backend. Rather, we use this “direct downloader” which allows us to review code first before placing it on our sites – http://freegento.com/ddl-magento-extension.php I would recommend you do the same.
Common ways you can assess an extension
Unfortunately there’s no real way to see the code before purchasing an extension, which makes reviewing before purchase difficult.
1. Do not place the Magento extension into your Magento install just yet!
This is because install scripts or observers can “kick off” and harm your site with just one page refresh on the frontend (assuming your configuration cache is off or has been refreshed thus enabling the extension.)
2. Look for Obvious Offenders
When auditing a Magento extension, I will usually first look at some telltale signs that a) the developer has no idea what they’re doing or b) they have created a malicious extension. Do an entire path search within the extension for the following PHP function strings:
eval: Finding a random eval() in code raises a lot of eyebrows, as it allows any code passed in as a string execute within the function. I’ve seen it used in extensions where they will receive some code from another server and execute it. Sometimes they’ll even go as far as to base64_encode the code so it’s not human readable. For more information on eval(), this is a decent StackOverflow post – http://stackoverflow.com/a/951868
base64_: Sometimes a developer can hide nasty things in code as it’s not human readable unless decoded by base64_decode. It’s worth taking the time to see what they’re trying to hide in the string.
mysql_: Magento has it’s own way of connecting to the MySQL instance and no extension should ever need to connect via the PHP mysql methods.
ini_: All ini directives should be set by the php.ini file on your server, or by Magento itself in the index.php file. Often times we see poorly coded extensions allowing more memory for the current process through ini_set(‘memory_limit’, ‘some dumb amount of memory here’). Any code that is using that should be refactored.
error_reporting: All error_reporting should be set on the server level or within Magento’s index.php file
mail: There usually should be no reason to send an email from an extension (unless it is advertised.)
chmod: This is a big no no as an extension could have the capability to change file permissions on your server without you knowing. This could theoretically give access to elements that you are wanting to keep private.
mkdir: Again, no directories should be able to be created by the extension. If the extension developer is defensive about using this, they should be using the built-in Magento folders within the install to manage their content.
file_put_contents: There generally should be no creation of files through an extension although there are cases where this may be acceptable.
curl_: cURL is acceptable if the extension needs to communicate with a 3rd party service, but be careful as to what it may be posting.
ftp_: Just like cURL, FTP can be acceptable if the extension needs to communicate outwardly. Review with your discretion.
These are some of the main ones. Use your own discretion when reviewing the code within the extension.
3. Bad Rewrites
Extending code comfortably is one of Magento’s strong suits, however know that if you’re rewriting core, you often need to take many things into consideration. How will this change affect this class? External factors? Other code that depends on the core existing as it currently does? Make sure to crack open the config.xml file and check for the <rewrite> node and check the files its rewriting. A big no no is if the extension just includes a Mage folder within the local codepool. There are very, very few circumstances where this is acceptable. In conclusion, check any rewritten classes for any offending code and make sure to compare it to the original class.
4. Scary Observers
Observers are a fantastic way within Magento to inject any custom logic you have into pivotal moments within Magento being initialized. They can also be a trap in terms of figuring out if you have a performance issue (the amount of times I’ve heard “this issue is probably because of an observer somewhere is… a lot.) I have see extensions do things like this – hooking into customer_save_after rather than just customer_register_success when they just need logic to do something with the customer object after they register. Any event that uses [object]_load_before, [object]_load_after, [object]_save_before, [object]_save_after needs to be looked into as these can be called very frequently. When Magento’s bootstrapped, it may even call these multiple times in one initialization! So, pop open their config.xml file, figure out what observer file they’re using, what events they’re using, and take a peek.
5. Terrible DB Scripts
Sometimes an extension will need to install its own tables within your database which is acceptable and normal. It’s when an extension is changing core tables (even if it’s adding columns), you should be careful. There are very few circumstances where modifying a core table is acceptable and could perhaps become a conflict if one is to upgrade the Magento install in the future.
6. Weird Cronjobs
There is the potential to run certain actions with an extension on a cron by default. Assess what it is running, and when. When creating an extension, you should always give the option of running the cron manually, or enabling it. Just assuming that “it’s 3am and everyone’s sleeping and not on the website” is not enough.
7. Annoying Layout Updates
8. Do a Quick Run Through the Code
Finally, it would be a good idea just to jump through files to check and see what they’re doing and where to get a sense of how the module will be changing your site. If you’re still unsure, consider installing an isolated default install of Magento and install it on there to see what will happen.
Overall, there is no hard science to determining if an extension is “good” or “bad”. One must use their own discretion and always test, test, test after installing an extension to make sure everything is still working as intended.