Drupal site go live checklist - ben600324/wiki GitHub Wiki

Here's a list of the most basic stuff I usually check when putting a site live. Of course this will change depending on what modules you have used and that sort of thing, but should be applicable to most Drupal sites.

Enable your Performance settings

This is an important one! Enable page caching, as well as compression and aggregation of your CSS and Javascript files (/admin/config/development/performance). This will improve your page load times substantially and reduce your database load. It's also a good idea to include all JS and CSS files within your themes .info file so that they are aggregated and compressed too. Besides only using the default in-site caching you should also consider using things like APC, Memcache, Varnish...

Ensure your settings.php file is read-only

When in development you may have been making regular changes to your settings.php file. Make sure it's read-only on the production environment.

Check robots.txt file

Make sure that this is configured correctly, particularly if you’ve disallowed all pages in order to stop the search indexes from spidering your site prior to go-live.

Check your BaseURL and Cookies settings

If you have either of these set in your settings.php file - they aren't by default - then update them to your live domain settings.

Update your database settings

Change your database connection settings to reference your production database.

Change your admin & account passwords to something secure Quite often you use a simple password, like 'password' while in development phase.

Check the account creation & administration settings

Check the details of who can create accounts, and what the process is around that. If your site is only going to be accessed by anonymous users you'll probably want to set it so that only Administrators can create new accounts. This isn't set by default and you're likely to end up with a load of spam account creation requests.

Check you have enabled your Analytics tagging

I usually disable analytics for in-dev sites so as not to impact on the live site stats. In fact even on live I usually disable analytics for users logged in as admin.

Check your file system configs

Update your file system paths if they happen to be different on your production environment (/admin/config/media/file-system).

Disable & uninstall modules that aren't being used

Quite often you may end up with modules that aren't being used. Disable, uninstall and delete these completely as they can still impact on your sites performance.

Disable Developer Modules and any other debugging

Unless you have a specific reason you should disable these on production sites. This includes things like the Views UI, Context UI & Field UI.

Remove the Drupal 7 generator meta tag

By default a meta tag is included on D7 sites which identifies them as being built on Drupal. This is unnecessary and from a security perspective could be used to identify Drupal specific sites for attack. If you use the metatag module you can disable this under the global settings, otherwise there is a specific module for this: https://www.drupal.org/project/remove_generator

Once live check you've disabled maintenance mode

Not something you're likely to forget, but worth mentioning just in case

Are the File Permissions set right?

This is one of the top items in our pre-launch Drupal checklist. To secure your Drupal website, the first step you must take is to set the file permissions right. Make sure your web server is not given permission to edit or write the files that it executes. Automated tools to set and verify permissions like File Permissions and Security Review Module, can also be used. The PHP Filter Module under /admin/modules needs to be disabled, if your site is using Drupal 7. The settings.php file should be secure so that the database connection information is protected.

Drupal Security Updates?

Drupal has been a choice of Content management system for various organizations but particularly so for organizations that deal with critical data. The reason why Drupal is known to become a secure CMS is because of the Drupal security team’s constant effort to keep it safe. With every major/minor release, security updates are shipped out. Many of them address immediate security risks. You will get warning messages when your Drupal security has lapsed. Make sure your Drupal 8 release is up to date with all the security releases and patches. Keep your modules and core updated. You could also check for security updates manually by clicking on Reports and then checking for Available Updates.

Secure your admin’s account name

The Admin account is the root account that is used for any Drupal website development. Securing the root account is very important and should not be ignored. The installation is extremely vulnerable to hacker attacks as it isn’t hard to guess the username for the hacker. So the root account name should be changed to a more complex one (before launch at least) and a strong password must be used. You can use the Real AES module to tighten up your security. Also, when granting user permissions, ensure minimal permissions are given to anonymous users and all permissions granted to them should also be given to authenticated users.

Don’t let your users see those Error reports!

Because it can get very annoying. Error reporting should be turned off such that it must write the errors onto a log but does not display it to the users. To disable error reporting, go to Configuration > Development > Logging and Errors, set the option to None, which will disable all the error reporting. It should be ensured that 404 errors are handled well. Using Drupal modules like Search 404 helps in displaying more helpful content like search results based on the URL the user has been searching for.

SMTP

SMTP? we have to check credentials if that for production site

CRON jobs?

These time-triggered actions can help in checking for updates, re-indexing the search mechanism, retrieving feeds, notifying other sites of updates and perform routine maintenance tasks. It is also recommended to configure CRON for security and performance reasons.

Server Configuration

Check the file upload sizes. This is to allow users to upload large media files from your Drupal website. To do this, you may need to adjust the server configuration. It is also important to check the execution time. You can do so by setting the max_execution_time in the server configuration. Also don’t forget to check that all the forms and modules are being sent to the correct email addresses.

Content and Search Engine Optimizing for your Drupal website

You must ensure that your site content is displayed correctly. Don’t forget to run your site through the Lorem Ipsum scanner before launching.

Email address check

Site speed

After having turned on caching mechanism, make sure to test the website for speed and performance. PageSpeed Insight, GTmetrix and Pingdom Website Speed Test is the one we use.

Third Party API

Do you have any third party that need API key and domain authorisation updated? (Eg. Lockr, Google Captcha, Google Map etc) Usually they have different values for dev, test and live. Make sure it’s all good.

SEO

Sitemap, Pathauto, Redirect, Metatag

Captcha

Check the watchdog for errors and warning, and fix these

Page speed check (PageSpeed insight, GTmetrix, or Pingdom Website Speed)

Do we need install PHP accelerator like APC, Memcached etc?

References

https://drupalsun.com/rick-donohoe/2015/06/25/drupal-go-live-checklist-revisited https://www.specbee.com/blogs/prelaunch-drupal-checklist-for-your-website http://drupalden.co.uk/drupal-site-go-live-checklist https://marameodesign.com/insights/our-website-launch-checklist-essential-checks-before-you-go-live/ https://www.arpatech.com/blog/drupal-pre-launch-checklist-for-developers/ https://dominiquedecooman.com/blog/drupal-7-tip-how-automate-and-control-your-go-live-checklist