Drupal Overview

The RC site runs on a content management system (CMS) called Drupal, which is an open-source framework that allows for expanded functionality and adaptability through “modules.” This makes for a very powerful but extremely complex (and often nonintuitive) platform that can adapt to RC’s various DH initiatives and needs to store and leverage metadata across site sections and content types. Drupal supports a large number of large-scale government, education, and industry websites, including NASA, Tesla, GE, Whole Foods, Harvard University, lots of ski resorts, and, yes, the University of Colorado Boulder (though this site is wholly unrelated to the RC site).

This section of the technical documentation will walk you through performing “front-end” web development tasks in the Drupal CMS (as opposed to the “back-end” development tasks covered in the next section). These tasks support and shape the site’s content and determine its appearance and usability. The following pages will cover: accessing and using the site’s admin UI, basic navigation and content editing, a rundown of Drupal entities and data handling, a tutorial on constructing database queries using Views, configuring content imports, changing the site’s appearance and behaviors, and performing performance and maintenance tasks.

CMS login and admin

Technical Editors in training will be provided with a username and password to access the backend of the site. Log into the site at this link. You should bookmark this page in your browser so you can easily return to it.

It’s worth noting that Drupal has a fairly robust “user permissions” system, but the site does not at present offer a public login option (for adding comments to content, etc.). If you receive a site login, then, you’ll be given either administrator privileges, which gives you complete control over all aspects of the CMS, or editor privileges, which will allow you to edit content pages. All RC staff engaging in dev work will be given full admin access and should be able to perform any of the tasks outlined here.

Upon login as an admin user, you’ll see a new menu banner across the top of each page; this is Drupal’s administrative menu, which gives you control over nearly every aspect of the site. Once you’re logged in with administrator or editor priveleges, you’ll also see contextual links and in-page menus to edit content. The function and use of these menus is covered in depth on the Navigation & Basic Editing page.

Drupal core, modules, & update logics

A Drupal installation has two major code components: Drupal core and contributed modules. Drupal core versions are released by the official Drupal organization (Drupal.org) with three types of releases, major, minor, and patch. Major core releases only happen every few years; as of this writing, Drupal 10 was just released (December 2022). Minor releases contain significant new features or additions and happen a few times each year. Patch releases contain bug fixes, security patches, and minor enhancements and are much more frequent, at least monthly. Drupal core releases always have three numbers: e.g., 9.5.2. The numbers reflect the major.minor.patch version of the release.

If you’re responsible for updating and maintaining the Drupal installation, it’s a good idea to monitor the Drupal core release cycle and the current releases for Drupal core.

Drupal modules, which extend the site’s functionality in various ways, are a bit more complicated since each module is maintained by a separate development team rather than by a centralized organization. Most popular Drupal modules are well-maintained and updated regularly. Some modules, however, may only be updated sporadically, meaning they may not maintain compatibility with the most recent Drupal release(s), and they may even, on occasion, be abandoned by their developers. For this reason, it’s important not to install any Drupal module that (a) does not have a strong justification to improve the site’s functionality, and (b) does not already have a wide user base at the time of adoption. Each contributed module will have its own page on drupal.org with details on its version number, compatibility, user base, documentation, and so on. Drupal.org’s main contributed module page can be useful to find new modules, but in performing site maintenance it’s generally easier simply to perform a web search for “Drupal module [name].”

Thus the Drupal ecosystem is in constant motion. As an open-source project (on of the largest in the world), all elements of Drupal are developed and maintained by a dispersed community of coders and web devs. Much of this development is sponsored by Drupal agencies and organizations that depend on Drupal’s continual development, but a decent proportion (almost 20%) of contributions to the Drupal project come from volunteers. (Incidentally, the #1 organizational contributor to Drupal development is Acquia, the company that hosts RC’s Drupal installation. For more on the state of Drupal development and the diversity of its dev community as of 2021, see this post by Dries Buytaert, one of Drupal’s founding architects.)

For all the above reasons, a Drupal installation must be regularly updated even as the dependencies among its various components must be respected. For example, even if a new major version of Drupal (Drupal 10) has been released, it is highly likely that the site requires modules that have not yet been updated to be compatible with Drupal 10. In this case, an attempted upgrade to Drupal 10 would likely break the site.

Luckily, the Drupal dev community has unanimously adopted a dependency manager called Composer that keeps track of all this for you and, generally, won’t let an update/upgrade happen unless every component of the Drupal install can satisfy its requirements/dependencies. Composer is a command line tool that runs via simple text commands in a terminal interface, so its use is covered in the “back-end”/Acquia section of this documentation: Updating Drupal via Composer.

The relational database: A note on Drupal’s content strategy

All web browsers require a web server (Apache) to serve a site’s page code in HTML. This is, for example, why RC can’t simply put TEI (XML) code on the web: browsers don’t know how to read it, so we transform documents (as related above) into HTML to get them onto the web. This HTML is imported into Drupal nodes via the site’s feeds importers (a functionality enabled by three feeds modules).

But Drupal doesn’t “keep” this HTML as content in a traditional sense; it does not, in other words, maintain an HTML file from which the page gets served. Instead, Drupal places all site content into its relational (MySQL) database, then uses this database to create each of the pages its serves (back into HTML). This primacy of the database in driving content management is what enables Drupal’s powerful Views functionality, which can perform complex database queries and thus basically “remix” and re-present any content that exists in the site’s database. This is also why you won’t find any of RC’s site content (other than media) in Drupal’s file system (SFTP): it’s all in the database.

Drupal’s extensive use of its relational database means that the database can get quite large, especially on a site with 25+ years of content. See the Database Management page for instructions on accessing and purging the database.