Chapter 2: Introducing Backdrop
This chapter introduces Backdrop as a manifestation of an open source community, and as a software package. It explains the technical components that make up Backdrop and how they relate to one another. Lastly, it describes the process of building a site using Backdrop using an extended analogy.
Backdrop is open source software, a fork (split-off) of Drupal, a much larger open source project that was supported by one of the largest communities of developers. Drupal 7 (released in 2011) gained non-trivial adoption among the digital humanities community as a platform for storing and querying complex structured data. Drupal 7 had significant shortcomings in user experience for people who build sites, lacking a lot of functionality that should be considered standard for modern websites. At the Digital Humanities Summer Institute “Drupal for Digital Humanities Projects” workshops, module installation was a reliable joke: immediately after installing Drupal, the students would have to work their way through a long list of modules to install before doing anything else. Realistically, building a digital humanities site requires enough functionality specific to the kinds of data that humanists work with that you should expect to install some modules. You shouldn’t, however, have to install a module to be able to use a link field, or a basic date field, or automatically have nice-looking page URLs – as was the case in Drupal 7. These are among the many shortcomings that the Backdrop developers have addressed with Backdrop.
As of January 2019, the user community for Backdrop is still fairly small-- in part because, for most sites, Drupal 7 remains a more robustly functional and fully-supported option. However, the Drupal 7 end-of-life has been announced for November 2021, and Drupal 8 is not a good choice for many websites, including digital humanities projects and websites for small businesses and non-profits. As a result, odds are good for a significant increase in the Backdrop user base in the next two years as Drupal phases out support for Drupal 7. In the meantime, development of Backdrop is ongoing, and by getting involved with Backdrop development (including through channels such as testing and documentation-writing, if you don’t write code), digital humanities have an opportunity to contribute to the overall priorities and shape of the platform.
Because less-technical site builders are a major part of the the target audience for Backdrop, it has one of the most patient, helpful, and generous developer communities of any general-purpose open source project. While the developer community tends to communicate internally via Gittir.im (a chat room for developers, with Github integration) and comments on Github issues for Backdrop core and modules, they also provide a Backdrop forum that may be a more comfortable environment for humanists to post questions and problems.
The Backdrop website includes a clear articulation of the project’s philosophy. The leadership structure of Backdrop is designed to provide checks and balances between the various perspectives and interests of the Backdrop community. The leadership structure page also explicitly includes a workflow for conflict resolution within Backdrop leadership. This stands in contrast to Drupal, where the philosophy, priorities, and core development approach are determined by the project creator, Dries Buytaert, who has a direct financial stake in the platform’s direction through his software-as-a-service platform, Acquia.
In one sense, it is as if projects that use Backdrop have a development staff of tens of people, even if the project itself includes no programmers. In another sense, because there are no developers dedicated specifically to your project beyond ones you hire yourself, if you encounter obscure bugs or issues with a module (or, worse, a particular combination of modules), they may linger unresolved for a long period of time. Module developers have different levels of personal commitment to maintaining the modules they create, though to date the core Backdrop developers have acted as a backstop in cases where serious problems with a module are discovered, but the module developer isn’t able to address them (due to lack of engagement, or not having the depth of technical knowledge to fix the problem). Choosing modules that others building similar sites have used successfully reduces the risk of encountering problems that remain unaddressed indefinitely. Sometimes, though, you may need to hire a developer to fix a bug, or write a module to provide specific functionality for your site. While this may cost a few thousand dollars, by making the fix or the module available to the rest of the community you can give back to the Backdrop ecosystem and perhaps save another project some time and money in the future. This approach stands in contrast to the custom development of a project or database from scratch, where little or none of that work is reusable by others.
Backdrop was developed in response to the developers – who were (and in many cases, still are) actively involved in the Drupal development community – having concerns about the usability of Drupal 8 for small businesses and non-profits. These concerns apply equally to digital humanities projects. Drupal’s major version upgrades have always been a non-trivial undertaking; unlike in the WordPress ecosystem, there are significant changes to the core code, and there is no backwards compatibility. To upgrade a site, you have to wait until all the modules you’ve used in the previous version are available for the new version (or there are new modules with upgrade paths), and even then, things are liable to break in the migration. All the effort needed to migrate a site to a new version of Drupal has historically been rewarded with significant improvements to the software; for instance, Drupal 7 included the ability to create custom data models (content types) as part of the core, whereas that functionality was part of a ubiquitously-used module in previous versions.
The architectural changes made between Drupal 7 and Drupal 8 were at a much larger scale than changes between previous versions. Drupal has historically had its own, atypical requirements for how certain programming tasks are implemented. In an effort to attract professional PHP programmers, it was decided that Drupal 8 would adopt conventions and frameworks that are widely used in the broader PHP development community. These conventions are very different from the previous “Drupal way” of doing things, and tend to be more complicated. This has alienated some Drupal developers, particularly those who work on Drupal development as a side-project, and may not be professional software developers with pre-existing familiarity with the standard PHP frameworks. As a result, even three years after Drupal 8 was released, its adoption by digital humanities projects (and within the small-business and non-profit communities) remains limited. Part of this is a vicious cycle with regard to modules: projects that lack grants or developers can’t migrate until modules are ported to Drupal 8, but specialized modules (like Partial Date, which offers a more flexible date field that is especially valuable for historical dates) won’t be ported until a digital humanities or similar project has grant funding for a migration that includes porting the module. Part of the reluctance is the fact that the vast majority of the new technical benefits are for developers, assuming pre-existing familiarity with enterprise PHP frameworks. The experience of building a site in Drupal 8 (i.e. the audience for this book) is very similar to Drupal 7. A few modules that had to be installed separately are now included in the core, but very little has changed for site builders to incentivize dealing with the hassle of a migration. Furthermore, Drupal 8 has more rac
As an analogy, imagine a small, vibrant community of philosophers in 17th century Barcelona, where participants only write treatises in Catalan. The use of Catalan within this community is treated as such a given that participants may never have learned Latin, even though Latin is the language of scholarship elsewhere in Europe. In order to increase the influence of this school of philosophy and contribute to conversations happening elsewhere in Europe, a number of influential figures within this group decide that all treatises must henceforth be written in Latin. Other members of the community are disgruntled at the fact that their treatises in progress must be rewritten in Latin. They feel that learning Latin would take too much time and would distract them from their actual work. They see Latin’s case system is as too difficult to learn fluently, and the philosophers are concerned they won’t be able to express themselves with the same nimbleness as they could before. The philosophers with the greatest concerns (here, the Backdrop developers) break away from the original community and continue to develop the same philosophical ideas they worked with before, while maintaining the use of Catalan with the adoption of a few more Latinisms where they are particularly effective at conveying certain ideas. Meanwhile, in the years following the switch to Latin, it becomes clear that the change has made it difficult for students who cannot afford private tutors to reach the point of linguistic fluency to be able to meaningfully contribute to scholarly discourse. The research areas of interest to students who do not come from wealthy families become underrepresented in the discourse of the Latin-speaking scholarly community (here, modules that aren’t relevant for “enterprise” Drupal sites haven’t been ported to Drupal 8 even after 3 years). An increasing number of students who have struggled with Latin instead join the split-off Catalan-speaking community, where their research agendas contribute to an interdisciplinary community that values collaboration.
The information about how you’ve configured Backdrop’s core and modules should mostly be stored in configuration files. If a Drupal module has been fully ported to Backdrop, it should be written in a way to take advantage of Backdrop’s approach of using configuration files, rather than storing configuration information in the database. That said, you may be using modules that work in Backdrop (by providing the right user-facing functionality), but haven’t been fully adapted to Backdrop. In those cases, the modules would store configuration information in the database. This isn’t inherently a problem if you only ever have one version of the site, but if you want to set up a development environment and a production environment, it means not only moving code from one to the other, but also making database changes in both places.
If you have previous experience with SQL and databases, you may be taken aback if you look directly at Backdrop’s database. It is not configured in ways that resemble the way someone creating a database from scratch would approach the task. That said, people who are creating sites by combining and configuring different modules never have to access the database directly. Backdrop’s code knows how to interact with the database, and it’s strongly recommended that you only make changes to the database using Backdrop’s code (or, for developers, Backdrop’s APIs) as a translator and intermediary. Making changes to the database directly (for instance, by sending SQL commands to the database and/or using an interface to the database itself like PHPMyAdmin) is dangerous, and often has unpredictable side effects, like data disappearing or getting corrupted.
Most of the work of building a Backdrop site involves using the administrative interface (which is largely determined by the code) to customize settings for the site (which changes the configuration files) and add content (which changes the database, and may also involve adding files to the filesystem).
While Backdrop’s code can easily remain unseen by the person creating the site (commonly referred to as a “site builder”), it is important to have a general understanding of the different sources of your site’s code, so you can make better guesses about where in the site configuration to go to make different kind of changes, and effectively troubleshoot when things go wrong.
At the same time, keep in mind that the code that makes up your site is not what makes the site unique. If all the code for your site were accidentally deleted, as long as you know what versions of which modules your site uses, you could re-generate your site exactly as it was within a couple hours by re-downloading Backdrop core and modules. If your database, configuration files, and/or “files” directory (for uploaded files) vanished, you would be in dire straits without a backup (see sections 20.4 and 20.5).
The most basic Backdrop site consists of the core Backdrop code, plus a database. The Backdrop core is the software available at https://github.com/backdrop/backdrop, and includes all the essential infrastructure and plumbing for a basic site (menus, user account management, file uploading capabilities, in addition to the Backdrop administrative interface itself). Modules that are part of Backdrop 7 core include those that enable content types, taxonomies for tagging and classifying content, comments, contact forms, and Views for developing different displays of the information on your site.
Modules are packaged-up code that provide some new piece of site functionality. This can range from tweaking the label of some field on the administrative interface to completely overhauling the way content access permissions are handled, to providing integration with common mailing list software.
The design of your site is largely determined by the site theme. Like modules, themes are packages of code that you add to your site to achieve a certain effect (in this case, to give your site a particular look). Unlike with modules, it’s okay to modify the theme code that you’ve downloaded. Theme code consists of PHP files that specify “regions” (i.e., things like how many columns your site can have, whether you can put text in a footer area, etc.) While all themes include one or more CSS files that determine the site's visuals (like color, fonts, and text spacing), some themes provide configuration options you can access through the Backdrop interface that allow you to change the site's colors without having to write any CSS yourself. There are also ways to use the CSS from an existing HTML theme and apply it to the HTML elements and classes provided by Backdrop. See chapter 18 for more about themes, and how to choose one that is a good fit for your site.
The core Backdrop code and the code for the modules you have installed define what is possible to do on your site. The configuration files store the information about how you've specifically chosen to configure the site, based on the possibilities and constraints provided by the code. For example, the core Path module gives you the ability to define the path (URL) that will be used for your content. When you go into the settings for Path and specify that you want your blog posts to appear at yoursite.org/blog/[year]/[month]/[date]/[title], that information is saved in a configuration file. If you’re familiar with version control (e.g. Git), managing your configuration files that way is a good approach, but you don’t need to use version control to build a Backdrop site.
If you have only used HTML to develop websites, switching to a database-powered content management system like Backdrop opens up a wide range of new options for managing and displaying your data, but it also makes the storage of that data less intuitively accessible. Where you could previously point to a specific .html file that contained the data displayed on a single webpage, the content that appears on an equivalent webpage in a Backdrop site is actually stored in many different places throughout the database. But whether you want to back up your data, share it with someone else, or export it for use with other software, there are many options for getting your data out of the Backdrop database in a variety of formats, including PDF, Excel-compatible CSV files and XML. Section 15.2 covers data export.
The Backdrop core code provides the essential plumbing for your site, and a small group of modules that provide basic website functionality. The additional modules you install provide much of the functionality of your site, and the choice of which modules to install largely depends on what your site needs to do. The information about your configuration choices for core and modules are stored in configuration files. Your site's theme and its associated configuration options determine what the site looks like. All the information about your site's configuration, as well as your site's content, are stored in the database.
The Backdrop core code provides an administrative interface where you will be doing most of the work involved in configuring your site. The following major components of Backdrop can be configured using this interface. Collectively, they make up the structure of the site.
One of Backdrop's defining features as a content management system is the ability to create content types-- essentially, templates for storing different kinds of data. In contrast to WordPress, where a user can choose between creating a blog post and a page-- both of which are by default limited to a title, text area, and some tags-- Backdrop allows you to create any number of content types, each of which can have as many fields as you need for storing different kinds of content (URLs, structured dates, pointers to other pieces of content or users, videos from external hosting providers like YouTube, in addition to multiple types of fields for text and images). This makes Backdrop well-adapted for storing and organizing data beyond simple webpage content.
As an example, consider a departmental website. Such a site could make use of Backdrop's default "Basic page" content type-- which contains a title field and a body field-- for general informational pages about the department and its programs. Departmental news items could be added through the site using the "Post" content type. This content type contains a title and body, but also includes an image field, tags, and has comments enabled by default.
The department could also use the "Page" content type to publish course descriptions, but Backdrop content types enable the site builder to store that information in individual fields-- rather than a large blob of text-- and then display the information in a variety of useful ways.
Imagine the site builder creates a content type called "Course". By default, Backdrop includes a title field and a body field with every new content type, though the body field can be renamed or removed entirely. The developer might then add the following fields:
- A "topic" field, for selecting from a standardized list of course topics (e.g. 19th century, sexuality)
- An "instructor" field, for selecting one or more faculty members or graduate students affiliated with the department
- A "semester" field, for choosing which semester the course has been and/or will be taught
- A "prerequisites" field, for typing in the names of prerequisite courses, where Backdrop will autocomplete based on the courses that have already been entered
- A "syllabus" field, for uploading a PDF of the course syllabus
When the site webmaster goes in to add information about a departmental course, they will be presented with an easy-to-use form containing these fields.
While this is a fairly simple content type, using only Backdrop core modules and the References module, there are modules that enable fields tailored for data ranging from email addresses, links and dates to geographic coordinates and temperature data. Content types can be made even more elaborate using Field groups (see section 6.5.6)-- for instance, you might want to group the time a class is scheduled with the room number the class is held.
In Backdrop jargon, a "node" refers to an instantiation of a content type. Whenever you add new content to your site using any content type, you have created a node. For most sites, almost all the data on the site is stored as nodes; an exception might be if your site is primarily a directory of people, in which case your content would be mostly stored in user profiles (see section 10.4).
Backdrop's "taxonomy" system provides an easy way of associating categories, tags, or other controlled or uncontrolled vocabularies with your content and users. You can create multiple vocabularies, which each contain terms. To continue with the departmental website example, the site builder would need to create a vocabulary for course topics, and populate it with the list of terms that the department uses to topically categorize its courses. When adding terms, there are options for adding a description for the term, as well as specifying its parent terms within that vocabulary in order to form hierarchies of terms (e.g. putting “Folklore” and “Children’s literature” under a parent term “Genre studies”).
Furthermore, within a particular vocabulary, site builders can configure fields that will be available when creating or editing any term within that vocabulary. For example, a site builder might create a vocabulary called "University", where users can specify the university they are affiliated with as part of their user profile. A site builder could add a field, “Address” to the “University” vocabulary. Every university entered by a user would be stored as a taxonomy term, and users with the right set of administrative privileges could edit those terms to add the address for the university. This would make it possible for the site to display a map showing the universities that its users are affiliated with, using the Views module.
When a node or user is tagged with a term from a vocabulary, by default that term appears on the node or user page as a link to a term page that displays all other nodes or users tagged with that same term, making it easy to browse related content. Section 6.4.4 describes how to set up a vocabulary and an associated term reference field; chapter 17 describes modules for importing, exporting and managing taxonomies.
By default, Backdrop provides two options for displaying content: 1) viewing a full node, and 2) seeing the default "content feed" (much like the WordPress “posts” page) that displays the shortened "teaser" version of the most recent nodes you've created. This may be suitable for a simple blog, but any site that has custom content types will need the Views module to make the best use of those content types. Chapters 12 and 13 cover Views in depth, but at its essence, Views allows you to query your database in simple or complex ways without writing any code. A very small subset of the possible displays you can generate with Views (often with the help of additional modules) includes:
- A table of all site users and their university affiliation, with dropdown criteria (drawn from fields in the user profile, such as discipline) that can be used to filter the list
- Rotating slideshows
- A gallery of image thumbnails
- A list of blog posts written by the person whose profile you're currently viewing
- A map displaying all the locations stored as part of nodes, where clicking on a location pushpin pulls up the title and a link to the node where those coordinates can be found
- A CSV export of some or all the content on the site
- An RSS feed
- A list of the most active site users
- Information stored in the user profile of a user referenced in the node you're currently viewing-- in the departmental website example, Views could display on a course page whether the instructor is a professor, lecturer, or grad student, without the webmaster having to enter that information as part of the course profile.
The results of these queries can be displayed on your site in many ways, including as a standalone page with its own URL, as a feed, as a plain-text file for exporting data as a spreadsheet, or as a block (see below).
Blocks are generally small containers of content or site functionality (such as a user login box, or a menu) that can appear in different places on the site (e.g. footer, right sidebar on blog post pages, top right corner of the front page). Blocks can be created by modules or views, or you can manually create a custom block, which is convenient for things like a copyright notice for a site footer.
On the block administration page, you can drag and drop blocks into the different regions (header, footer, sidebar, etc.) that have been defined by your site's theme. Backdrop also has a structure called “Layouts” that can more flexibly define different regions for different pages. (For people familiar with Drupal, this is similar to Display Suite or Panels.) In addition to determining where on a page the block appears, you can configure the block to appear only on pages that meet certain criteria. For example, if you have a block that's only relevant within a particular area of the site, like "Related blog posts", you can specify that it should only appear on pages from the “Blog” content type. Section 11.2 describes the configuration of blocks in depth.
Backdrop has a fairly straightforward menu system. You can create any number of menus, and pages within a menu can be nested arbitrarily deep. When you create a node or a view, you can add easily add it to a menu. Module-generated pages (e.g. site contact forms) can be added to a menu manually.
Every menus is automatically available as a block. While some themes automatically display the "Primary links" menu, in most cases you need to go to the block administration page and place the block corresponding to the primary menu in the appropriate "menu" region for your theme. How the menu block is displayed varies by theme, but modules like Superfish or Nice Menus can provide a dropdown display for menus in order to easily handle nested menu items. Section 11.3 describes menu configuration.
Even small sites that do not accept user-contributed material will likely have multiple users. For security reasons, each user should have their own account, even short-term research assistants.
By default, Backdrop creates a page for each user that includes their username and how long their account has existed. By default, users can upload an avatar (small picture) that will display along with their username on content they've created using the default "Post" content type, though this is entirely configurable and removable if desired. As with nodes and taxonomy terms, you can add any number of fields to user profiles, including fields that only users with administrative privileges-- and perhaps not even the user himself-- can see and edit.
Roles are a key component of Backdrop's permission system, providing differentiated levels of access to your site (including, but not limited to, administrative functionality.)
The user account that you create during the Backdrop installation process is referred to as "user 1". This account automatically receives irrevocable full access and permissions to absolutely everything on the site. Therefore, the login information for that account should be closely guarded, and it should be rarely used. If there are users who should have full administrative access to the site, it’s better to give them their own user account with the “administrator” role.
When you install Backdrop using the "standard" install option, Backdrop will create a role called "administrator", that automatically gets full permissions to core functionality, and any new module that's installed. The administrator role also has permissions to modify permissions for its own role, and all other roles. Only skilled and trusted Backdrop site builders should have the administrator role assigned to their user account. In a situation where multiple people with different skill sets are collaborating on a project using Backdrop, it's best to set up different roles where the permissions are tailored to what kind of work the person is doing, in order to reduce the risk that a user could "break something". An undergraduate assistant, for instance, might have permission to create and save blog posts, but not publish them publicly until a graduate student assistant reviews the content. There might be a role corresponding to the work of a particular research assistant who has been exclusively tasked with uploading and adding metadata to images. User accounts can have multiple roles, and the permissions the user has are cumulative. The Backdrop permissions system is remarkably granular; almost every module provides its own permission configuration options (so you could allow a research assistant to administer the configuration of one module and not another), and modules like Field Permissions can restrict what user roles can edit which fields in nodes, taxonomies, file types, and user profiles.
Backdrop's content type system allows you to create highly customizable templates for storing and managing your content: content types, file types, and user profiles. These templates can include the option of using taxonomy terms to categorize your content, and taxonomy terms can have their own customizable templates for storing related metadata. Each piece of content you create using a content type is called a node. Views is a module that provides a user interface for querying your data and displaying the results in a wide variety of ways, including blocks-- small boxes of data that can be placed any of the regions (header, sidebar, etc.) of your webpage defined by your theme. The menu system provides users with a way of navigating site content. Users can optionally have customized profiles, and a user's roles define their level of access within Backdrop's granular permission system.
This chapter has described the technical underpinnings of Backdrop, as well as the major components that you will need to install and/or configure in order to successfully build a Backdrop site. Chapter 3 covers options for hosting a Backdrop site, as well as the installation process. If you already have Backdrop installed, you can move ahead to chapter 4.