Call it a “site audit” or a “health check”, from time to time we all should take a look at our Drupal installations and see how much of a mess we have made. A Drupal site audit is like a physical, you do it to make sure that things are running smoothly and catch issues early, if they exist. But just like yearly physicals, we all try to avoid site audits for as long as we feel healthy.
Site audits are important for many different reasons. A site audit helps identify the spaghetti code or bad practices that tend to get into your Drupal installation over the course of time, and allows you the opportunity to do something about it. It helps you keep code organized and makes future development and on-boarding new developers to your project a lot faster. Every time we take on an existing Drupal project, we always do a site audit and let our clients know what it would cost to first fix the mess and then work on the enhancements they are looking for.
Doing a thorough site audit can be challenging. Depending on the complexity of the site you are taking on, it may be weeks worth of work. But there are a few relatively quick things you can do that will take you 80% of the way there:
- Run the Hacked! module: This module will let you know if Drupal core or any of the contributed modules have been hacked and show you where those hacks are. Hacks are never a good idea and if hacks to contributed modules are absolutely necessary, these should always be done as patches and properly documented.
- Use the Coder module: The Coder module has two parts, Coder Review and Coder Upgrade. Coder Review is really helpful during a site audit as it identifies problematic code that needs changing because of changes to the Drupal API. It will also point out code that does not conform to Drupal coding standards.
- Look at Drupal Reports: The default Drupal reports are a great help too. The Status report is where you should start, as it will tell you the problems identified by Drupal. Looking at the Available Updates report will immediately let you know how far behind the site is in terms of code upgrades. And finally take a look at the Recent Log Messages report and in particular the error log from there to see how frequently the site has been generating error messages.
- Database logs: Take a look at the database logs too. For example, for MySQL take a look at the slow query log. This will help identify performance issues with the site that might require attention.
- Third party services: There are third party services that can be utilized, such as GTmetrix that lets you see your site’s performance metrics, or Wave that identifies accessibility issues on your site.
This is by no means a complete list. There is more sophisticated technology, such as Acquia’s Insight, which will give you a more comprehensive report of your site’s health, but you would need to be hosted on Acquia for this to be an option. However, this list gives you a starting point - a way for you to figure out how big of an undertaking it would be to bring your installation up to standard, before you can even start thinking about adding more features.