So you’re ready to launch your new website. What things do you need to check to ensure you haven’t overlooked something important? Or worse still left tools used during development enabled that could lead to security issues.
This is my list which is a skewed towards Drupal on Linux servers however I'm sure there will be elements that are useful to others:
Server
Preparation
-
Take a full backup of the development (and existing site if replacing one)
-
Make sure you have a failover option ready in-case you need to revert
Security & SPAM prevention
-
Check Status Report, Available Updates and Site Information pages
-
Ensure best practices are followed for Security & SPAM prevention
Permissions & setup of key modules
Performance
-
Use Advanced CSS/JS Aggregation module instead of core aggregation
-
Disable poor performance modules when other services are better choice
External Services
General Housekeeping
-
Audit users accounts and ensure all admins use a secure password
-
Check site-information / email addresses are all correct for live environment
-
Test email sending works (site messages, contact forms etc..)
-
Site Click through, remove any test content, unneeded users etc...
Server
1. Setup Apache hosting on production server (gzip, cache headers)
The detail of setting up your Apache hosting could fill several articles and I’ll probably write some in due course. Suffice to say that some of the important items are:
- Ensure you know where your document-root is located so you know where on the server the application files need to reside.
- Try and enable mod_deflate to compress outgoing files for bandwidth and speed optimisation
- Try and enable mod_expires to set cache headers so web browsers will try and cache items like images and CSS which are often reused, saving time and bandwidth on subsequent page requests.
2. Setup SSL certificates if required
Again this could be the subject of its own article. Sometimes there can be a lead time depending on the type of certificate desired, so getting started early might be useful. For now I would simply suggest looking into a service called: Let’s Encrypt
3. Setup PHP, MySQL as required
This will be application specific, so this is here mostly as a reminder that you’re likely to need some form of scripting language and most likely a database too.
4. Any extra services? Git, Email, Memcache, Varnish etc…
Again this is going to be pretty specific to the application, so again it’s here as a reminder.
Preparation
5. Prepare DNS for going live
DNS has an inherent propagation time / delay as servers across the world renew their caches. So if you’re migrating your site to a new server you might want to start creating some temporary sub-domains (such as old.domain & new.domain) that can be aliased on the server. This will aid in redirecting users to the new server once the changeover has happened in order to reduce delays whilst propagation of the main domain takes place.
If it’s a new site its only the time taken for the root DNS servers to pick up the details, but even still it is always good to get a head start.
6. Check if CDNs are configured correctly for live environment
If you’re going to be using CDNs (Content Delivery Networks) to aid in delivering your website quickly and at scale, then you’ll need to check that you have them ready and configured for a live site, and not just your development environment.
7. Take a full backup of the development (and existing site if replacing one)
Sounds obvious, and it’s here mostly as a reminder. That way it shouldn’t get overlooked in the rush to get your website live.
8. Make sure you have a failover option ready in-case you need to revert.
If you’re migrating from one application / server to another, it might be wise to understand what would be required to roll back the deployment. Sometimes things don’t go to plan and it might be useful to roll back to the old application. That way you can continue providing a service in the time it takes to correct whatever problems might have arisen during the deployment, prior to attempting it again.
Security & SPAM prevention
9. Check Status Report and Available Updates pages
Check the Status Report page at: /admin/reports/status
This page lists a great deal of useful information from the core requirements of Drupal such as php and database versions, memory limits, cron runs, through to add on modules and their status / requirements. The status report is colour coded and any issues will be highlighted in red and typically have a link to a configuration page or the documentation to help you resolve the issue.
Check the Available Updates page at: /admin/reports/updates
This page lists the Drupal core version plus all the modules currently in use, and indicates for each whether an update is available. Where practical it is best to be running the latest version of Drupal core and modules as they will incorporate fixes for any vulnerabilities known to the community. Thought you might want to consider that new bugs or regressions can come with updates so it’s worth running tests against updates before using it in a live environment.
10. Ensure best practices are followed for Security & SPAM prevention
Make sure file permissions for sites/*/files directories and code directories are set correctly, in general this means ensuring your codebase has read only permissions for group and world users, and execute permission for directories to allow traversal. The ‘files’ directory should be writeable by the web-server to allow for uploads, either by way of the web-server running as the user that owns the sites/*/files directory structure or via group write access. Finally your settings files should be set to completely read-only to prevent changes once final updates have been made. For more information see the Securing file permissions and ownership page on Drupal.org.
To check you’ve not forgotten anything try to run the ‘Security Review’ module on the production environment: https://drupal.org/project/security_review and review the output for any issues.
Ensure any customisations or added code are upholding best practices by analysing the results from ‘Coder’: https://www.drupal.org/project/coder or better yet use an IDE with code sniffing / linting features such as PHPStorm (see the following for setting up for Drupal: https://confluence.jetbrains.com/display/PhpStorm/Drupal+Development+using+PhpStorm) to have this available to you at all times during development.
If your site allows end users to add content (like articles etc…) then check: /admin/config/content/formats
Depending on your version of Drupal one of the following: ‘Filtered HTML’, ‘Basic HTML’, ‘Restricted HTML’ or ‘plain text’ should be set as the default for authenticated users to help prevent cross-site scripting attacks. You should also check the configuration of those format(s) available by default to authenticated users to ensure that the ‘Limit allowed HTML tags ...’ checkbox is enabled to strip out potentially dangerous tags. Ensure also that the following tags are not in the allowed tags list (further down the page): <img>, <embed> or <object>.
If the ‘Better Formats’ module is enabled, check the default formats assigned to the various roles are sensible for the type/authority of the user. Consider who has access to what, and be mindful about how some tags can be abused before allowing them.
If you have forms on your website that can be submitted by end users, and bear in mind this also includes the sign-up form on the login page, then you’ll want to protect your forms against spam and attacks. Check what kind of contact forms are available to anonymous and authenticated users on your site? Have you installed and enabled modules such as: CAPTCHA, reCAPTCHA, Honeypot? Alternatively you could use an external anti-spam service.
Finally try to make sure that all publicly exposed email addresses are protected from spam bots with solutions like Spamspan, Invisimail or a custom obfuscator.
11. Disable Developer modules
Developer modules often provide a great deal of additional information on page loads or privileged access to the system. These are greatly useful during development to understand what’s going on, especially so for debugging.
However on production servers they can have several drawbacks, firstly they add additional bloat both to the processing side and the delivery bandwidth which slows down the website’s load time. Additionally from a security perspective they add additional attack surface area, and what’s more they could provide an attacker with elevated privileges allowing them to compromise more parts of your website / server.
You should at least disable, if not completely remove development modules such as: devel, coffee, stage_file_proxy, hacked etc...
Also depending on the type of use the website is expecting some of the UI modules such as: field_ui, rules_ui, views_ui might not be required for regular day to day use. These modules could be re-enabled if required whilst adding new functionality and then disabled again for performance benefits.
12. Disable any theme specific development settings
Most themes have a number of development settings to help speed up development. These should be turned off when going live to remove any performance hit. This is likely to be different for every theme but a good place to start is the settings links for the active themes on the ‘Appearance’ page: /admin/appearance
This is also a good chance to disable (and remove) any themes which are not being used.
13. Disable error messages being displayed to screen
From: /admin/config/development/logging
Set “Error messages to display” to ‘None’. This prevents any embarrassment, or confusion for your end users that start seeing error messages on the page.
Also remember to check your settings.php file for any hard-coded development error settings similar to the following:
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
$conf['error_level'] = 2;
These will need to be removed or commented out whilst the site is live.
14. Remove .txt files from core
Whilst it’s practically impossible to completely obfuscate Drupal’s usage on a site, given there are lots of small tells, what we can try to do is make it difficult for an attacker searching for a specific version, for which they might be trying to exploit some known weakness or issue.
Drupal is a large open source project, which often means good software with fewer security vulnerabilities since lots of eyes on the code usually results in problems being spotted early. However occasionally things get through as people don’t immediately see the threat. On those occasions systems may be vulnerable until they are updated to the latest security release version.
During the period between release of a new security version and the time it takes to update your server(s) it’s better that you not be broadcasting your specific version. Most attackers will scan servers looking for very specific files which might indicate a version with a weakness, rather than trying all theirs exploits in a brute-force method. It’s far more efficient to scan for a few files, then deploy a particular exploit if a specified file is found, so don’t make it easy for them by leaving your exact version number lying around in plain sight!
Remember to leave ‘robots.txt’ in place though, as it performs a special function. Also remember to edit robots.txt back to standard if it has been edited during development to restrict search crawlers etc...
Permissions & setup of key modules
15. Permissions
On the Permissions page: /admin/people/permissions/list
Verify what permissions anonymous and authenticated users have been given. Try to ensure users have the absolute minimum amount of permissions required to achieve what they need to on the site and nothing more.
Use the roles functionality in core Drupal to group together related permissions. Remember users can have several roles at any one time, allowing functionality to be granted to them as and when required, plus it can also be revoked once no longer required.
Be very careful with granting any of the various ‘administer’ permissions to a role as these often grant a large amount of control over the configuration of the website. These should really be reserved for an ‘Administrator’ role and granted only to users who are both competent and trustworthy.
The 'View Media' permission from the 'Media' module actually bypasses other file control and should only be for administrators. Also if one or more node access modules is in use (workflow access, og access, content access etc) be careful to ensure that node permissions are not given which would prevent access from being determined by these modules.
Once permissions are set, create a test user for each role, log in as them and try using the site the way they would to check they access to what they need and nothing more. (Hopefully this was done earlier during QA, but this is your last reminder!)
16. Content types & nodes
Visit the Content types page: /admin/structure/types
Check to see if there are any content types created during development that are not being used. If there are, confirm the type can be removed, and if so delete that content type. Delete any dummy nodes that were created during development for testing.
17. Pathauto
From the Patterns page: /admin/config/search/path/patterns
Make sure you have path generation patterns for all major content, taxonomies and user entity types. This can be achieved by either setting up a generic pattern for each major entity type such as content, and then including each and every bundle (specific content types, like: Article, Basic page etc), or create a number of bespoke patterns for one or more different bundles as required.
Updates for the Settings page: /admin/config/search/path/settings
Change general settings for 'Update action' to something other than 'Create a new alias. Delete the old alias.', which is more appropriate during development. In most cases 'Create a new alias. Leave existing alias functioning' is appropriate for production. This is because a live site will over time accumulate in-bound links to pages, and you most likely wouldn’t want to loose that traffic as a result of change of path alias.
In combination, you can set redirects to be automatically created when aliases are changed with the 'Redirect' module at: /admin/config/search/redirect/settings
18. Views
Check the Views page: /admin/structure/views
You may wish to delete any development views no longer in use to de-clutter the views list and make it easier to manage.
If you wish to maintain and track changes made to your views via a version control system like git you’ll want to ensure all views have been exported to code. For Drupal 7 use Features to export views to a features module, and then check through the views list to make sure none of the views are in an overridden state. For Drupal 8 use the Configuration Management interface: /admin/config/development/configuration Or alternatively use the Drush command: drush cex
Public facing views, especially on the home page and on sites with a lot of authenticated traffic, should be configured appropriately for caching. This can be done within each view’s edit page by checking under the ‘advanced’ section which may be collapsed if still using the default views (global - not view specific) settings.
19. Email
Check the Contact form page: /admin/structure/contact
Plus if using the ‘webform’ module: /admin/config/content/webform
Make sure email recipient addresses are set correctly for the various contact forms and / or webforms.
If using a modules such as ‘reroute_email’ or ‘mail_redirect’ etc..., remember to disable that module after informing all developers and QA users that email is going live.
Performance
20. Configure performance settings
Visit the Performance page: /admin/config/development/performance
For Drupal 7: Within the ‘Cache’ field-group area enable ‘Cache pages for anonymous users’ & ‘Cache blocks’ by clicking in the checkboxes if necessary. Drupal 8 has caching enabled by default (unless disabled in the maximum age drop-down selector) and intelligently too thanks to cache tags. For all versions of Drupal check that the ‘Page cache maximum age’ is set to an appropriate time, consider how often you might update pages and how long it’s acceptable to have them cached for before the updates start to show.
For Drupal 7 enable ‘Compress cached pages.’, Drupal 8 removed this feature. I assume it was removed to simplify the codebase, if truly required a better option would be to enable compression within Apache / Ngnx (and then potentially cache with Varnish at the edge of the network)
Enable ‘Aggregate CSS files’ and ‘Aggregate JavaScript files’. This brings together several files into fewer files, which reduces the number of HTTP requests required to the server thereby speeding up the overall time required to fetch the page from the server.
For Drupal 7: 'Block caching' should be enabled, unless there is help text on the form warning otherwise. Minimum cache lifetime of cached pages should be set to an hour for most applications, or as you feel is appropriate for the website.
For extremely active sites you may wish to consider adjusting Drupal’s default session lifetime values. Drupal keeps a copy of every session in the database and relies on the standard PHP garbage collection routine to clear them. This happens every time a session is started i.e. a page load request, for Drupal 7 there is a module for adding this to the cron tasks to lighten the load for page requests from a visiting user. The configuration element you’re looking for is 'session.gc_maxlifetime' which can be found in a an ‘ini_set()’ call in settings.php for D7 and for D8 as a parameter in the ‘sites/default/services.yml’ file.
Check for full URLs (i.e. starting with http(s)://...domain...) in node bodies etc. and convert them to relative URLs if they are pointing to local content on the same domain as the website. Links to external sites using fully qualified URLs are fine. The client may have put in fully qualified URLs during testing that won’t work when the site goes live (due to protocol or domain mismatch). A good tip is to search in a tab-separated database dump, and fix or flag to the client anything you find.
21. Use Advanced CSS/JS Aggregation module instead of core aggregation
Core Drupal offers some aggregation for CSS and JS, but it’s a bit patchy especially when it comes to compressing. You would be well advised therefore to install and use the Advanced CSS/JS Aggregation module: https://www.drupal.org/project/advagg
This module allows finer grain control over the process, plus options to control the order / placement of CSS / JS includes within the generated HTML output. This can be useful for pushing render blocking items into the footer of the delivered HTML. This provides a perceived speed increase to the user as the page can be rendered earlier by the browser whilst CSS / JS continues to download in the background. This can also have some sideeffects on the way the page looks initially until all the required CSS / JS has download and could be considered detrimental. You’ll have to way up the pros and cons of what bits to you chose to use, but overall the module brings a great deal of extra control to the process.
The main reason you may want to embrace it often comes down to how fast Google consider your site to be which might be a factor in page ranking now or in the future. For more information take a look at Google’s Pagespeed Insights tool.
22. Check log messages and fix any apparent issues
If you have the core database logging module (dblog) enabled you can check the the list of log message at: /admin/reports/dblog
If you’ve chosen to use a different system you should hopefully know where it’s writing its output.
Most messages will be ‘notices’ which can often be ignored, ‘warnings’ and ‘errors’ on the other hand deserve more attention. Often you can filter the messages by type and or severity which can be useful to de-clutter the output. Certain errors, if they reoccur can fill up the log, so be sure to ensure you set the system to maintain an appropriate amount of records before overwriting old messages.
Every log message requires a database write (for the default ‘dblog’ module) so a large list of regular and reccurring messages can have an 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. Consider building this maintenance into your client contracts.
23. Check 404 and 403 reports
Not found / Forbidden errors could point to potential problems. Not only should these be checked prior to going live, but they should be periodically rechecked to ensure end users aren’t suffering from recurring 404 or 403 errors.
If you’re using the core ‘dblog’ module you can check the reports at: /admin/reports/page-not-found and /admin/reports/access-denied
If you’re using some other form of logging such as syslog etc… you’ll have to track down your log files or use the web-server’s logs.
Look out for entries which have an unusually high count. Once you’ve found these question whether they are a problem and if so get them fixed.
You may find some strange entries like “wp-login.php”, these will be from bots looking for the presence of a particular application (Wordpress in this case), probably for some no-good reason. They’re a nuisance and difficult to block, so you’re probably best filtering them out once you’ve determined it’s not genuine missing content.
24. Install & Enable Fast 404 module
Fast 404 is a module that assists Drupal for requests to the server that attempt to access a non-existent page location or file. All requests are first handled by the web-server (Apache etc…) looking for the requested item; if it’s a file the web-server returns it and all is well.
If the request doesn’t map to a file that exists, then it is assumed that it is a page location or other resource delivered by Drupal, at which point the index.php is executed with the path passed as an argument. That causes Drupal to bootstrap and determine whether the requested item is a path for which it has content, in the case where the request is for a non-existent item this process is quite resource intensive just to return a 404 status code.
These problems are exacerbated if the 404 is as a result of bad links on the page being loaded to a resource such as a graphic element, or style-sheet, as all these requests will arrive at the server in quick succession. This ties up memory and other resources which might block / delay other requests from being serviced. For a more in-depth discussion see this Acquia blog article.
Installing the Fast 404 module (https://www.drupal.org/project/fast_404) can improve the Drupal core handling of these non-existent files in a fast and less resource intensive manor. That in turn will leave your server’s precious resources available to serve more useful requests.
25. Disable poor performance modules when other services are better choice
Depending on your needs and how much traffic you need to be able to scale up to, there may be some modules that you’d be better off ditching in favour of a more performant option. The following is a quick overview of some of them, plus the rationale. The list is not exhaustive:
- Boost module: Good to continue using for smaller sites, but once traffic builds an in memory cache like varnish would probably serve your needs better.
- Database logging core module (dblog): The Syslog core module can store logs much faster, because it does not need to write to the database.
- Server-side statistics modules: Instead, use client-side statistics services, such as Google Analytics or Omniture.
26. Remove unused modules to cut down the bootstrap time etc...
During development it’s common to try out various community contributed modules whilst in search of solutions to the needs of the project. Occasionally you even replace some modules along the way as the development process adapts to changes in the specification. Sometimes the unused modules remain enabled despite no longer being used. Ideally a log should be kept during development of why a particular module was chosen to be used and what functionality it provides to the site.
Before going live it’s useful to try and find, disable and / or remove these unnecessary modules. Partly is good practice to de-clutter but there’s also a small performance gain to be achieved.
Upon starting to handle a request Drupal goes through a process called bootstrapping. This is where all the useful features like starting up a database connection, assessing what modules are installed etc... are set in motion. As part of this process Drupal runs through a list of the enabled modules and for each: it calls that module’s initialisation function. These initialisations could be lightweight and fast, though that’s not guaranteed, but either way they all add up.
For those modules that serve no purpose on the website the time and resources spend initialising them is totally wasted. Additionally extra resources might be wasted in adding elements to the page during rendering. As well as adding to the waste these extra items of functionality might even serve to confuse end users or content editors.
There are also a number of Core modules that could be contenders for uninstallation depending on your website’s needs, these include: Color, Comment, Dashboard, and Help. Dashboard and Help simply add more links to the menu which can unnecessarily confuse content editors.
External Services
27. Enable and configure Google Analytics module
Enable the Google Analytics module and add your GA Property ID at: /admin/config/system/googleanalytics
Tracking your website’s usage is often critical. Google Analytics is a free service and a good starting point for most websites. Make sure you have it correctly configured with a live Property ID upon launch. During development you’d be wise to override the Property ID on dev and test sites, that way your analytics results won't be skewed by internal traffic from your development sites.
28. Ensure all External Web Services are setup correctly
If you’re using any external services, now is the time to ensure they are correctly configured and / or activated. Sometimes this activation might need to happen using the remote service’s website / controls such as for payment gateways etc…
A non exhaustive list of potential services includes:
- Social Media services like Facebook, Twitter etc…
- Anti-Spam services
- Font delivery networks
- Video streaming networks
- External email server
- Advertisements networks
- CDN’s or Caching networks
- Payment gateways
- Merchant receiving bank accounts
29. Setup Cron, Syslog
Cron allows for scheduled services to be run on a server. Whilst all Drupal 7+ sites contain the functionality of the old “poor man’s cron” module which piggybacks a Drupal cron run onto a page load request, it’s better to configure the server to run the Drupal cron process in a scheduled manner. By scheduling the cron process a more predictable time period between cron runs can be established and adjusted for the site’s needs.
Syslog is a more performant way of logging in comparison to the default database logging (dblog module) where the cost of writing to the database is several times more resource intensive than syslog. Also syslog can be scaled by the use of a dedicated server if required, whilst reducing the load on any dedicated database infrastructure you might be using. As a result you’d be advise to configure syslog and disable the old dblog module on a live website.
General Housekeeping
30. Audit users accounts and ensure all admins use a secure password
It’s easy when developing a website to desire simple login credentials such as: “admin” account name with the password “pass” for easy access. So ensure all admin users have now set a secure password if they haven’t already.
Also check there aren’t any users with the admin role that you don’t want to have full access to the website. Ideally this role should be developer only and your content editors should use another role with reduced permissions.
31. Check site-information / email addresses are all correct for live environment
Check the Site Information page at: /admin/config/system/site-information
This page holds the most common site information, such as the website name, slogan, email address and the default front page. It's worth checking that all of this information is correct. It would be embarrassing if your first series of emails arrived from [email protected] rather than the proper name / domain of the website.
32. Configure basic SEO practices
SEO is a large topic area and these tips are just some of the basic / technical best practices.
For a head start on some of the more complicated technical elements install the SEO checklist module and work through the checklists elements implementing those that make best sense.
At a minimum try and ensure the following are attended to:
- Redirect traffic from the non-www version of the domain to the www version (or vice versa) to avoid the site being indexed twice. This can be done using the .htaccess file in the root of the Drupal site.
- Check you haven’t left anything like “Disallow: /” in your robots.txt file which would have been used to prevent Google crawling your site during development.
- Lock-down your dev and test environments to ensure these aren’t accessible by random visitors or crawled by Google. Using HTTP Basic authentication might be one way to achieve this.
- Ensure you have added, enabled and configured the Global Redirect, Redirect and Pathauto modules to provide consistent naming of paths with fallback redirection of old paths orphaned by way of a rename.
33. Check SSL works & redirects correctly
If you’re using SSL encryption you’ll want to check you have a properly trusted certificate on the server as opposed to any self-signed certificates you might have been using during development. Make sure you can visit the site in a browser using HTTPS without getting any warnings about the certificate. Check the ‘secure’ indicator padlock in the browser has gone green in colour, hover / click for further details and ensure they match your expectation of the newly installed certificate.
Lastly depending on how you’re using the SSL functionality check that site redirects too HTTPS immediately upon the first request. Or switches to and from HTTPS as and when required if only using it sparingly, say for securing form submissions, sensitive information etc...
34. Test email sending works (site messages, contact forms etc..)
Email is easy to overlook given it doesn’t prevent the website from loading, but often highly integral to the smooth functioning of the website. For instance websites with user login access need to be able to send emails for such things as sending replacement passwords for user’s who’ve forgotten them.
Contact forms are another prominent source of emails, often transferring messages from end users to website’s owners. Check that all the various contact forms are both correctly configured with the appropriate recipient email addresses and that form submissions are successfully emailed.
35. Site Click through, remove any test content, unneeded users etc...
For a small website without a formal QA process, a simple click through of the main admin / content areas should be performed. Make sure to do this for all available user roles including as a logged out ‘anonymous’ user.
Click around and make sure there are no broken links and everything looks okay. Remove any test content, such as "lorem ipsum" text, or content generated by the Devel module if found.
Lastly remove any dummy users that where added for testing purposes during development.
36. Internal Search Indexing etc…
If using internal search on you’re website, be that using the core ‘search’ module, or ‘Search API’ + ‘Apache SOLR’; has all the content been indexed? Indexing is often performed on Drupal cron runs a few pages at a time to avoid long running processes hogging server resources. As a result it’s possible that not all content is indexed. It might improve the website’s functionality if the index is fully built prior to going live. This can be achieved by manually triggering the process as required until all content has been processed.