A Drupal Pre-Launch Checklist

There are numerous steps you should complete before launching a new website; cross-browser testing, checking for dead links, proof-reading. These are covered more than adequately elsewhere but in this article I'm going to look at a number of steps applicable specifically to launching a Drupal site. You may not agree with them all, but then none of the following are compulsory - these are just my personal recommendations.

There are numerous steps you should complete before launching a new website; cross-browser testing, checking for dead links, proof-reading. These are covered more than adequately elsewhere but in this article I'm going to look at a number of steps applicable specifically to launching a Drupal site. You may not agree with them all, but then none of the following are compulsory - these are just my personal recommendations. Rather than simply list them as bullet points, I've tried to give some of the rationale between these tasks, and pointers to online resources where I can.

Server Configuration

Configure Cron

Drupal provides an extensible number of Cron jobs scheduled to run at varying intervals, such as re-indexing the search mechanism and checking for updates. Contributed or custom modules may define their own Cron jobs, from retrieving the latest Twitter feeds to processing message queues. Whilst it is possible to run a Drupal site without ever needing to run Cron, it's highly recommended that you do so - the Update status module in particular is well worth using to help maintain the security of your website. There is good documentation on setting up Cron for Drupal in the official documentation. Alternatively you may wish to look at Poor Man's Cron, though this is simply a backport of automatic cron-running functionality offered in Drupal 7.

Check the maximum file upload sizes and max_execution time

If your site facilitates uploads of large files - such as MP3 files or videos - ensure that your server is configured to allow file uploads up to an appropriate size. In conjunction with this, look at the max_execution_time setting, which may well get exceeded if you're uploading particularly large files.

Check recipient email addresses

Check that all forms, modules and so on are sending to the correct email addresses - it's very easy to forget to update these once you go from development (your own addresses) to a client's.

Security

Set the file permissions

It's vital that you correctly configure the security permissions on your filesystem in order to secure your site from malicious hackers. In particular, you should ensure the security of your settings.php file, which contains your database connection details. Note also that to facilitate uploads and so on your files directory needs to be writeable by the web server, and you should ensure your installation is configured with access to a writeable temporary directory. The official documentation contains a useful article on securing file permissions and ownership, and the installation guide contains information about the files directory specifically.

Protect your root account

Typically you'll build your site using the default administrator account - the one you set up upon installation - but do remember that this account has full access to your website. Not only that, but the havoc which could be wreaked by a hacker getting access to this account could, network security not permitting, be carried out using nothing more than a web browser. You may select any username you wish; rather than, say "admin" you can make something altogether more difficult to guess. Ensure you're using a strong password. Some people recommend that this account be disabled altogether, though this can complicate things when it comes to upgrading modules etc; something you're likely to need to do often. As an aside, the password hashing mechanism used in version up to and including 6 is inherently insecure; you may wish to use a module such as AES to toughen up your security.

Check Permissions

Luckily new permissions introduced by installed modules tend to default to being pretty restrictive, and have to be manually enabled for other roles (whether anonymous, registered or custom). One of the flip-sides of this is that it can be easy to set up parts of a site as the root user only to find some way down the line that normal users can't access things which they ought to be able to access. Always test the site under each role carefully before launching.

Turn off error reporting

I'm still amazed how often I see Drupal error messages on live sites. It's not just Drupal-specific messages either; PHP errors can be rendered by Drupal itself. You can opt not to display system error messages and warnings in Site Configuration -> Error Reporting; set the option of the same name to Write errors to the log so that they aren't displayed to the user.

Error Handling

Handle 404 errors gracefully

Do ensure that you cater for missing pages (404 errors) in as helpfully as possible. One (deliberate, I might add) feature of Drupal's built-in 404 handling is that a page is displayed without any blocks, even if those blocks were set to appear on every page. As such, often your navigation disappears from the page when you get a page not found error. Consider using a module such as 404 blocks (renamed 404 Navigation in Drupal 7) for this, and perhaps a module such as Custom Error to define specific error pages. If you want to go the extra mile you may even wish to use something like Search 404 which upon displaying a page not found error, tries to second-guess what a user was looking for by feeding terms from the URL into the search engine.

Search Engine Optimisation

Combine Pathauto with Global Redirect

If you use the Pathauto module to automatically generate "friendly" URL's (and I can't recommend that step highly enough), you should install a module called Global Redirect as well. This module works by analysing a visited link and if an alias for it exists, it performs a 301 redirect to the aliased path. For example, suppose contact-us is an alias for node/123, and somehow or another a user visits node/123 directly; Drupal will redirect back to contact-me. Why is this important? Well, if a single page is accessible from multiple URL's, this - at least as far as Google is concerned - can impact negatively on your search ranking.

Check robots.txt

If appropriate, check your robots.txt to ensure that the relevant sections of your new site are excluded from crawlers. There is some documentation on robots.txt in Drupal on the official site.

Maintenance

Create a Maintenance Page

Should you need to take your website down for any length of time, such as during a site upghrade, it's worth thinking about what a visitor will see if they visit your site during that period. What a user gets by default is pretty unfriendly and somewhat unprofessional. Luckily - at least from Drupal 6 onwards - it's pretty easy to create a custom maintenance page. For Drupal 6, the official documentation contains some useful information on theming the Drupal 6 maintenance page.

Performance

Configure Caching

Caching will deliver significant performance boosts, particularly on high-traffic sites. Ensure that you've configured it in the Performance tab, but also, double-check any pages or blocks created by the Views module; these have their own caching options which are generally switched off by default.

Configure CSS and JavaScript Optimisation

One of the by-products of Drupal's modular system is that a typical site will probably have scores of JavaScript and CSS files, increasing the number of HTTP calls for every page significantly. (As an aside, if you have a lot of modules it's actually quite easy to hit Internet Explorer's limit of 31 links.) Fortunately you can "squeeze" all the relevant CSS and JavaScript files, compressing them at the same time by enabling this feature in the Performance section. This is a typical last-minute configuration, as generally you'll need this facility switched off during the development process.

Content and Publishing

Check Unpublished Content is not Visible

In certain tasks, for example, when creating a view - and not to mention when writing custom code - it's very easy to forget to check the status of a node before displaying it. Thus, draft content could appear on the website before it's ready. Try adding a few items of content, leaving them unpublished and browsing the site trying to find them. Double-check the filters on your views. Check that any custom SQL includes a check of the status column.

Check your RSS feed

By default Drupal generates an RSS feed of your content, including individual feeds for your taxonomy terms. The default feed is comprised of published nodes which have been promoted to the front page - a facility which isn't always relevant. In Drupal nodes can represent all sorts of things, which might not always be logical to publicise in a feed. Blog entries or new stories very much belong in a feed, static pages less so. However you may also have various other pages and objects that it doesn't make sense to syndicate; custom error pages, confirmation pages or landing pages, for example. You could consider implementing your feed(s) using the Views RSS module, which allows much more finely grained control over what goes into your RSS feeds. In any case you may wish to disallow access to rss.xml altogether.

Check your favicons

If you're going to use a favicon, make sure it's displaying correctly - and if not, ensure that you unselect the option to display Drupal's default favicon in your theme settings.

Site Monitoring

Configure Statistics

It's not just the security and reliability of your site you might want to be monitoring - you may wish to (and indeed probably should) monitor site usage, be it using the core statistics module - perhaps using the Advanced Statistics settings companion module - or an external service such as Google Analytics.   Have I missed anything? Please let me know using the comments below.