Drupal go-live checklist (revisited)Jun 25th 2015

A handy tool for every developers arsenal: a simple go-live checklist! When a site is finally ready to launch it can be easy to get excited and forget some of the important details, but having a checklist to hand can prevent any last minute slip ups. 

Here's my own personal checklist and below it a further description of each item with some hints and tips. Leave me a comment if you have any questions or think I've missed anything important!

Go-Live Checklist

1. Check Status Report and Site Information page
2. Disable Developer modules
3. Disable any theme specific development settings
4. Disable error message display
5. Configure performance settings
6. Check log messages and fix any apparent issues
7. Check 404 and 403 reports
8. Ensure custom 403 and 404 pages are in place
9. Enable and configure Google Analytics module
10. Ensure all Web Services are setup correctly
11. Audit users accounts and ensure all admins use a secure password
12. Ensure best practices are followed for SPAM prevention
13. Configure basic SEO practices
14. Test email

...and here's those points explained in detail:

1. Check Status Report and Site Information page

You should always start by checking the status report - /admin/reports/status. This page shows you all of the basic requirements for your Drupal site to run correctly.

Any issues will be highlighted in red and typically have a link to a configuration page or the documentation to help you resolve the problem. This page will also tell you when Cron was last run; this is important for periodic jobs to be fired off, so make sure it has run recently (default is every 3 hours), and if it hasn't then ensure you debug that issue.

The site information config page holds all of the most common site information, such as the website name and email address.

It's worth double checking that all of this information is correct. It could be quite embarrassing if your first newsletter arrives from dev@example.com.

2. Disable Developer modules

Developer modules unnecessarily bloat your website so these should be disabled when going live. If they haven't been configured out the box then you can safely uninstall these too without worrying about losing any information.

It’s quite common to cram your website with contrib modules only to find out that numerous modules haven’t actually been used or were replaced by a similar module later in the development process, so these should be removed and uninstalled too.

There are also a number of Core modules we regularly uninstall such as Color, Comment, Dashboard, and Help as these Core modules are often unused on your average Drupal site. In our opinion Dashboard and Help simply add more links to the menu which unnecessarily confuse content editors.

3. Disable any theme specific development settings

This may be completely different for every theme but most themes have a number of development settings to help speed up development. which should be turned off when going live to remove any performance bottlenecks created by them.

This is also a good chance to disable (and remove) any themes which haven’t been used.

4. Disable error message display

Nice and simple; head to /admin/config/development/logging and set “Error messages to display” to “None”. This prevents any embarrassment and confusion created when your end users start seeing error messages on the page which to them will look like technical gibberish!

5. Configure performance settings

The site performance page - /admin/config/development/performance will allow you to configure a number of options to help optimise your Drupal site. This includes page caching and optimising CSS and JavaScript files.

See our series on High Performance in Drupal for some expert tips - High performance in Drupal Part 1: Give your site a boost and High performance in Drupal Part 2: Lightning fast code.

6. Check log messages and fix any apparent issues

Assuming you have the core database logging module (dblog) enabled you should have a list of log message which can be found at /admin/reports/dblog

Most messages will simply be notices which can be ignored,  though often there may be certain errors which saturate and fill up the log. Each log message requires a db write so a large list of regular messages can have a large impact on site performance. One example of this could be an undefined variable which doesn’t appear to cause any issues, but creates an error message to be logged on every page view.

It is good practice to regularly check the error log and periodically fix any recurring errors which are being reported.

7. Check 404 and 403 reports

Not only should these be checked prior to going live, but they should be periodically checked to ensure end users aren’t suffering from recurring 404 or 403 errors. Simply check both reports - /admin/reports/access-denied and /admin/reports/page-not-found - and look out for entries which have an unusually high count. Once you’ve found these question why they are a problem and get them fixed. If you have the URL Redirect module enabled there should be a simple link you can use labelled “Fix 404 pages with URL redirects”.

You may find some odd entries like “wp-login.php”, though these will just be from spam bots so they can be ignored.

Another little tip: Some of your links may not  appear in this report as they work, but are still problematic as they’re actually links to your development or test sites. Enable Pathologic as an input filter to help find and remove any of these.

8. Ensure custom 403 and 404 pages are in place

This is a nice little touch which doesn’t have to take any longer than 5 minutes. Simply create two basic pages; one for your 404 page and one for your 403 page, then set them as up under /admin/config/system/site-information.

The aim of these pages is to funnel lost visitors to other areas of your site to help them find what they were looking for. Some people choose to make these as simple as possible whilst others put a bit more “flare” into them. For some inspiration check out 33 brilliantly designed 404 error pages.

If your site uses the Search module you could also try utilising the Search 404 module - this handy little module performs a search on the keywords in the URL of the page which can't be found.

9. Enable and configure Google Analytics module

The first thing you want to do when you launch is check out your visitor stats; though the last thing you want to see is that none of this data exists because you forgot to setup Google Analytics properly!

Simply enable the Google Analytics module and add your GA Property ID under /admin/config/system/googleanalytics .

For best results we recommend overriding the GA ID on dev and test sites, that way your analytics results won't be skewed by internal traffic from your development sites.

10. Ensure all Web Services are setup correctly

Many web services such as Mollom or Typekit require a domain name specific API key to use. If you use any of these services on your website, you should ensure that you've registered your real domain name with the service and you've updated Drupal with your new API key.

11. Audit users accounts and ensure all admins use a secure password

It’s easy when first developing a site to use a simple login such as “admin” with the password “pass” so ensure all admin users have set a secure password if they haven’t already. We recommend using a tool like LastPass to generate and remember strong passwords.

Before you go live double check there aren’t any users with the admin role that you don’t want to have full access to the site. Ideally this should be a developer only role and your content editors should use another role with reduced permissions.

12. Ensure best practices are followed for SPAM prevention

The pro’s and con’s of different Spam modules and techniques is a story for another day, but there’s a few basic steps you can take:

• If your site doesn’t use comments then disable the comments module. If it does, ensure permissions are correctly setup and that comments are only enabled on the content types they are required on.
• Check the “Who can register accounts?” setting - /admin/config/people/accounts. If your only users are administrators simply change this to “Administrators only” to avoid an influx of spam user accounts.
• Use Honeypot or Mollom to help reduce spam on contact and comment forms.

13. Configure basic SEO practices

This will be covered in a later blog post in further detail, but there’s a few tips you can use to ensure your site gets a head start here:

• Redirect traffic from the non-www version of the domain to the www version (or vice versa) to avoid the site being indexed twice.
• Check your haven’t left anything like “Disallow: /” in your robots.txt file which would prevent Google crawling your site correctly.
• Lock your dev and test environments to ensure these aren’t accessible by visitors or crawled by Google.
• Ensure you have added, enabled and configured the Global Redirect, URL Redirect and Pathauto modules.

14. Test email

Ahh, good old we-nearly-forgot-about-it email. You’d be surprised how many sites have issues sending email, especially when you have smaller self-hosted sites where there is no key reason to check this.

Fire off a forgotten password email when the site is ready on the liver server and ensure it reaches you OK without being sent to spam.

Personally we prefer using Mandrill on any of our sites which rely on email. Mandrill is a free tool which helps prevent email being marked as spam and provides details of all outgoing mails in a clean, easy to use interface.

Written by: Rick Donohoe, Account Manager

Microserve is a Drupal Agency based in Bristol, UK. We specialise in Drupal Development, Drupal Site Audits and Health Checks, and Drupal Support and Maintenance. Contact us for for further information.