Modules
Drupal is a truly modular framework. Functionality is included in modules, which can be enabled or disabled (some required modules cannot be disabled). Features are added to a Drupal Web site by enabling existing modules, installing modules written by members of the Drupal community, or writing new modules. 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.
Both the addition of new content types such as recipes, blog posts, or files, and the addition of new behaviors such as e-mail notification, peer-to-peer publishing, and aggregation are handled through modules. 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, though 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 the user hook. That means that any function named according to the convention module name plus hook name will be called. For example, comment_user() in the comment module, locale_user() in the locale module, node_user() in the node module, and any other similarly named functions will be called. If you were to write a custom module called "spammy.module" and include a function called "spammy_user()" that sent an e-mail 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 that the browser will receive. Drupal can use several popular templating approaches, such as Smarty, Template Attribute Language for PHP (PHPTAL), and PHPTemplate. The important thing to remember 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 a cascading 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 box, list, or breadcrumb trail) can be overridden simply by declaring a function with an appropriate name. Then Drupal will use your function instead.
Nodes
Content types in Drupal are derived from a single base type referred to as a node. Whether it's a blog entry, a recipe, or even a project task, the underlying data structure is the same. The genius behind this approach is in its extensibility. Module developers can add features like ratings, comments, file attachments, geolocation information, and so forth for nodes in general without worrying about whether the node type is blog, recipe, or so on. The site administrator can then mix and match functionality by content type, for example, choosing to enable comments on blogs but not recipes or enabling file uploads for project tasks only.
Nodes also contain a base set of behavioral properties that all other content types inherit. Any node can be promoted to the front page, published or unpublished, or even searched. And because of this uniform structure, the administrative interface offers a batch editing screen for working with nodes.
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 the most active users, 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, a navigation block contains links to only the administrative functions to which the current user has access. Placement and visibility of blocks is managed through the web-based administrative interface.
