Going live with a Drupal website

Posted on 31/01/2016

Having a launch checklist is always a good idea, especially if you develop it over time. It will narrow down the chances of having issues before the launch and make sure that everything is in order.

This is an extensive list of settings and other details that should be checked before a Drupal website goes live. Most of the items are applicable for Drupal 6, 7 and 8.

Apart from the beginning and ending of the list, it's not important to follow the exact order.

In case you are already familiar with each item, here's the short list:

  • Backup everything
  • Set automatic backups
  • Using or not using www
  • Block common bot requests
  • Initial performance optimization
  • Update email addresses
  • Set up cron
  • Use strong passwords
  • Website analytics and monitoring
  • System updates
  • Integration with third-party services
  • User permissions
  • Delete or unpublish dummy content
  • Check status report
  • Private filesystem
  • Ecommerce websites
  • User registration settings
  • Test workflows
  • Disable unused modules
  • Error reporting
  • Update robots.txt
  • Backup everything and go live

Detailed explanations and reasons for including each item are below:

Backup everything

Before making any changes, make a full backup of the site. I usually mark this as "Last dev snapshot before going live".

The backup should include:

  • All code
  • Public file uploads
  • Private file uploads
  • The database

If later on anything goes wrong, you can always restore the backup and compare the data or code.

Set automatic backups

Make sure that you have scheduled automatic backups with the Backup and Migrate module and that they are actually stored. This is an absolute must for any website, and is something that is included in my installation profile. I usually go with daily backup for the past 30 days and keeping weekly backups forever.

Also, if you have the "Database Logging" module enabled, you might want to include the {watchdog} table in backups. The information there might be useful in the future (e.g. when you need to track past actions of a user).

Depending on how critical the data is, you might want to set off-site backups as well, such as uploading the backups via FTP to another server.

Using or not using www

Set the redirection to www.example.com or example.com. Read the comments in the default .htaccess file in order to see which lines you need to uncomment. Choosing one of these is a good development practice and will prevent inconsistencies for authenticated users when they go from www.example.com to example.com.

If not sure, redirect to www. Funnily enough, you can read today's discussion on HN on the same topic.

Block common bot requests

Malicious bots will always try to "scan" your website by "learning" about the system and then trying to break in. They particularly like WordPress as it's most used CMS, and many sites are outdated.

This means that they will try to visit many WordPress specific URLs that don't exist on your website. Even though this is harmless, these requests will take away the resources from your regular visitors. I have seen bots doing this even tends of thousands times per day, which does make a negative impact on performance.

I like to update .htaccess entries and give a fast response for URLs that will never exist on the site, such as those specific to WordPress or Joomla. This is easy to setup and there are no downsides.

Here's a gist:

Two notes:

  1. Bear in mind that pages with these paths will NOT be accessible anymore. This means that if for any reason you have a page with URL alias of /wp-admin, you will have to exclude it from .htaccess.

  2. Exclude the 404.html file in robots.txt by adding Disallow: /404.html.

Initial performance optimization

Drupal optimization is a separate topic, but you should always include the bare minimum:

  • Installing and setting up opcode cache on the server, such as APC (Advanced PHP Cache). This will speed up the execution of your PHP code. You should be good to go with defaults, but sometimes tweaking the settings can drastically improve the performance. See the official documentation as well as the following two articles.
    Keep in mind that APC might not be available if you are on a shared host.
  • Enabling the aggregation for static assets (CSS/JS) at /admin/config/development/performance. This will decrease the size of CSS/JS and reduce the number of server requests of each page.
  • Compressing the output on the page above.
  • Installing the Fast404 module. This will reduce the amount of memory used for serving a "Page Not Found" response.
  • Set cache for Views pages and blocks.

Update email addresses

Check if email addresses are the right ones. This includes at least:

  • Site-wide email address set at /admin/config/system/site-information.
  • Super-admin email address set at /user/1/edit.
  • Any other email addresses used in configuration. This depends on the modules you use, but chances are that you will have active Rules that send emails, so you can check that on /admin/config/workflow/rules.
  • If you are using the Webform module, check all nodes and see to which email addresses are the notifications sent.

Set up cron

Schedule cron and disable the one in core. You can do this at /admin/config/system/cron by setting the Run cron every value to Never.

Core cron should be disabled whenever you can set a real cron on the server. Otherwise, regular page loads will trigger the cron in the background, slowing the website for regular visitors.

Cron frequency depends on the website configuration and processes it needs to perform periodically. For regular websites, every 12 or 24 hours is perfectly fine. For fine tuning the cron and frequent processing, check out the Elysia Cron module.

Note: on some shared hosts you might not be able to set up server cron. In this case you'll have to use the cron in core. Drupal 8 has a separate module in core for this, called Automated Cron. This is part of the core for D7, and for D7 you will have to use the Poormanscron module.

Use strong passwords

  • Make sure that the super-admin (UID: 1) password is not easy to guess.

  • On critical websites, always have another admin account that will be used on day-to-day basis and for regular management tasks, e.g. manager.
    This is a good security practice - in case your computer or network are compromised you are lowering the chances of losing the control over that account. Also, regular administrators will not automatically bypass access checks (unlike the super-admin), which can highlight mistakes in site configuration and permissions.

  • If you keep test accounts on live sites, make sure that they also have strong passwords. Just edit them as administrator and set new passwords, in case you have too many accounts to check.

Website analytics and monitoring

Check if website analytics and monitoring services are set up. In most cases this consists only of Google Analytics, but can include other things such as Piwik and HeatMap.

If you are migrating the website to another domain, make sure that the tracking code is the correct one.

System updates

Enable the "Update" module, set it to daily checks and to send you emails whenever there are critical security updates available. You can do this at /admin/reports/updates/settings.

I recommend setting the threshold to Only security updates, as you will sometimes use a dev branch of the module. In such cases, the system will keep notifying you whenever Drupal.org generates a new development snapshot. You might not want to update immediately, because development snapshots contain code that is not thoroughly tested yet.

Integration with third-party services

If you are migrating the website to another domain, make sure that the keys are correct ones. Examples: reCaptcha, Mollom, payment processing keys, etc.

User permissions

Check user permissions and make sure that anonymous and simple authenticated users do not have access to any critical pages or settings. If you keep Devel installed on the live site, make sure that the Access developer information permission is granted only to administrators / developers.

Delete or unpublish dummy content

Delete all test content, and unpublish all content that is not ready to go live.

I usually navigate to /admin/content and search for "lorem", "test", "placeholder" and other keywords used for creating test content.

Check status report

Check status report page at /admin/reports/status, and see if there are any items that need your attention. Examples of things that can go wrong: undetected libraries, wrong file or directory permissions, missing configuration, etc.

This is also the place where modules integrating with third party services will report missing or incorrect keys.

Private filesystem

Make sure that private filesystem is not accessible over web. Even though Drupal will generate an .htaccess file that denies direct access, it's a good security practice. You can do that here: /admin/config/media/file-system.

Ecommerce websites

Make sure that the payments will be processed for real and with the right account.

If you have an SSL installed, validating it is a good idea. You can use this tool to make sure all certificates are properly set up and that browsers can recognize them.

User registration settings

Check if the user registration settings are properly set up. You can do this at /admin/config/people/accounts.

Test workflows

This really depends on your website, but here are some examples that need to be checked:

  • Search
  • Resetting the passwords
  • User registration
  • Contact form
  • Creating nodes as a regular user
  • Make sure that emails are sent and that you have good deliverability. This is a topic on its own, but if one of the big email providers (Gmail, Yahoo, Hotmail, Aol, etc.) keep moving your emails to junk, you have to deal with it.

Disable unused modules

If you will not change any configuration after going live, you can disable most of the UI modules. For example: Field UI, Views UI, Rules UI, Commerce related modules, etc.

In addition to this, you might want to disable modules used for development, such as Devel.

I recommend doing this only once you are done checking other things. If the site needs some final tweaks, you will need these tools.

Error reporting

Prevent all errors from being displayed on the screen. There are two places where you should do this:

  • Logging and Errors page in Drupal, found at /admin/config/development/logging. The setting should be set to None on live sites, and All messages on dev sites.
  • PHP configuration, by setting the display_errors value to Off.

I recommend doing this at the end, because in case you need to debug something in previous steps, having this enabled will point you in the right direction.

Update robots.txt

This is of course applicable only to public websites. Update robots.txt file and allow search engines to crawl your site. Use the default Drupal one, as it is shipped with common exclusions specific to Drupal. During the development you will most likely block the whole domain, as you don't want search engines to pick up placeholder content.

Backup everything and go live

Make a full backup of everything, just like in the first step. I usually mark it as "Going live".

That's it - now cross the fingers, push the green button, and good luck!