Chapter 1. Overview of Drupal

What Is Drupal?

Depending on who you talk to, you’ll hear Drupal called a Content Management System (CMS) or a Content Management Framework (CMF, a platform that you can use to build a custom CMS)--and both are accurate. It can be called a basic CMS because after installing only the base Drupal software, you can create a website with forums, static pages, and/or a blog, and manage the content online. On the other hand, it can be called a flexible CMF because most people choose to add additional modules to Drupal in order to build more complicated websites with more features, and Drupal also allows you to create fully custom modules.

Drupal is free and open-source software (FOSS), governed by the GNU General Public License (GPL) version 2 (or, at your option, any later version). If you have never read the GPL and plan to use Drupal, you would be well advised to do so (even more so if you plan to do any Drupal programming, for yourself or others). The GPL governs not only what you can do with Drupal software itself, but also what you can do with any add-ons you download from drupal.org, code you find on drupal.org documentation pages, and any derivative work (work that contains GPL-licensed work, verbatim or with modifications) that you or others create. It’s also written in plain English and is quite a good read (for programmer-types anyway); you can find it in the LICENSE.txt file distributed with Drupal core, or at http://gnu.org.

And finally, Drupal is also a project and a community. Unlike some FOSS software that is developed primarily by one company that later releases the source code to the public, Drupal is continually evolving due to the efforts of a world wide community of individuals and companies who donate their time and money to create and test Drupal software, write the documentation, translate it into other languages, answer support questions, keep the drupal.org web servers running, and organize get-togethers on a local and world wide scale.

Drupal Core

Drupal core is what you get when you download Drupal from http://drupal.org/project/drupal, consisting of a set of PHP scripts (some with embedded HTML mark-up), JavaScript, CSS, and other files. This software interacts with a web server (typically, Apache), a database (MySQL, PostgreSQL, and SQLite are supported by Drupal core version 7, and others are supported by add-on modules), and a web browser to provide the basics of a CMS:

  • A URL request dispatch system
  • A user account management system with flexible permissions and roles
  • Online content editing
  • A theme (template) system, which lets you override how everything from a button to an entire page is displayed
  • A block system that allows you to place chunks of content in various regions of a site’s pages (this system will be quite different in Drupal 8, and more flexible).
  • A navigation menu builder
  • A flexible taxonomy system that supports categories, tags, and user-defined taxonomy vocabularies
  • Optional modules supporting commenting, content fields, RSS aggregation, search, and site features such as forums and polls (depending on the Drupal version, some of these may require downloading add-on modules instead of being part of Drupal core)
  • The ability to set up a site in different languages and translate content (depending on the Drupal version, some add-on modules may be required to make a multi-lingual or non-English site)
  • Logging of system events and errors
  • An API for Drupal programmers

Drupal Add-Ons: Modules, Themes, Distributions, and Translations

Drupal is modular software, meaning that you can turn site features and functionality on and off by enabling and disabling modules. Drupal core comes with a few required modules and several optional modules; you can download thousands of additional contributed modules from http://drupal.org/project/modules. Most modules have configuration options that you can modify from the Drupal administration interface, by logging in to the Drupal-based site using an account that has been given appropriate permissions. The permission system is flexible: you can define named roles, which are granted specific permissions (the permissions are defined by modules), and you can assign one or more roles to each user account.

Drupal uses a theme system to separate the content from the specific HTML markup and styling. This means that if you want to redesign the site’s layout or styling, you can do so by downloading a new theme from http://drupal.org/project/themes, purchasing a commercially available theme, or creating one yourself—once installed and enabled, it takes effect immediately to change the look of your site without the necessity of editing your content pages. The theme system allows you to use the default display for whatever you are happy with and override the parts you want to change; the overrides can be at anything from the lowest level (for example, the presentation of buttons) to the full page.

You can also download Drupal in a distribution, which consists of Drupal core and a collection of contributed modules and themes that work together to provide a more functional site for a specific purpose. Distributions are available at http://drupal.org/project/distributions for e-commerce, government, non-profits, and many other purposes.

And finally, you can download translations for Drupal and its contributed modules, themes, and distributions from http://localize.drupal.org. As of Drupal version 7, this is unfortunately more complicated than installing a module or theme, even more so if you want to set up a multilingual site. It should be improved in Drupal 8.

Finding Drupal add-ons

Here are the main ways to find Drupal add-ons (modules, themes, or distributions):

How Drupal Handles URL Requests

When Drupal is installed properly and the web server receives an HTTP request that corresponds to the Drupal site, the main Drupal index.php file is loaded and executed by the server to handle the request. It is important for Drupal programmers to understand how Drupal handles such requests; here is an overview (see also Figure 1-1):

  1. Drupal determines which settings.php file to use for the HTTP request (you can set up Drupal to serve multiple sites, each with its own settings.php file), and this file is loaded and executed.
  2. If a URL request is coming from an anonymous user (a site visitor who is not logged in), the page cache is checked to see if output has previously been cached for the same requested URL. If so, the cached output is returned to the web server, and Drupal is done. Drupal page caching does not apply to authenticated (logged-in) users.
  3. The database connection, configuration/variable system, and PHP session variables are initialized.
  4. The language system is initialized, and various files are loaded and executed (core include files and enabled modules' .module files).
  5. Drupal determines whether the site is offline (also known as being in maintenance mode) or online.
  6. If the site is offline, Drupal retrieves the offline message stored by an administrator as the page content. Other functions are called to generate some sections of the page content.
  7. If the site is online, or if an authorized user is accessing a page while the site is offline, Drupal determines which functions need to be called to generate the content for the request, and calls these functions. They ideally return raw, prerendered content, but they could also return rendered or partially rendered content.
  8. Drupal determines what delivery method to use for the page, and calls the appropriate delivery function.
  9. For HTML page requests, the default page delivery function prints HTTP headers, uses the theme to render the raw content into HTML, prints the HTML output (which effectively sends it to the web server), saves user session information to the database, and exits. The AJAX request delivery function is similar, but it renders into JSON output instead of using the theme system to render to HTML. Modules can also define custom page delivery methods.
Overview of Drupal HTTP request handling

Figure 1-1. Overview of Drupal HTTP request handling

Related topics:

Drupal 8

In Drupal 8, some of this high-level overview will still apply, although the details behind the steps will be changing significantly. In particular, fewer files will get loaded, and philosophically, Drupal will be oriented towards responding to generic HTTP requests containing session variables and other context information, rather than returning HTML pages given a URL.

The Drupal Cache

Drupal has a cache system, which allows modules to precalculate data or output and store it in the database so that the next time it is needed it doesn’t have to be calculated again. This can save a lot of time on page loads, at the expense of some added complexity: any module that uses caching needs to take care to clear its cached data whenever the data is invalidated due to changes in dependent data. The Drupal 7 cache system has a fairly simple API, consisting of functions cache_set() and cache_get() (with a few variations), as well as cache_clear_all() to clear all database caches, including module-specific caches. Modules can register to have their caches cleared by implementing a hook (hooks are module entry points to altering Drupal) called hook_flush_caches().

Both Drupal core and add-on modules cache information using this system. Here are a few examples:

  • Page output for anonymous users (page caching can be turned off from the Performance configuration page)
  • Block output (block caching can also be turned off from the Performance page)
  • Menu routing (URL) information, block registration information, and other information collected from modules
  • Theme information, including the list of theme regions and theme-related information from modules and themes
  • Form arrays

Programmers and site builders new to Drupal quickly learn that the first thing to try, if they are having trouble with a site or if programming changes they have recently made are not being recognized, is to clear the cache. You can clear the cache by visiting the Performance configuration page and clicking the cache clear button, or by using Drush.

Related topics, examples, and references:

Drupal 8

The cache API functions are different in Drupal 8 because it uses classes to manage caching.

Get Programmer's Guide to Drupal now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.