Drupal Deployment Checklist
Here is a short list of things I check before finishing a new deployment.
- Database logging row limit (admin/settings/logging/dblog)
- I have found the default row limit of 1000 can wrap quickly, leave you without vital debugging information when you need it most. The average row length is generally around 1kB, so even boosting this to 100,000 rows will still leave you with a manageable watchdog table.
- User registration settings (admin/user/settings)
- The default value of Visitors can create accounts and no administrator approval is required is easily overlooked, and often undesired.
- Disable devel modules admin/build/modules
- Not only devel itself, but other other utilities (such as masquerade, trace, or coder) may have been installed that you wouldn't need on the production site. Leaving extra modules enabled can hinder the performance of your site, or even create security vulnerabilities if misconfigured.
- Set a maintenance theme (settings.php)
- By default Drupal's Site off-line page uses the Minnelli theme. Switching this is a nice enhancement, in case you ever need to use the maintenance mode, or in the unfortunate event you experience unplanned downtime. In most cases your site's theme will work fine; just add $conf['maintenance_theme'] = 'mytheme'; to settings.php. You may also need to add a maintenance-page.tpl.php to your theme; if you're using Zen this is already done for you.
- Confirm email settings
- Often, placeholder email addresses will be filled in during development, and should be updated before deployment. I try to start with the correct addresses from the beginning when possible, but sometimes you don't have this information until later in the project's life. In addition to Drupal's global site_mail, addresses can be stored in a variety of places: The admin user's account, contact forms, webforms, ubercart, triggers, or CiviCRM settings.
- For Zen users – disable theme registry rebuilding (admin/build/themes)
- If you developed your theme using Zen, don't forget to switch off Rebuild theme registry on every page. This is a huge performance penalty.
- Error reporting (admin/settings/error-reporting)
- On a production site, it's best to suppress on-screen error reporting by choosing Write errors to the log.
- Performance settings (admin/settings/performance)
- The best performance settings depends on your site. Also, don't change cache settings at the last moment without thoroughly testing your site's features. Ideally, I like to finalize the cache settings about 2/3 of the way through a project, so that the final stages of development and testing are performed with cache settings that will match production.
- Redirect to/from 'www.*' (.htaccess)
Drupal's .htaccess file contains an example RewriteRule showing how to redirect from example.com to www.example.com or vice-versa. Enforcing a single domain name is essential if your site uses SSL, and even with plain HTTP I like the consistency of a single URL.
Additionally, since the RewriteCond declaration is specific to a particular host, you can add multiple domains to the same .htaccess file, either for multi-site installs or for multiple testing / production host names.
- Check proxy settings
If your production server uses a proxy or load balancer, Drupal needs some additional configuration to accurately record remote IPs. This impacts error logging and some modules such as Mollom.
$conf['reverse_proxy'] = TRUE; $conf['reverse_proxy_addresses'] = array( '10.10.20.100', '10.10.30.100', );
- Setup cron job
- Don't forget cron!
What are your favorite last-minute checks? Post them below!