Taking over an existing site from a contract developer or company that doesn’t primarily build Drupal sites (or even some that do) can often be a daunting task.

Often we find our clients assume that all Drupal sites are created equal, and as we’re taking it over we can just dive right in and start developing. Unfortunately that’s not always the case so we end up doing a site audit.

A site audit accomplishes a couple things:

• Provides the client with an overview of where their site currently sits in terms of performance, security and general quality of the build.
• It provides us with a good knowledge of the estimated effort needed before “diving in”.

Firstly, we never touch the live site so it’s important to grab the up to date code and database and load them into our local development server where we’re free to run our audit tools.

Hacked!

The first tool we generally run is Hacked! which very quickly lets us see if any contributed code or the Drupal core has been modified. Sometimes modifying code is a necessary evil when modules need to be patched to provide functionality that is not currently committed to the module. More often than not though, it’s quick hacks to provide custom functionality for the site which is a big no-no for us. Hacking contributed code prevents us from updating the modules easily and can introduce exploitable code that goes unchecked by the drupal community. Hacked! currently needs to be present in your sites’ modules folder for the drush command to work, but if you apply this patch to a download of Hacked! placed in your Drush modules folder it’ll be available as a standalone Drush command.

Site Audit

The Site Audit module provides us a general overview of common config options that should generally be set in a production environment without manually checking them. This can give you a good idea of how performant the site is so if speed has been an issue for your client’s site then this can help. Site Audit runs as a standalone drush command and, even better, can report on Hacked!’s status with this patch.

Security Review

The Security Review module does similar checks to the Site Audit module, but with a focus on security. An important one is making sure that inputs don’t accept PHP and that no PHP or Javascript code is currently contained within nodes and comments.

The next few things are where you’ll have to get your hands dirty and actually dig into the site and it’s code.

• You’ll want to check for custom modules and take a look at what they’re doing.
• Take a look at the watchdog table if logging was turned on for the site. You’ll want to see if any modules are causing things like PHP warnings, errors or 404’s.
• Also make sure you take a look at the theme(s) enabled on the site. You’ll want to check things like the number of templates, the code in the templates and most importantly check for any funny business in the template.php file.

These aren’t the only things we do, but it’s a quick ten foot view of the site that can give us an idea of the effort involved in taking on a new client’s site. Typically we’ll generate a report for a client with the aggregated information from our various reports and provide it to a client with a recommendation for next steps.

Let us know how you perform site audits in the comments!