Deploying a drupal site - Considerations and a handy checklist

If you are deploying a drupal site to production for the first time OR even doing it after a really long time, here are a few things you should probably consider:

Note:-
1. This page mentions Apache, MySQL and Linux but the principles apply to Nginx, PostGreSQL and other databases,  and other operating systems too.
2. Some of the advice is not Drupal specific but more to do with the environment in which Drupal runs. However, it is important to consider them all holistically to get the best setup for your site.

Security:

1. The first thing to do after deploying your drupal site is to change the $drupal_hash_salt in your settings.php. Never keep this the same as your other environments. In addition, it is best if you keep this in a file system outside of your docroot.

2. Check the status report. The status report is an excellent guide of mistakes in your deployment. A good module will also report here of any mis-configurations. Fix all the problems listed here especially updating modules that have security fixes.

3.  Make sure the permissions setup for the different roles in the site are appropriate. Since this list can be quite long, its best to scrutinize this carefully line by line. Especially, make sure you aren't granting more than is necessary for anonymous and other untrusted roles.

4. Remove all generic user accounts you may have created during testing. Make sure all active users on the site are named users you can track and audit actions of on the site.

5. Add a brute force module (such as login_security) to make sure your users logins aren't compromised. You may also consider TFA (albeit this module is still in Beta).

6. Set Error Message display to None. You wouldn't want to inadvertently disclose additional information of how your website has been built.

7. Ensure the docroot file/folder ownership (recursively) is setup to something other than the webserver user account. E.g. devops-admin:devops-users. Also change the permissions to something like 755 so the webuser can traverse through the folder structure. The two exceptions to this are the settings.php (and any files included within this file) which should be set to 444 and the sites/default/files (or equivalent as setup in the File System settings) where drupal stores files created and uploaded that require the webserver user write permissions (the same goes for the Private file system if you are using one).

8. If using the Private file system of drupal, then make sure its outside of the docroot.

9. If you are using Git on the production server, make sure you keep this outside of the docroot (by using the GIT_WORK_TREE environment variable) OR atleast block access to the folder and its contents through htaccess OR in the Apache config itself.

10. Ensure you have a firewall configured (such as by using tools such as ufw OR directly using iptables) to block everything except traffic you must allow in . Also make sure services such as mysql, redis aren't directly exposed to the internet and aren't listening on all ports if they don't need to.  In addition to the firewall on the server, make sure you are also using the firewall of your service provider such as Amazon EC2 Security Groups  effectively.

11. Setup SSL for the site. This is both good for security as well as SEO.

12. Update the server with the latest updates for the operating system, services such as mysql.

13. Create an application specific mysql user with a strong password and assign appropriate rights to the drupal db to this user only. Use this user in settings. php for your site.

Performance:

1. Assuming you have done everything you can to optimize your code itself (and adding appropriate indexes to your tables), turn on Drupal Page and Block caching if that is appropriate for your setup. Set the Minimum Cache Lifetime to a high enough number (depending on how often your site's content is refreshed) and the Expiration of Cached Pages setting (which tells proxy servers for example how long they can serve up stale pages).
In addition, turn on Aggregate/Compress CSS and Aggregate JS files too. Make sure you have tested your site with all these settings well in advance, because some of them may have unintended consequences and require you to rejig your code.

2. Turn off all modules that you aren't likely to need on production such as Devel, Views UI etc.

3. Turn off unnecessary extensions in PHP and Apache.

4. Consider the use of Varnish and one of  Redis, MongoDB or Memcached. These can seriously improve your site's performance if you get or expect a lot of traffic and your pages don't have to rebuilt afresh for every page request. Drupal has contributed modules for each of these that work fairly well with these software.

5. Turn on any additional drupal modules that you can benefit from based on the functionality available on your site. Some examples are Boost (to enable file based caching as opposed to Database caching of drupal), Entity cache, Varnish , Memcache API, AuthCache etc. A full list can be found at https://groups.drupal.org/node/21897. As always, test thoroughly before enabling on production.

6.  Make sure you are serving minified JS and CSS (some contrib modules help here but can be done without them too).

7. Make sure the images on your site are optimised to be the least size possible.

8. Test your site on https://developers.google.com/speed/pagespeed/insights/ to make sure Google sees your site as performant. Ideally, conduct this test while you have a close to actual load simulated on the site using tools such as Apache JMeter.

SEO: 

1. Make sure your robots.txt isn't blocking any css, javascript or images that Google and other search engines should be accessing. Check what Google can and cannot see based on your robots.txt configuration by testing it in the Google Webmaster Tools under Fetch as Google.

2. For the below points use tools to detect these such as the Moz Bar.

a. Make sure you don't have duplicate pages (pages with different urls but the same title). If you need to have them for some reason make sure you set up the canonical url to the one common url on both the duplicate pages. The drupal metatag module is excellent and useful in setting these up.

b. Ensure you have no duplicate page titles. This can happen especially when you have pages that are in a paginated series. Set the titles up to display the page no. too in such cases using drupal tokens. Also, if you can (this would likely involve writing code),  setup the meta tag rel="prev" and rel="next to the next and previous pages in the series. For paginated series, ensure you don't have a canonical url setup so google doesn't think all the pages have the same content. Also, if you have facets being used to filter content, make sure you aren't creating several paths for google to index that essentially don't add any further new pages with new content. This can be controlled in the robots.txt by disallowing certain page parameters so google doesn't needlessly traverse through every facet.

3. Setup meta descriptions, snippets, social tags (such a og:) appropriately for your pages.

4. Ensure if you are using both www. and the no www. version (naked domain) for your site,  you have the canonical url setup for one or the other consistently across all pages.

5. Use the excellent XML Sitemap module to generate a sitemap for your site. Ensure you only have pages in there that need to be indexed by Google. Check the URLs on the sitemap to make sure that you aren't pointing to default pages that Drupal generates (such as for taxonomy, all content items of any content type etc) that you haven't themed or don't want visitors to see directly. Add a 404 redirect in addition to such pages or add a noindex meta tag and ensure they aren't linked within any of your pages. A good tool to scan your website for such links is Xenu that can crawl your website's links.

6. Ensure that you have got all the 301 Redirects setup correctly if you are migrating over from an old site.

Monitoring:

1. Setup something like NewRelic or Pingdom to ping your website periodically with real user monitoring (RUM) setup. These give you useful alerts should your site go down for some reason OR is giving users a slow experience.

2. Setup server level monitoring using your cloud services provider's tools (such as Amazon EC2) or tools such as NewRelic agents, Munin, Nagios etc. to monitor disk space, disk i/o, cpu , network i/o, memory utilisation, service uptime etc. These can be useful to give you alerts of impending risks on your site.

Miscellaneous:

1. Ensure Site Information in Drupal is setup correctly with the Email address, 404 and 403 pages setup correctly.

2. Set Cron to run at an interval suitable for your website

3. Create SPF records for emails that you are going to use if your site sends out emails.

4. Add favicons for all devices. A useful tool for this is http://www.favicon.cc/?

5. Ensure you are using the correct SMTP server, third party service logins (e.g for AddThis, Google Tag Manager, 3rd party APIs used on the site etc) .

When you have run through this checklist, you should be quite confident of launching your new Drupal website.