Support / Maintenance travailsWhy and how to audit legacy sites

Suchi GargTechnical Team Lead

Introductions!

→ Business Owner perspective

Maintenance contracts?

→ Developer Perspective

“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”

Maintenance contracts?

Site Audits!!In comes the Savior

To put simply - audit is a runthrough of the implementation of the Drupal site.

is a Site Audit?

A Drupal site audit is a process to establish a clear baseline about how a Drupal website is built and configured and how it functions. The site audit provides the foundation for knowing what is required to get your site to meet its business objectives. Unless a site is exceptionally well-documented, current and accurate, the audit is necessary before additional work is done to the site by a developer other than the one that built it. This avoids creating new problems on top of any that may already exist.

→ Acquisition Audits - generally done before buying new sites/ businesses→ Implementation Verification Audits - A customer wants to validate work done by their vendors -

usually very brief engagements.→ Vendor Management Audit - Done to switch vendors when the existing vendor is problematic→ Support Audit - Again very brief - but needed when the system needs to be moved to be

supported by a different entity.

Types of Site Audits

to do an audit?

→ Site Audit helps us in understanding the exact “health” of the install - which in turn helps in

contract negotiation.

→ 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".

Ideally site audits should be done before the contract is signed.

BEFORE you actually write a single line of code.

The second best time to get a site audit done

Get a local install done.→ Get the FULL source code

→ Get the complete DB. If the data is sensitive - ask for obfuscated date.

→ Install the site on a local server/ localhost.

→ Try to understand the architecture

to do a Site audit?

Tools Needed

This module scans the currently installed Drupal, contributed modules and themes, re-downloadsthem and determines if they have been changed. Changes are marked clearly and if the diff module is installed then Hacked! will allow you to see the exact lines that have changed.

Hackedhttps://www.drupal.org/project/hacked

The Site Audit module provides us a general overview of common config options that shouldgenerally be set in a production environment without manually checking them. This can give you agood idea of how performant the site is so if speed has been an issue for your client's site then thiscan help. Site Audit runs as a standalone drush command.

Site Audithttps://www.drupal.org/project/site_audit

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

Security Reviewhttps://www.drupal.org/project/security_review

While not essentially a site audit tool, we always make sure to run our sites through Coder as well.Coder checks the Drupal install against coding standards and other best practices. A note here – itruns through the contributed AND the custom modules and themes.

Coderhttps://www.drupal.org/project/coder

→ Check the update status of core as well as contrib modules - have the latest security patches been applied?

→ You'll want to check for custom modules and take a look at what they're doing. Focus on

▪security holes▪performance problems▪beginner mistakes▪Was the custom module needed?

→ Take a look at the watchdog table if logging was turned on for the site (Or look at the syslog). 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.

→ If possible - talk to the original developers of the site - they might even tell you pain areas - be polite!

Usually a report is submitted after site audits - which has the following components:

→ Introduction - What is the site’s purpose, basic architecture, platform and modules used. Also discusses the implementations on a high level.

→ Findings - Lists out all the findings - both positive as well as negative→ Improvement areas - what needs to be done to fix the problem areas

of a Site Audit?

One word -

can do a Site Audit?

Questions?

Thank You