FREE MAGENTO CODE AUDIT REPORT

If you are running the Magento Code Audit on a test server, your performance grade may be really low. Most development servers have caching turned off — because if you make a change to the test site, you want to have it appear on the site without delay.

Poor performance grades can usually be fixed with better mySQL settings, and installing caching properly.

Customer Paradigm built the code audit tool, because we often work on sites that someone else built. And our code audit tool is a great starting place to figure out how the site was built. And if the previous development company took shortcuts in the process.

A site that has no core file modifications, no deleted or added files, and has a minimum number of third party extensions will rank with a score of “A.” A site with 23 third party extensions, and 51 core file overrides is going to rank with a “C” or a “D.”

The main issue when upgrading is that if changes have been made to the “core” files, any and all changes made to these core and base files will be wiped out when you upgrade. This means that if your developer changed a core file to display a fancy discount on the site, this change will need to be re-created in an extension or other area in order to preserve the functionality when upgrading.

So… why upgrade? Like most products, upgrading the software on your Magento site can give you new functionality, better performance, and patch security vulnerabilities. Certain new features or extensions will only work with the latest version or two of Magento.

Often, we’ll find that a missing PHP module can break functionality of a site… and can be a headache to troubleshoot.

The system checks for:

• curl – a module that allows you to send and receive information using URL syntax. It’s often used for URL-friendly rewrites, and works with the .htaccess file on Apache.
• dom – the dom extension allows Magento to work with XML documents through PHP programming.
• gd – the GD library allows PHP to create images automatically, and display them in the browser, including JPG, GIF, PNG, SWF, TIFF and others.
• hash – used for public key / private key encryption. Without hashing, any usernames or passwords in your database are stored as plain text. Not so ideal.
• iconv – allows php to convert a string into a encoded character. For example, if someone puts in an illegal character (perhaps they are overseas on a foreign language keyboard), the system can put in the proper symbol and translate if for Magento.
• mcrypt – used as an interface between PHP for supporting encryption methods, such as DES, Blowfish and more.
• pcre – used as a way to handle Perl-compatible regular expressions.
• pdo – used as a way to have PHP connect to a database.
• pdo_mysql – used as a way to have PHP connect directly to a mySQL database.
• simplexml – allows PHP to very simply and easily convert XML to an object in Magento, that can be processed by the system.

(This is a bit more technical, but understanding what modules are not installed for PHP allows you to understand why certain systems are not working properly.)

PHP safe mode is often used on shared servers to restrict what PHP scripts can do on a site. It’s often used to restrict or lock down specific functions, including moving, opening or executing files. PHP safe mode has been deprecated as a feature in PHP 5.3.0, and has been removed in versions greater than PHP 5.4.0.

• Files. Session management using files is much faster than using the database method.
• Database. Magento can keep track of past users in the mySQL database, but this means that each time a visitor requests a page, the system has to write their information into the mySQL database. This is slow, and not best practice.
• Memcached can speed up the Magento storefront by moving the session files to a highly optimized separate system.

If your site is on a test server or still in development, then it’s normal that these caches are turned off. But if your static blocks, layouts and EAV types are disabled on a live site, your site is going to be running a lot slower than it should.

Turning on these caches is something you are often able to do in your Magento admin panel. They might be disabled or invalidated if you’ve made major changes recently to your site.

Magento Enterprise has additional caching, including Full Page Caching. This allows you to have extremely fast (i.e. sub-2.0 second) page load times. The fast your site loads, the more sales conversions you are likely to see… as well as see better search rankings as well.

Magento modules are a blessing, because they allow you to have advanced functionality that isn’t built into the core Magento platform.

Want to integrate with a third party warehouse? Accept alternative payment methods? Display a red image for your t-shirt when the red option is selected on a product page? Extensions can do all of this, and more.

Without extensions, a Magento site is limited to only the functionality that is built into the Magento code release.

But extensions are often a curse. Because they can conflict with one another, and cause system instability. Our advice: only use the extensions that are absolutely necessary, and do rigorous testing to make sure that they don’t break anything.

When should you override Magento core files? Honestly, you shouldn’t. You can introduce system instability, and wreak havoc on your Magento site. It can make Magento extensions behave strangely. And if you ever want to upgrade, you’ll lose any of these changes.

Instead, you’ll want to make changes that extend core functionality by creating a module.

This section of the Magento code audit lets you know if your Magento Programmer has taken shortcuts and changed core files.

Magento works from a design “fallback” system, where if a theme doesn’t have a specific design option (i.e. the product grid on a category page), it will “fallback” to the base design files.

It’s much, much better to use a separate design than to go in and hack the base design templates in the system.

Again, if you upgrade your site, or even want to implement a new design for your site, your options may be limited if base files have been modified.

This is a great way to make sure that when you are copying a site from one location to the next, that you’ve copied all of the core files. (This won’t check for all of your modules or design files, though.)

It’s usually not a great idea to add new files to the core directories; Magento has a place for new files to live. Again, you’d likely lose any of these files in an upgrade.

Often we’ll see a breadcrumbs-copy.phtml, or a bookmarks.xml.backup-01-01-2014 file, which is a server-based copy of a file. This isn’t a big deal. It usually means that someone was working on that file, and created a live backup on the server, so that they could quickly revert if they messed something up.

If the number seems larger than you expect, it may be because this report will show the simple products that are used to make up a configurable product. For example, if you have T-shirt that is sold in four sizes (S, M, L, XL) and three colors (Red, White, Blue), then you would have 4 x 3 = 12 simple products:

• Small – Red
• Small – White
• Small – Blue
• Medium – Red
• Medium – White
• Medium – Blue
• Large – Red
• Large – White
• Large – Blue
• X-Large – Red
• X-Large – White
• X-Large – Blue

But on the front end of the site, it would be listed as a single configurable product on your Magento storefront.

Magento recommends a value of at least 256 MB. On a dedicated database server, this setting can be 80% of physical RAM.

On a server where memory is shared between the database and application, this number should be around 40% physical RAM. Ideally, this value is larger than the size of your database.

Your server is set to run several different threads from PHP and Magento to the system at the same time. If this is set too low, then the site slows down to a crawl, because each person coming to the site essentially has to wait in line for the mySQL database connection.

Magento recommends a value of at least 8 threads running at the same time. If possible, this value should be set as high as the maximum (16).

This should be set to a minimum of 8 (the default is 0). On a server with a large amount of memory, it can be set to 32 or 64.

Note, this may be a false positive on Mysql5 installations, as in Mysql 5 a concurrency of 0 is unlimited.

Magento recommends a setting of at least 100.

This is the amount of memory that is allocated per thread. The sort buffer size is a per-session buffer that is allocated each time it’s needed by a database connection. The sort buffer is often used when there is no index available in a mySQL database table.

We recommend the key buffer size is set to at least 200 MB for optimal site search speed.

The larger the buffer pool, the more the database acts like an in-memory database, and avoids having to look up information fro the hard drive. (This speeds up performance.)

We recommend this is set to at least 15 MB for best lookup time on your Magento site.

A version of mySQL that is too new might be a red flag if you are running a much older version of Magento (i.e. Community 1.4) that wasn’t designed to run on a more current version of the mySQL database.

The mySQL database is limited by the disk space on the server. If fill up the hard drive, any tables that you’re trying to write to will often become corrupted. It’s a quick fix to repair those tables, but you’ll likely need to run a script to go through every single table in Magento’s mySQL database to do this.

And Magento, by default, has a lot of tables. Magento Community has approximately 327 mySQL tables, and the Enterprise platform has about 450 mySQL database tables.