This article was first published on the 18th March 2018
For some time now, our company has run individual audits of Magento 1 and Magento 2 based online stores. Some of these shop audits happen in the process of taking over a running project: before we get to work, we do the shop audit in order to find out about the current state of the project, the code quality and possible pitfalls that might await us.
Better basis for informed decision making
Many of these shop audits happen when a merchant wants to get an independent opinion on the store from a technological point of view. Without any prior affiliation with the project, we are free to examine it, look for issues regarding performance or security, core hacks and code quality in general.
These insights offer a basis for decisions the merchant can make.
Is it time to put more emphasis on a neglected issue? Did the work of the previous or current developers lead to good results? Are there imminent dangers to the online store's success?
Structure of our Magento Shop Audits
The process is generally divided in three parts:
Magento store analysis
The first task is to gather information about the store. We then take a deep dive into the code to find out about potential security issues, performance bottlenecks and code quality.
A search for known Magento security issues, risky configuration and hacks is performed. Afterwards, we test the store's performance. Sometimes a single line of code is able to slow down the complete store. And finally the code quality in general is analyzed: core hacks that make future updates more expensive, and drawbacks in the code.
Finding security issues is the most critical part of the analysis. Possible findings can be:
- Missing Patches / outdated Magento version
- Existing Hacks (which can for example leak payment data)
- Unsecured directories and files containing sensitive data
In almost every of our recent audits, we have found at least one severe security issues!
If the Magento core code is modified directly, it is impossible to deploy new versions of Magento without overwriting those modification. We check for the following:
- Modified core files ("Core Hacks")
- Copies of full files and directories where it wouldn't have been necessary
- Usage of outdated programming construct which may not be compatible to newer versions of Magento or PHP
Code quality defines how hard it is to extend or change the code in the future. Also, bad quality usually hides more bugs as it is more difficult to find them. In order to get an impression of the code quality, we check the following (random sampling):
- Custom extensions
- Third-Party extensions
- Custom theme
- Third-Party theme
Summary of findings in the report
Once the analysis is completed, we create a report that summarizes all findings and results. It is a documentation of our process and of the scope that was examined. For example, for some stores only a selection of third-party extensions is analyzed, and we generally do random sampling as it's nearly impossible to read every line of code.
We provide a written report in Englisch or German which usually contains between 5 and 10 pages.
In addition to the pure documentation of findings, we add our advice to the report. That way, issues are contextualized and prioritized according to their severity. As a result, everyone who reads the report is able to understand in what condition the technological basis of the online store is and which issues - from an independent point of view - should be worked on first.
Our advice often includes:
- Remove hacks and security issues
- Replace core hacks by rewrites / plugins
- Replace / remove certain third-party modules
- Introduce certain quality measures
- Change of hosting
Why we recommend shop audits
Not every merchant is lucky enough to find a trustworthy system integrator. There are some black sheep out there who either ignore best practices and hack the core, outsource work to even less trustworthy third parties, or don't know what they are doing, which (in a complex system such as Magento) can have dire consequences.
The shop audit for stores based on Magento 1 or Magento 2 can then act as an analysis of the status quo and a map for the next steps on the way to a better technological basis.
It can also help to have a smoother transition from one system integrator to another if you have an account of the current state right before the baton is passed on. It also prevents finger-pointing.
For us, a shop audit is like a box of chocolates - you never know what you are going to get (words to live by from Forrest Gump). Unfortunately, it is not so uncommon to find severe security issues or even hacks. Some of these made it into Andreas von Studnitz' talks about Magento worst practices (of course, all data which would make it possible to track back the source were removed). The good thing is that once discovered, there is a chance to get rid of hacks and improve the foundation of these online businesses. So a shop audit of an online store can often be the trigger for improvements.