Best Practices for Configuring and Managing Drupal

Drupal Version

Before you take a Georgia Tech Drupal site live, it is a good idea to go through the following checklist of best practices to make sure your site is secure and streamlined for production use. This checklist is designed for Drupal 7 sites on OIT's Web Hosting, but will generally apply to other environments and later versions of Drupal as well.


Within the Drupal Application

Helpful Tip: The admin interface can be accessed via the black admin toolbar at the top of any page when logged in with administrator rights.

Make Sure Core, Module, and Theme Updates Get Applied When Needed

Enable the Update manager using the following settings so that you and your team will be notified of important available updates.  Then, make sure those updates get applied in a timely fashion (but be sure to back up your site before doing so: more information on backup is below, in case anything goes wrong).

If you are using Drupal 8 or higher (considered modern Drupal), the site now needs the Composer CLI tool to manage installation and updates for Drupal core and any modules, due to more complex project dependencies.

Recommended "Available updates" Settings

Located at: Reports -> Available Updates -> Settings (admin/reports/updates/settings)

  • Check for updates: Weekly
  • Check for updates of disabled modules and themes: Yes (unless on a multi-site, where only 1 site should check this)
  • E-mail addresses to notify when updates are available: At least TWO (2) email addresses (preferably some office-wide emails).
  • E-mail notification threshold: Only security updates

Limit Access to Your Site

Avoid giving out any more access than necessary

  • Make sure you have a suitable user account role for content managers that does not let them install modules, change themes, adjust low-level Drupal settings, etc.
  • Ideally, only trained IT and/or web development staff should have administrator or super administrator privileges

Review your User Account List Regularly

Remove (or block) accounts of users no longer working in your unit; blocking is often the better option, as that maintains tracking of what those users did. Removing the account will require all content changes to be attributed to the "anonymous" user.

Review your Role Permissions Regularly

Roles are what map Drupal access permissions to individual users.  Review the list (found at People -> Permissions) to make sure roles do not have unnecessary permissions that put your site at risk.

Recommended "Account settings" Settings

Located at: Configuration -> People -> Account settings (admin/config/people/accounts)

  • Anonymous users - Name: Visitor
  • Administrator role: Super Administrator (for Drupal Express sites only; for all other sites: Administrator)
  • Who can register accounts?: Administrators only
  • Require e-mail verification when a visitor creates an account: Yes.
  • When cancelling a user account: Disable the account and keep its content.
  • Personalization
    • Enable signatures: No
    • Enable user pictures: No

Enable GT Account Authentication

  • Most Georgia Tech Sites should use GT Account Authentication, which is provided by the CAS (cas) module
  • Drupal Express has the CAS module already installed
  • For all other sites, see the Installing CAS section for installation and configuration instructions

Recommended "Text formats" Settings

Located at: Configuration -> Content authoring -> Text formats (admin/config/content/formats)

  • Order matters: place "basic text editor" at the top/first, then "minimal HTML", etc.
  • "Plain text" is the only format to which Anonymous users should have access.
  • If "PHP code" is present, DO NOT allow anyone to use it!

Configure Error Logging Securely

Drupal and PHP error messages shown to regular users could reveal sensitive details about your site, and just look unprofessional as well.  Use the following settings to hide error and warning messages from site visitors and keep them from overflowing your site's database.

Note: Do not enable the core syslog module if you are using OIT Web Hosting. According to the syslog module documentation, it is not appropriate for shared hosting. You should be able to find most useful debugging information by going to the Logs section in the OIT Web Hosting Control Panel and looking at the error logs.

Recommended "Logging and errors" Settings

Located at: Configuration -> Development -> Logging and errors (admin/config/development/logging)

  • Error messages to display: None
  • Database log messages to keep: 100

Enable Caching to Improve Site Performance

Recommended "Performance " Settings

Located at: Configuration -> Development -> Performance (admin/config/development/performance)

  • Caching
    • Cache pages for anonymous users: Yes.
    • Cache blocks: (Depends on how often your blocks change)
    • Minimum cache lifetime: (Depends on how much dynamic content you have)
    • Expiration of cached pages: (Only matters if you are using an external cache like Varnish)
  • Bandwidth optimization
    • Aggregate and compress CSS files: Yes
    • Aggregate JavaScript files: Yes

Protect Web Forms and Collected Data

Note: You should try using non-Drupal solutions for forms, such as Qualtrics, whenever possible. Keeping forms and general data out of Drupal is more secure and makes it easier to manage and later upgrade your Drupal site.

In general, do not use Drupal to store sensitive data of any kind: FERPA protected, HIPAA protected, DoD protected, or personal identity information (SSNs, birthdates, etc.)!  The exception to this rule is if your Drupal site is for internal use only and is firewalled properly to prevent access from off-campus.  Even then, you should apply all possible security protections to prevent internal hacking of your sensitive data.

If you still need to have a form on a Drupal site, use the latest version of WebForm, and install some type of anti-spam / anti-bot protection, as forms get hit by bots quickly and regularly once they are made public.

  • Look at modules like Honeypot, Spamicide and BOTCHA to fend off bots
  • Avoid CAPTCHA (especially the early versions) if at all possible, as it will greatly irritate your users; the latest version is more acceptable, as it does not "quiz" the site visitor as strongly as the earlier versions
  • If you're resorting to CAPTCHA, consider whether or not the form can instead be locked down to just the Georgia Tech Campus only

Recommended "Site information" Settings

Located at: Configuration ->  System -> Site information

"E-mail address" is the address from which emails are sent by the site, so it should be generic, rather than the address of a real person.  Note: this must be an @gatech.edu email address for the campus email servers to accept messages from your website!

Note that the Georgia Tech web theme does not display the "Site name" set here, but rather has it's own site title fields on the theme configuration page.  However, "Site name" is used for the name shown in a web browser tab and any page bookmarks in a browser, so it needs to be set to something meaningful, and ideally identical to what you set on the theme configuration page.

Module and Library Safety Tips

  • Where possible, sign up for alerts about updates to libraries being used (such as CKEditor, phpCAS, Flexslider, etc), especially security vulnerability alerts.  Drupal does not give any notifications about out-of-date libraries!
  • Always turn off the following (unless you really need them):
    • PHP filter
    • Tracker
    • Comments
  • Review your modules regularly and disable any that are not being used
    • Disabled modules should be uninstalled and then removed from the Drupal filesystem (move them to the /private folder if you are on OIT Web Hosting)
    • If Drupal reports that a module has been removed from its repository on the Drupal.org website, there's usually a good reason.  Remove any such modules from your site ASAP!
  • Avoid keeping development-only modules on live sites. If you really need any, keep them turned off when not in use.
  • Avoid alpha/beta release modules and anything that is poorly supported or not supported at all.
    • When evaluating new modules, look at the last date of a release (be wary if more than a year ago), number of sites reporting usage of the module, reputation of the module's maintainer(s), and the number of open issues in the development queue.

Check Your Site's Health

  • Check the Status report (found at Reports -> Status report) and correct any problems listed
  • Use the Security Review module to scan your installation for common security problems

Custom Code and the Drupal Filesystem

General Rules of Thumb

  • Always write secure code!
  • Never hack the core Drupal code or any third party modules!
    • Hacks will likely get overwritten when updates are applied later on.
    • Instead, look for ways to extend or adjust the code through a custom module.
  • Avoid using unsupported modules, libraries or themes.
  • Test anything new or uncertain in a separate instance of Drupal.  Never develop on your live site!
  • Don't bother trying to hide the fact that you're running Drupal - it's really not worth the time and effort.

Drupal Filesystem Maintenance

  • Avoid putting anything but Drupal related code in or under the main Drupal directory
    • Adding other files or applications complicates the upgrade process, which can result in those other files or applications disappearing unexpectedly.
      • Drupal version 8 and beyond does not support running any other applications from within or under the main Drupal directory.
    • If you manually install modules or themes, don't leave their archive files within the Drupal directory tree.  Move them to the /private directory if you want to keep them around.

OIT Plesk Web Hosting Control Panel

General Hosting Account Configuration

Owner/Administrator

  • Avoid giving out hosting account access unless it is absolutely needed; only those who need to perform Drupal code upgrades should have hosting account access - content managers should never be given access to the hosting account.
  • Regularly check that the administrators of a site are correct (and remove any former maintainers).

Notification Email Address for Website

Only one email address is allowed, so set to the address of a mailing list or alias that forwards to all of your site administrators.

Installatron Applications Installer

  • If you are using Drupal 8 or higher (considered modern Drupal), the site now needs the Composer CLI tool to manage installation and updates for Drupal core and any modules, due to more complex project dependencies.
  • The Installatron tool on Plesk does not support Composer-managed updates, and is not recommended for managing a modern Drupal site. Installatron will update Drupal core without checking dependencies, and there is a high risk of updates eventually breaking any site that includes additional modules, as most Drupal sites do.

    Plesk now offers the PHP Composer UI tool to provide limited Composer support via a site's control panel. However, updates have to be manually prompted, and the tool is limited use.

  • How do I get started with Drupal on Plesk?
  • Is Drupal the right choice of CMS for my site?

PHP Composer UI Tool

  • While it's strongly recommended to use Composer CLI to develop and manage your site projects locally, the PHP Composer tool on Plesk provides some helpful options for managing Composer applications from your site control panel.
  • How do I use the Plesk PHP Composer extension? 

SSL Configuration

Follow the guide to SSL configuration to run your site with SSL encryption (via an https:// URL).

Plesk Backup / Restoration Manager

  • Before any major update or smaller update, it is recommended that you create a full backup of your site following the instructions before performing any changes/upgrade on your site.
  • In case that you need to restore the site back from unsuccessful change/upgrade:
    Please note that Drupal upgrade process tends to add new files to the system.  

    Restoring from backup will not delete files that were added after the backup was created. Therefore, it is suggested to do a "clean" restore to avoid new files created during the unsuccessful upgrade interfering the configuration of your site before the backup.  

    How to do a "clean" restore with Plesk Backup Manager (under About Restoration Behavior section)

Scheduled Tasks (cron)

Directory structure (multi-site vs. solo site, single system per virtual host, etc.)

  • This will vary depending on your site setup, but we no longer recommend using "contrib" and "custom" subfolders in the sites/all/modules folder.

URL Redirects

  • These are usually created in your .htaccess file (always keep a copy of the latest in your /private directory).
  • Check that your redirects did not get overwritten when your site's Core code was late updated.

Additional ideas can be found in the following: