What Is Drupal? [How Drupal Works]

Drupal  is used to build web sites. It’s a highly modular, open source web content  management framework with an emphas is on collaboration. It is extensible, standards-compliant, and  strives  for clean code  and  a small footprint. Drupal ships with basic core functionality, and  additional functionality is gained by enabling built-in or third-party modules. Drupal is designed to be customized, but customization is done by overriding the core or by adding modules, not by modifying the code  in the core. Drupal’s design also successfully separates content management from content presentation. Drupal can be used to build  an Internet portal; a personal, departmental, or corporate web site; an e-c  ommerce site; a resource directory; an online newspaper; a social networking site; an image gallery; an intranet; and  virtually any other type of web site that you can imagine creating.

A dedicated security team strives  to keep Drupal secure by responding to threats and  issuing security updates. A nonprofit organization called  the Drupal Association supports Drupal by improving the drupal.org web site infrastructure and  organizing Drupal conferences and  events. And a thriving online community of users, site administrators, designers, and  web developers works hard to continually improve the software; see http://drupal.org and  http://groups.drupal.org.

Technology Stack

Drupal’s design goals include both being able to run  well on inexpensive web hosting accounts and  being able to scale up to massive distributed sites. The former goal means using  the most popular technology, and  the latter means careful, tight coding. Drupal’s technology stack is illustrated in Figure  1-1.

Figure 1-1. Drupal’s technology stack

Drupal runs successfully on any operating system that supports PHP. The web server  most widely used with Drupal is Apache,

though other web servers (including Microsoft IIS) may be used. Because of Drupal’s long history with Apache, Drupal ships with .htaccess files that secure the Drupal installation. Clean URLs that is, those devoid of question marks, ampersands, or other strange characters are  achieved using  Apache’s mod_rewrite component. This is particularly important because when migrating from another content management system or from static files, the URLsof the content need not change, and  unchanging URIs are cool, according to TimBernersLee (http://www.w3.org/Provider/Style/URI). Clean URLs are available on other web servers by using the web server’s  URL rewriting capabilities.

Drupal interfaces with the next layer of the stack (the database) through a lightweight database abstraction layer, which was totally  rewritten in Drupal 7. The database interface provides an API based on PHP data object (or PDO) and  allows Drupal to support any database that supports PHP.  The most popular databases include MySQL and  PostgreSQL. In Drupal 7, SQLite is nowalso supported.

Drupal is written in PHP. All core Drupal code  adheres to strict  coding standards (http://drupal.org/nodes/318) and  under

goes thorough review through the open source process. For Drupal, the easy learning curve  of PHP means that there is a low barrier to entry for contributors who are just starting out, and  the review process ensures this ease of access comes without sacrificing quality in the end  product. And the feedback beginners receive from the community helps to improve their  skills.

For Drupal 7, the required version of PHP is 5.2. 

Core

A lightweight framework makes up the Drupal core. This is what  you get when you download Drupal from drupal.org. The core is responsible for providing the basic  functionality that will be used to support other parts of the system.

The core includes code  that allows the Drupal system to bootstrap when it receives a request, a library  of common functions frequently used with Drupal, and  modules that provide basic functionality

like user  management, taxonomy, and  templating, as shown in Figure  1-2.

Figure 1-2. An overview of the Drupal core (not all core functionality is shown)

The core also includes the basic  functional building blocks for most web sites, including feed aggregation, blogging, polls, and  forums. 

Administrative Interface

The administrative interface in Drupal is tightly integrated with the rest of the site. All administrative functions are easily

accessible  through an administrative menu that appears at the top of the page when you are logged in as a site 

administrator

Modules

Drupal is a truly modular framework. Functionality is included in modules, which can be enabled or disabled. Features areadded to a Drupal web site by enabling existing modules, installing modules written by members of the Drupal communityor writing newmodules. In this way, web sites that do not need certain features can run  lean and  mean, while those 

that need more can add as much functionality as desired. This is shown in Figure  1-3.

Figure 1-3. Enabling additional modules gives more functionality.

Modules can extend Drupal by adding new content types  such as recipes, blog posts, or files, and behaviors such as e-mail notification, peer-to-peer publishing, and  aggregation. Drupal makes use of the inversion of control design pattern, in which modular functionality is called  by the framework at the appropriate time.  These  opportunities for modules to do their thing are called  hooks. 

Hooks

Hooks  can be thought of as internal Drupal events. They are also called  callbacks, but because they are constructed by function naming conventions and  not by registering with a listener, they are not truly being called  back. Hooks  allow

modules to “hook into”  what  is happening in the rest of Drupal.

Suppose a user logs into your Drupal web site. At the time  the user logs in, Drupal fires hook_user_login. That means that any function named according to the convention module  name plus hook name will be called.  For example, comment_user_login() in the comment module, locale_user_login() in the localemodule, node_user_login() in the node

module, and  any other similarly named functions will be called.  If you were to write a custommodule called 

spammy.module and include a function called  spammy_user_login() that sent  an email to the user,  your function

would be called  too, and  the hapless user would receive an unsolicited e-mail at every login.

The most common way to tap into Drupal’s core functionality is through the implementation of hooks in modules.

Themes

When  creating a web page to send to a browser, there are really two main concerns: assembling the appropriate data and  marking up the data for the Web. In Drupal, the theme layer is responsible for creating the HTML (or JSON, XML, etc.)that the browserwill receive. Drupal uses PHP Template as the primary templating engine, or alternatively you can use theEasy Template System (ETS). Most developers stick with the standard templating engine when constructing new Drupal

themes. The important thing toremember is that Drupal encourages separation of content and  markup.

Drupal allows several ways to customize and  override the look and  feel of your web site. The simplest way is by using acascading style sheet (CSS) to override Drupal’s built-in classes and  IDs.

However, if you want  to go beyond this and  customize the actual HTML output, you’ll find it easy to do. Drupal’s template files consist of standard HTML and  PHP. Additionally, each  dynamic part  of a Drupal page,  such as a list or

breadcrumb trail, can be overridden simply  by declaring a function with an appropriate name. Then  Drupal will use your functioninstead to create that part  of the page.

Fields

Content in Drupal is composed of individual fields. A node title is a field, as is the node body.  You can use fields in Drupal to construct any content type that you can think of- for example, an Event. If you think about an Event, it typically contains a title, adescription (or body),  a start date, a start time,  a duration, a location, and  possibly a link to register for the event. Each of those elements represents a field. In Drupal we have the ability to create content types  using fields- either 

programmatically by creating amodule, or through the Drupal administrative interface by creating a new content type and assigning fields through the user interface. The great  news is that the Field API makes it extremely easy to create simple to complex content types  with very littleprogramming.

Blocks

A block is information that can be enabled or disabled in a specific location on your web site’s template. For example, a

block might display the number of current active  users on your site. You might have a block containing links to the mostpopular content onthe site, or a list of upcoming events. Blocks are typically placed in a template’s sidebar, header, or

footer. Blocks can be set to display on nodes of a certain type, only on the front  page,  or according to other criteria.

Often  blocks  are used to present information that is customized to the current user.  For example, the user  block containsonly links to the administrative areas of the site to which the current user  has access, such as the “My account” page. 

Regions where blocks  may appear (such as the header, footer, or right or left sidebar) are defined in a site’s theme; placement and  visibility of blocks  within those regions is managed through the web-based administrative interface.

File Layout

Understanding the directory structure of a default Drupal installation will teach you several important best  practices, such as where downloaded modules and  themes should reside and  how to have different Drupal installation profiles. A default

Drupal installationhas the structure shown in Figure 1-4.

Figure 1-4. The default folder structure of a Drupal installation

Details about each  element in the folder  structure follow:

•     The includes folder  contains libraries of common functions that Drupal uses.

•     The misc folder stores JavaScript and  miscellaneous icons  and  images available to a stock Drupal

installation.

•     The modules folder  contains the core modules, with each  module in its own folder. It is best  not to touch anything i

this folder  (or any other folder  except profiles and  sites). You add extra modules in the sites directory.

•     The profiles folder  contains different installation profiles for a site. If there are other profiles besides the default profile in

this subdirectory, Drupal will ask you which profile  you want  to install when first installing your Drupal site. The main e

purpose of an installation profile  is to enable certain core and  contributed modules automatically. An example would be an

-commerce profile that automatically sets up Drupal as an e-commerce platform.

•     The scripts folder  contains scripts for checking syntax, cleaning up code,  running Drupal from the command line,

handing special cases  with cron,  and running the  test suites (new in  Drupal 7). This folder  is not used within the

rupal request life cycle; these are shell and  Perl utility scripts.

•     The sites directory (see Figure 15) contains your modifications to Drupal in the form of settings, modules, and  themes.

When  you add modules to Drupal from the contributed modules repository or by writing your own, they go into sites/all/

modules. This keeps all your Drupal modifications within a single folder.  Inside the sites directory will be a subdirectory

named default that holds the default configuration file for your Drupal site- default.settings.php. The Drupal installer will 

modify these original settings based on the information you provide and  write a settings.php file for your site. The defaul

directory is typically copied and  renamed to the URL of your site by the person deploying the site,so your final settings fi

would be at sites/www.example.com/settings.php.

•     The sites/default/files folder  is included in the base  installation of Drupal by default. It is needed to store any files that 

are uploaded to your site and subsequently served out. Some examples are the use of a custom logo, enabling user

avatars,or uploading other media associated with your new site. This subdirectory requires read  and  write permissions by

the web server  that Drupal is running behind. Drupal’s installer will create this subdirectory if it can and  will check that the

correct permissions have been set. In addition to sites/default/files, a sites/default/private directory may be created for 

storing files that are sensitive in nature and  shouldn’t be displayed unless the site visitor has the proper credentials. You

create the private files directory by navigating to Configuration > File System and  entering the directory where you want

private files to reside in the text field titled Private file system path.

•     The themes folder  contains the template engines and  default themes for Drupal. Additional themes you download or

create should not go here;  they go into sites/all/themes.

•     cron.php is used for executing periodic tasks, such as pruning database tables and calculating statistics.

•     index.php is the main entry point for serving requests.

•     install.php is the main entry point for the Drupal installer.

•     update.php updates the database schema after a Drupal version upgrade.

•     xmlrpc.php receives XML- RPC requests and  may be safely deleted from deployments that do not intend to receive

XML-RPC requests.

•     robots.txt is a default implementation of the robot exclusion standard. 

•     authorize.php is an administrative script for running authorized file operations— for example, downloading an installing a new theme or module from Drupal.org.

Other files not listed  here  are documentation files.

Figure 1-5. The sites folder can store all your Drupal modifications.

Serving a Request

Having  a conceptual framework of what  happens when a request is received by Drupal is helpful, so this section provides a

quick walk through. If you want  to trace it yourself, use a good debugger, and  start at index.php, which is where Drupal

receives most ofits requests. The sequence outlined in this section may seem complex for displaying a simple web page, but

it is rife with flexibility. 

The Web Server’s Role

Drupal runs behind a web server,  typically Apache. If the web server  respects Drupal’s .htaccess file, some PHP

settings are initialized, and  the URL is examined. Almost all calls to Drupal go through index.php. For example, a call

to http://example.com/foo/bar undergoes the following process:

1.       The mod_rewrite rule in Drupal’s .htaccess file looks at the incoming URL and separates the base  URL from

the path. In our example, the path is foo/bar. 

2.      This path is assigned to the URL query parameter q.

3.       The resulting URL is http://example.com/index.php?q=foo/bar.

4.       Drupal treats foo/bar as the internal Drupal path, and  processing begins in index.php.

As a result of this process, Drupal treats http://example.com/index.php?q=foo/bar and http://example.com/foo/bar 

exactly the same way, because internally the path is the same in both casesThis enables Drupal to use URLs without

funny-lookingcharacters in them. These  URLs are referred to as clean URLs.

In alternate web servers, such as Microsoft IIS, clean URLs can be achieved using  a Windows Internet Server Application Programming Interface (ISAPI) module such as ISAPI Rewrite.  IIS version 7 and  later supports rewriting directly. If you are runningyour site on IIS 7 or later,  you’ll want  to check out the web.config file that enables clean URLs and  protects prying eyes from files that we really don’t want  them to have access to, like .install, .module, .test, .theme, .profile, .info, and  .inc files.

The Bootstrap Process

Drupal bootstraps itself on every request by going through a series  of bootstrap phases. These  phases are defined in

bootstrap.inc and  proceed as described in Table 1-1.

Table 1-1. Bootstrap Phases
Phase	Purpose
Configuration	Sets global variables used throughout the bootstrap process
Database	Initializes the database system and  registers auto load functions
Variables	Loads system variables and  all enabled bootstrap modules. Session Initializes session handling.
Page Header	Invokes hook_boot(), initializes the locking  system, and  sends the default HTTP headers
Language	Initializes all the defined language types.
Full	The final phase: Drupal is fully loaded by now. This phase validates and  fixes the input data.

Processing a Request

The callback function does  whatever work is required to process and  accumulate data needed to fulfill the request. For example, if a

request for content such as http://example.com/q=node/3 is received, the URL is mapped to the function node_page_view() innode.module. Further processing will retrieve the data for that node from the database and  put  it into a data structure. Then, it’s time  for theming.

Theming  the Data

Theming involves transforming the data that has been retrieved, manipulated, or created into HTML (or XML or other output format)Drupal will use the theme the administrator has selected to give the web page the correct look and  feel. The resulting outputis then sent  to the web browser (or other HTTP client).

Summary

 After reading this chapter, you should understand in general how Drupal works and  have an overview of what  happens when

Drupal serves  a request. The components that make up the web page serving process will be covered in detail in later chapters.