Why Audit?

Catalog Technical Debt

Coined by Ward Cunningham

http://c2.com/cgi/wiki?WardExplainsDebtMetaphor

http://c2.com/doc/oopsla92.html

ifsworld.com

• We get caught up in work and don't pay down the debt.
• Often don't have the vision that we are in debt.
• Hard convince a product owner.
• Auditing the the first place is the right step.

xkcd

We don't need to "Fix the world with software."

On the flip side. carried away

"good enough"

The Checklist

How to use this document.

• Assess: Build a mental model.
• Action: Make a recommendation.
• Estimate: Cost to fix.

• Often the action is just to document something.
• Remember that estimates are just estimates.

What you will need

• Access to code
• Copy of database
• Admin accounts
• Shell/remote access to production/staging environment

Stand up a copy of the site.

Review status of site on host. Reports > Status Report

Can be done without admin access, but will be incomplete.

General Best Practices

Quick Checks

Prod Check https://www.drupal.org/project/prod_check

(admin ui that expands on status report)

Site Audit: https://www.drupal.org/project/site_audit

(drush commands generate reports)

Hacked!

The Drupal Patching Ecosystem

Patching modules is extremely common.

Secure Pages requires a patch to core.

A patched module is harder to update.

There is a process

The point is to document these modifications. And share!

drupalroot/
patches/
  project/[project]-[description]-[issue]-[comment]-[core-version].patch
                        

https://www.drupal.org/patch/submit

And there should be an issue filed in the project's queue. Even if it just supports your use case!

Any custom code follows Drupal coding standards (https://www.drupal.org/coding-standards).

You don't need to memorize these! https://www.drupal.org/project/coder

Use the API

$view->display['default']->handler->options['filters']['changed']['value'] = '2025-04-30 00:00:00';

Vs.

$filters = array();
$filters['changed'] = '2025-04-30 00:00:00';

$view->set_exposed_input($filters);

Documentation

It exists, is correct, and ideally, focuses on the why, over the how.

// When the number of items exceeds the visible items,
// resetting the width will collapse the size to
// the viewport width and cause all items be in view.
if ( numItems >= visibleItems ) {
    return;
}

Other tidbits

• Use of $_SESSION for anon users.
• Heavy use of includes (dozens).
• Is version control in use?
• Location of webroot in VCS (exception: Pantheon)

Modules

Site Configuration / Architecture

How were pages engineered? Was the approach done in a best practices manner?

Blocks < Context < Panels

• Block system rendered, then placed.
• Block and context gives you tunnel vision.

Is configuration tracked?

Exported to Features/Config Management.

Are exported features cohesive? They should be restricted one feature per bundle type, not one single, site-wide feature.

File system

images/field-name/[year]/[month]

Security Review

This spans site code/config and the hosting environment.

Modules are up to date with security releases.

Risk levels defined

No “PHP fields/Input modes” are used on the site.

This isn't just a security issue. Try indexing solr with a drupal_goto().

High access input formats are only granted to appropriately vetted users (e.g. full html should be restricted to trusted roles).

Anti-spam technology is required for any open user registration.

• Captcha
• Honeypot
• Mollom
• Community manager

• I've seen databases 90% composed of user spam.
• Some legitimate, well-intentioned users just aren't going to provide high quality content.

The hosting environment is up to date.

Hosting Vs. Managed Hosting.

• Big diff between hosting and managed.
• F1 patched ~60 servers against the bash-shock vulnerability within hours.

Any development or staging instances of the site are hidden from unauthorized access/search indexing.

Any unused user ssh or (s)ftp user accounts are discontinued.

ssh uses public/private key authentication instead of passwords. At least 2048 bits.

General web-server best practices:

Nginx

Apache

Hosting Environment

What is the current update status of software packages? (php, mysql, apache). Note PHP 5.3.3 on RHEL 6 systems is vendor supported.

php memory limits (We normally use 192MB)

This will vary, anything 512 and over would be an indicator of problems in the way the site was engineered.

F1 client ~12 gigs.

If APC is used shm size (~96MB - 128MB)

APC is not a very good general back-end cache for Drupal. Poor fragmentation hits performance.

Size wil vary. Default is never adequate (64MB).

More if APC is back end.

Don't use it as a back end. Especially for page cache.

Front End

CSS well architected. Avoid duct tape themes.

Overuse of templates?

Display Suite!

Business logic in theme layer?

The only if statements should be checking that a variable is set or not empty.

Process

Deliverable requirements. What does the client expect from your support?

As a subcontractor, may not know. But should learn what steps are being taken.

One site I know of, they were just unzipping over the existing installation. Which did not delete/move files.

Opportunities

General opportunities for improvements

Upsell your services!

• Analytics
• UX/Design
• Solr Search