Whether you are inheriting a Magento store from a hobby developer or getting shifted on a Magento project done by a different agency, determining what you are dealing with is not simply an answer to “does the store front look good?”. This three-tier system by Fabian Schmengler should help with overcoming the hassle of Magento quality analysis.
The first step before starting to work on an unknown existing Magento installation, should always be a shop analysis. Not only to understand the requirements and processes of the merchant, but also and above all to evaluate the quality and recognize possible problems early on. Unfortunately, many shops are tinkered with without any knowledge of conventions and best practices, which leads to:
- Suffering performance
- Security vulnerabilities
- Impossibility to update
- Unmaintainable code
Points 1 and 2 directly affect the merchant. Points 3 and 4 lead to bugs being accumulated over time, which results in new changes causing bugs in different places, that get harder and harder to solve.
This bug-ridden cycle is often the reason merchants try a new agency or developer to “fix everything”, so it is no coincidence that most shops that land on my desk are in such a degenerated state. The more important it is to analyze first, before any quote for further development and maintenance, to not fall into the same trap as the predecessor and to add clarity on both sides.
Three-Tier Analysis
The analysis has a three-tier design such that after the first tier (1 to 2 hours of effort) there is already a rough estimation of quality and need for action, and after the second tier it is possible to make a quote for cleaning and updating the shop.
Tier 1: First Impression
- The installed Magento version is determined. The older it is, the more important but also the more complicated the update will be.
- List of installed extensions is examined for the following:
- Number of extensions, number of custom modules, developed for this shop.
- Known extensions and providers (positive or negative).
- Encrypted or obfuscated source code.
- Deactivated or unused extensions.
- Serious security vulnerabilities, like sensitive data accessible from outside or latest security patches not applied.
- Number of core hacks (changed files in app/code/core and app/design/frontend/base) and core overrides (files in app/code/local/Mage).
- Data: Number of stores, number of products, used product types.
- Used tools, if evident (version control, modman, Composer et cetera).
- Server info, if available (hosting provider, PHP version, MySQL version, Varnish et cetera).
- Error logs, if available (recurring exceptions, warnings and notices).
In extreme cases, like a heavily modified Magento 1.3 shop, you can already stop at this point and advise a new build from scratch. Regardless, you should be able to roughly estimate the effort of an update and give immediate call to action against security problems if necessary.
Useful Tools:
- n98-magerun: command line tool for Magento, able to quickly reveal a lot of info without any manual work required
- Magento Project Mess Detector: plugin for n98-magerun which lists core hacks in an easy-to-digest document
Tier 2: Problems And Need For Action
Now that there is a global overview of what the Magento installation is composed of, the code gets examined more carefully. In case of uncertainties, always talk to the client to prevent making false assumptions.
- Regarding the found core hacks and core overrides: determine purpose, illustrate possible cleaner solutions (like usage of configuration, custom theming or development of a custom module).
- Regarding installed extensions: determine purpose, installed version and latest version. Find out compatibility with current Magento version, according to vendor.
- Compile a list of class rewrites, asses risk of conflicts (a rewrite of Mage_Sales_Model_Order should ring alarm bells immediately).
- Examine diff between theme and underlying default theme.
- Rough check of themes, custom modules and unknown extensions for best practices, red flags, performance brakes and security vulnerabilities.
Useful Tools
- Kalen Jordan’s Magerun Addons: a n98-magerun plugin for theme analysis.
- ECG Magento Code Sniffer Coding Standard – Magento coding standard definition for PHP_CodeSniffer
Further reading
- Analyzing an existing Magento Shop by Andreas von Studnitz (PDF)
- Theme Refactoring by Fabian Schmengler
Tier 3: Detailed Code Review
Now themes, extensions and custom modules are going to be analyzed in-depth. How deep we go and where we focus on depends on the wishes of the client and the allocated budget.
Personally, due to previous experience with this kind of analysis, I usually skip this tier given a broad examination applied in tier 1 and 2. After those, it is possible for me to provide a cost estimation after roughly 4 to 6 hours of analysis regarding:
- Clean up: remove unused extensions, replace problematic extensions, convert core hacks in clean modules, theme refactoring
- Update: extensions and Magento
Magento Audit Toolbox
A few tools have already been recommended above. As a lot of time is spent doing this kind of code analysis, I have collected a useful set of tools in a public repository: Magento Audit Toolbox.
Of course these don’t replace a trained eye but only support it. The toolbox is targeted at developers and agencies that want to standardize the analyis process and make it more efficient. The results are relatively useless for a merchant as long as they are not completed and interpreted by an experienced developer.
Using the Magento Audit Toolbox
There a few requirements the toolbox depends on:
- A complete copy of the source code (“/media” can be left out, to not download several gigabytes of images)
- A copy of the database (customer and sales data may be removed)
- Adjusted app/etc/local.xml with credentials for a local database
- And of course PHP and shell access
The repository contains a readme with detailed instructions on what exactly it does and how to use it.
Reporting the analysis
I usually collect the results of tier 1 and 2 in a spreadsheet, grouped by:
- General- Magento
- General – Server
- Installed Extensions
- Core Hacks
- Class Rewrites
- Miscellaneous
On every sheet there is a column “Action Required”, that gets filled with the required or recommended action if applicable.
Example: Installed Extensions
Example: Core Hacks
The report is laid out such that it is apparent for a merchant what has to be done and where the problems lie. It is also sufficiently technically detailed, so that it could be given to another agency or in-house developers, in case someone else is responsible for performing the necessary work after the analysis.
A written summary with the overall rating and verbal discussion of the results should also be included. In case of problematic extensions and modifications, it should always be asked, if they are really necessary and if yes, why. There might be more appropriate solutions for the client’s problems but without discussing this with the client, you will never know.
In case you are convinced by this approach and want me to do the analysis of your Magento store, feel free to contact me!
This post originally appeared on Fabian’s English blog and is also available in German.
