Developer’s Guide

Welcome to academic and enterprise-level Drupal development for the Trinity College of Arts and Sciences at Duke University. We are focused on providing secure and reliable Drupal website development and toward that end we have developed this vendor guidance.

We greatly value and will make time for coordination efforts or answering questions related to our hosting and maintenance of your finished website. To that end, we strongly encourage frequent communication with us throughout the development lifecycle. Emailing us is our preferred method for contact.

Scope for projects

When identifying your specifications and requirements for your project, please include all the items we identify in this document as requirements for delivery to Trinity Technology Services. (TTS) We can discuss exceptions as needed on a project-level basis. The sooner we discuss exceptions early in the build process, the better it will be for smooth project hand-off.

Drupal core and module versions

We will only host Drupal-based content management system websites. Our current standard is Drupal version 7. Email us if you wish to build your website in Drupal 8. For us to host your website, you'll need our explicit permission to use Drupal 8, again, at the start of your build process.

This document is specific to Drupal 7 website development. While Drupal 8 website development, is varies enough that we’ll need to discuss your build process in advance of the start of the project before you begin.

We strive to keep all core and non-core modules current with the latest stable release. We will perform website testing against Drupal core and module updates to ensure that functionality and presentation is what we expect.


We maintain a list of carefully reviewed modules. We have reviewed these modules extensively for security, reliability, stability and mainstream usage within the Drupal community. You should limit your website development to this list of modules.

If you wish to use a module not on this list, contact us with the module you wish to include. The module MUST meet the following criteria:

  • The module must be a Drupal-hosted module project
  • The module must have the maintenance status of "Actively Maintained" and a development status of "Under active development"
  • The reported installs must be greater than 1000 websites

We must review any module that doesn't meet any of the above criteria for security, reliability, performance, and other various aspects to determine if we can accept the module for inclusion. This is best done as early in the website development as possible to allow for contingencies should a module fail to meet approval.

Custom Modules

In the event that the requirements of the website build require a custom module, the agency creating the custom module must also arrange a service-level agreement (SLA) for the life of the website. Alternatively, the agency may contribute their custom module to the community. If the community accepts this module, and the module becomes reviewed and approved by Drupal’s security review committee, then the creating agency may  close their support SLA for the balance of the website’s lifecycle.

Security practices

  • Ensure your Drupal core and modules are up-to-date during your development process. There should be no outdated modules at the time of website hand-off.
  • Uniquely name the user/1 account. For example, do not use "Admin" for user/1.
  • Disable allowing PHP code in any user-facing content fields, regardless of user role.
  • Disable the Devel module just before shipping your files and database to us
  • We use Shibboleth to manage user accounts. No local accounts, that is, accounts that only exist in the Drupal user table.
  • Stick with the above list for modules. Use as few as possible.
  • Review your watchdog and apache error output logs. Address theme warnings.


We have standardized our theming using Omega. You must obtain our permissions before selecting another theme. Use a subtheme, and do not edit the base theme. There's more information at the website on subtheming. We have our own TTS and TTS subtheme that we use for our departments. You may use this theme for your website if you wish. If you choose to use our theme, which we encourage, you will not have to enter into an SLA with the website owner for the websites’ lifecycle. The TTS theme is a subtheme of the Omega 4.x theme. The TTS subtheme is a subtheme of TTS and is responsive as well as acccessible.

  • Allow for easy content editing via the Drupal user interface by never placing content in your template files.
  • Please use Drupal's conventions for including JavaScript into your theme. Avoid making manual edits to html.tpl.php when you can use drupal's APIs or modifications to the theme info file.
  • Do not specify your JavaScript or cascading stylesheets in the tpl files. Use your theme's template.php file, or use the file for specifying style sheet inclusion.
  • Avoid place "excessive" logic in your theme. Use stable and contributed modules over custom-coded logic wherever possible.

Duke Alert System

Duke University maintains an emergency alert system. Any website that TTS will host must include the Duke Alert Bar. You can find general information on adding this to your website here.


We recognize that 'Features' can be an effective way of replicating functionality from one environment to another. We developed the following guidelines and best practices for creating and managing features with the goal of helping to reduce the risk of creating features that result in conflicts:

  1. Keep your features as small and compartmentalized as possible; that is, do not encapsulate all your functionality in one feature, but break it out into smaller units, each bundling a single function.
  2. Use a unique naming convention for the following data types or entities that make up a feature. In this way, each name is unique to each defined feature set:
    1. Image styles
    2. Flexslider options
    3. Date and time format
    4. Taxonomy terms
    5. Content type and associated field names
    6. Feeds
    8. Pages
    9. Panels
  3. Develop your feature(s) in a local/development environment
  4. Commit your feature(s) to the website repository (<site-name><feature-name>)
  5. Deploy to staging, enable and test
  6. Deploy to production, enable and test

Moving forward, should a feature need to be updated:

  1. Download the latest version of the feature from the website repository to a local/development environment
  2. Make the configuration changes in the local/development environment
  3. Recreate the feature in the local/development environment
  4. Commit the changes to the website repository
  5. Deploy the modified code to staging, revert the feature (drush fr <feature-name>) and test
  6. Deploy the modified code to production, revert the feature and test


We use the standard Drupal multi-site configuration for all our websites. We understand that setting up multi-site on a local environment isn't trivial but doing so will better allow you to match the environment you'll be deploying to.

Multi-site uses a naming convention where the sites/local-site directory mirrors the actual domain for the website. For example, the website is found at sites/sociology_duke_edu. Inside this directory are the modules, libraries, files and themes that are unique for this website. The theme name mirrors the lowest-level of the domain, i.e., "sociology" for Please be sure to name the custom theme accordingly:

├── libraries
├── modules
└── themes
     └── sociology

Accessing the Duke University network

  • Every member of your team that will be updating website content on the Duke network will need a "Guest Account." Note that will log all activity on our network. You "own" all activity our system associates with your Guest Account, so be sure that everyone on your team procures a Guest Account.
  • To learn more you can read about our guest policy here, guest access to Duke resources here, and when you're ready, your Duke contact may request your guest account here
  • The default lifetime for guest accounts is one year; however, we strongly encourage your Duke contact to request that the duration of your account to be limited to the time you expect to complete your project.
  • Our security procedures limits who may directly access website files. We have available a git repo so that you may commit your code changes there and we may then push your changes as needed.

Development workflows

Ideally, you may wish to develop locally before bringing your website to our servers. When you're ready to send us your files, you may find that drush archive-dump is helpful for this.

Server information

We maintain a "staging" and "production" server pair for all of our websites. Generally, you'll be working on the "staging" server. We place IP restrictions on our staging servers, limiting access to those who are on the Duke internal network. If you are off-campus, this will require that you use your Guest NET ID Account in conjunction with out VPN software to access our network. Visit for more on accessing the Duke network remotely.

Also note that we generally do not synchronize the staging website's database with production. You must recreate any changes you make the the staging website's configuration to the production's database. We have started to support Drupal 7's Features module for this. See the section on features for more information.

Uploading and maintaining your code

We have a GitLab server where we maintain all of our code for our websites. You must use your Guest Net ID to access this server. We use git to push code update

To access our GitLab server, we'll need to add your Guest Net ID to the releveant project repository. If this is your first time accessing the server, you must access the server before we grant you access, due to how we manage accounts with shibboleth. Once you access the website, you'll need to add your public key. You can read more about the key creation process here.

After we install your exportedwebsite on our servers, you'll be able to push your code changes using git. We use a "staging" branch for the staging server, and "master" for production. Once we confirmed that the "staging" branch code is correct, you'll merge these into the master branch and "git push" your changes to our server. Please notify us via email after doing so and we'll push your changes to the production server.

Maintenance page

We strongly encourage the creation of a maintenance page for when we take websites off-line for maintenance tasks. The design need not be the same standard as the rest of the website, but be certain to be clear that the page is legible. Drupal covers this process here.

Site Delivery Review

We use the Site Audit module to review received websites and find potential issues, such as unused or improperly disabled modules. We also will crawl the major pages at the website and check Drupal watchdog log and the apache logs for warnings and errors.

Site Launch

We will run our quality assurance checklist prior to launching your website. Also note that we only launch a new or redesigned website on Monday through Thursday. If Friday is a holiday for the target launch week, then Monday through Wednesday are the available weekdays.