Monday, February 28, 2011

Using open source software to design, develop, and deploy a collaborative Web site, Getting started with Drupal

Techcloud Unlabelled 2:57 AM

Introduction
This article gives you an overview of the Drupal content management system. We describe the common building blocks and discuss some common assumptions of the Drupal approach. It is helpful to understand core concepts and basic Drupal terminology as you go through this article and beyond.

The Drupal content management system maintains its content in a database. Within the database, the content is stored as nodes and other high-level objects, such as users and comments. There are a variety of different, predefined node types including stories, blogs, and polls.
Drupal constructs pages that contain one or more pieces of information in the form of nodes, blocks, and other items. Each page is typically organized around a center column of content with left and right side-bars, and a header and footer. With the exception of the center column of content, the other areas are optional.
The center column is used to display the main site content; the optional areas are for additional content. Drupal uses blocks to fill the optional areas with small pieces of information. The optional areas typically hold navigation links (for example, most popular nodes) and other abbreviated content. Just like any content, blocks can be made dependent on the user's role, providing a customized view of the information.
One of the most important features of Drupal is the ability to extend the types of nodes available, such as your application-specific content, by writing custom node modules. Modules are extensions to Drupal that implement one or more hooks from a predefined interface. Hooks define user permissions, interact with the database, and provide an interface to edit the content.
The menu system controls the navigation of the Web site and is fully customizable through the user interface. By contrast, the menu hook function controls how URLs are formed, how URLs are translated, and what function a specific URL will call. Newcomers to Drupal are frequently misled by the name of this hook function because it is not really about menus. So be aware that this is a possible point of confusion when dealing with "menus" in Drupal.
The separation of content from presentation is enabled by a system that themes the pages based on templates. Most content can easily be structured and styled by defining a set of template, or tpl, files and theme functions.
Nodes can be organized into categories or taxonomies. Forums are an example of hierarchical content within a taxonomy.
All the content is accessed through a permissions system to control the access and editing of content on the Web site.
It is important to understand that we are presenting the steps we took to implement the required functions for our online community site. This information should not be interpreted as a rigid set of development guidelines that must be followed to develop a successful or functional Drupal site. Instead, use this article as a point of comparison during the development of your site.
Nodes
An important concept in Drupal is that all content is stored as a node. They are the basic building blocks for the system, and provide a foundation from which content stored in Drupal can be extended. Creating new node modules allows developers to define and store additional fields in the database that are specific to your site's needs. Nodes are classified according to a type. Each type of node can be manipulated and rendered differently based on its use case. A few of the standard node types include:

Pages: Simple nodes for displaying content (By using PHP, the content can be dynamically updated. Any piece of content can be dynamic with the inclusion of PHP.)
Blog entry: A node for maintaining an online journal or weblog
Forums: Sets of nodes and their comments (These nodes are grouped by assigning a taxonomy term.)
Story: Generic pages that expire after a certain date (These are similar to normal pages but can be styled differently.)
Comment: Special type of content that lets users make comments about content defined by other nodes (Comments are not a type of node and are stored in a separate table in the database.)

The database records a basic set of information for a node, including a title, teaser (or abstract), and body. Information about the creator, creation time, and status are recorded. Any additional information that your application needs generally means that you need to create a new node type that writes to database tables specifically defined for that node type.
Drupal implements a revision system for changes made to node content. This allows a module developer to cut a new database record for each update of a node in a table specifically allocated to node revisions. You can read more at Drupal revisions overhaul.
Taxonomy
The Drupal taxonomy system allows the classification of nodes, which enables the organization of node content on a displayed Web page. This categorization can also be used to modify Web site navigation.
Categories are defined by tags, or terms, and sets of terms can be grouped into a vocabulary. Drupal can automatically classify node content with terms, or node content can be manually classified using associated vocabularies. Drupal also allows free tagging, letting users define their own terms for node content.
Module developers can take advantage of nodes classified with categorization terms by using various organizational functions that the taxonomy module provides. This module also supplies functions that allow developers to add navigation to a page based on node content classification.
Comments
The Comment system is another feature of Drupal. A node can be configured to accept the attachment of threaded comments by a user group with the appropriate permissions. This enables users to post their comments on particular content presented in a Web page. Typically, the posts might appear on a forum topic or a weblog entry.

Blocks
Blocks are small, self-contained units of information typically displayed in navigation areas or side areas of the page, but can be placed anywhere on the page. They provide small views of information that are embedded in the presentation of other nodes. Modules provide basic blocks used to display their content. Administrators can create new blocks based on existing blocks, or write PHP code to directly query and render content inside a block.
In the configuration page in Figure 1, you can:

Enable or disable a registered block.
Order the presentation of the information by assigning a weight (-10 to 10, with the lower numbered items presented higher in the group).
Place blocks in the left or right sidebar, header, or footer or content region.

Figure 1. Specifying different blocks defined for our fictitious Web site
Specification of blocks

Modules
Modules are the main mechanism to extend Drupal. They implement a well-defined interface that allows the new modules to interact with the system and the system to interact with the module. Drupal calls the functions in this interface hooks. Drupal hooks are grouped into three categories; they are used in modules that:

Authentication: Provide additional user authentication mechanisms
Core: Need to respond and interact with the core Drupal code
Node: Provide a new node type to the system

Typically, you create a new module if you need to extend Drupal in any way. A common use case for a module is when the standard node table in the database does not contain the information that your application needs. A module implementing the node hooks can easily utilize an extended database schema to store any information that it requires. It is important to understand that a module does not need to implement all of Drupal's hooks; it only needs to implement the hooks that are required to implement the extension.
Once a module is created, you have to enable that module and assign access privileges to the various roles that are defined. Figure 2 shows part of the administrator's screen that enables a module (administer > modules). Here we have enabled the announcement and comment modules. This administrator's interface uses check boxes to enable or disable individual modules, such as our custom announcement module and the system-supplied comment module.

Figure 2. Enabling a module
Enable or disable individual modules

Hooks
To programmatically define a module, you need to create specific functions that conform to the syntax of predefined functions. These hooks enable the system to call the appropriate PHP function when viewing a page or storing information in the database. Each hook has a defined set of parameters and a defined returned type. The syntax of a hook is to prepend the module name in front of the defined interfaces. For example, a hook to delete a node that is of the type announcement is in the form announcement_delete(...). This hook allows your custom module to delete any information in the database that your module creates and should be removed when a given node is deleted.
Another example for viewing a node of the same type, announcement_view(...), would allow the module to filter content based on access privileges for the current user. An example for presenting content on a page is announcement_block(...). This enables the module to return a small container of themed content used as a block on any Web page.
A few of the basic hooks for node access, database interaction, and theming are described briefly below. A more detailed discussion will be in the next article, where we'll describe our custom announcement module.
Node access hooks
In this section we'll cover a few of the typical hooks that will need to be written for a new node module. All the documentation for the hooks is in the API reference for the appropriate release of Drupal. The hooks we describe are taken from our example announcement module and should be used as a guide rather than a strict recipe for module development.

<module_name>_perm

The perm hook defines the types of access permission that can be assigned to each user. The node module defines a few standard types: Listing 1. Implementing the perm hook from the node module

function node_perm() {
   return array('administer nodes', 'access content', 'view revisions', 
      'revert revisions');
}

The node module distinguishes between administering nodes, accessing content, and viewing and reverting revisions. These strings are used when assigning access privileges to different user roles (see Figure 4). Use the existing types if you can, but you can always create your own types if the semantics of your module differ. For example, if the announcement module needs to distinguish the create operation from the edit operation, you can supply a hook with create announcement and edit announcement values in the array.
The Drupal function user_access() makes it easy to check the current user's privileges against these string types. The function user_access('access content') returns TRUE if the current user has the "access content" privilege (that is, the user can view general content on the Web site). You will find this function commonly used in a module's menu hook, but feel free to use it wherever you need to evaluate a user's permissions before executing an action.

<module_name>_access

The access hook provides the ability to restrict access to particular operations on content. The node operation (view, create, update, delete, and so on) and node are passed in to help determine access privileges. By returning a Boolean value, you can enable or disable certain operations on the node. For instance, you might check to see if the current user is the author of the node to determine whether or not the user can carry out the current operation. To do this, you might use the following code shown in Listing 2. Listing 2. Example implementation for the access hook

function <module_name>_access($op, $node) {
   if ($op == 'update' ||  $op == 'delete') {
      if ($user->uid == $node->uid or user_access('edit <module_name>')) {
         return true;
      }
      else {
         return false;
      }
   }
}

The example access hook allows the update or delete operations to execute if the user initiating the request is the owner of the content, or if they have been explicitly granted permission to edit that type of content.

Node presentation hooks

<module_name>_form

The form hook defines the input widgets, like text fields, check boxes, and so on, used to add and edit a node for this module. Examples of this function are in the documentation for the appropriate release. The implementation of the form interface has changed between Drupal 4.6 and 4.7.

<module_name>_validate

The validate hook is used by modules to ensure that the data in the node is valid before posting to the Web site.

<module_name>_submit

The submit hook is used by modules to modify data in the node before posting to the Web site after the validate hook completes successfully.

<module_name>_view

The view hook provides the mechanism for the module to define the presentation of a node of this type. It first prepares the node by applying filters through the use of another hook, then generates the HTML through the theming process.

<module_name>_menu

The menu hook allows the module to define URL paths that it wants to handle. The return value is an array of items. Each item is an associative array that defines a unique URL. There are various options for the return values, ranging from normal items in a tree of paths to callback items that register a function to call for a particular path. An example of a menu hook function is shown in Listing 3. Listing 3. Example implementation of the menu hook

function <module_name>_menu() {
  $items = array();
  $items[] = array('path'     => '<module_name>', 
                   'title'    => t('Module Name'),
                   'access'   => user_access('access content'),
                   'type'     => MENU_SUGGESTED_ITEM,
                   'callback' => '<module_name>_page');
  return $items;
}

This example instructs Drupal to recognize the URL /<module_name>, use it in the default menu list, make sure only roles with "access content" permission can access it, and to use the <module_name>_page function when this URL is seen in the browser.

<module_name>_nodeapi

The nodeapi hook is a useful function if you need to interact with other modules in the system. For example, if the comment module is enabled, the comment_nodeapi() function would be called to extend the node object with data pertaining to any comment information associated with the node. The nodeapi hook can also be used for other events, including viewing, database access, searching, validating, and so on.

Node database hooks
The node and node_revisions tables in the database contain most of the information for a fragment of information stored in the system, such as title, teaser, body, creator, and creation time. This system allows many revisions of a node to be saved without sacrificing performance or scalability. When a new node module is written, typically one or more new tables are added to the database. The database hooks allow the module to create, modify, and delete data in the tables as new node content is created and modified in the system.
Drupal has a database abstraction layer that includes several functions that link the high-level Drupal database API to the low level PHP database module API for MySQL or PostgreSQL. Cross-database compatibility is achieved by implementing the database abstraction API for your database.
However, you need to consider one very important thing: To have a truly cross-database-compatible module, you must take great care to write SQL that works on all database platforms. Drupal does not provide a system or mechanism to handle those kinds of compatibility problems yet.

<module_name>_load

The load hook allows the module to load any additional information for a node of this type from additional tables in the database. The return value is an object containing the additional properties to be added. Drupal automatically merges them into the node being loaded. For example, the code might look like that shown in Listing 4. Listing 4. Example implementation of the load hook

function <module_name>_load($node) { 
 $additions = db_fetch_object(db_query('SELECT * FROM {<module_name>} WHERE nid = %s', 
                                      $node->nid));
 return $additions; 
}

The $additions are then automatically merged by the system into the results of loading the node.

<module_name>_insert

The insert hook signals the module to add data into the database for the node argument. Typically, this is a call to a function in the database abstraction layer (for example, db_query) to insert data about the node into the tables defined for this module. The standard data stored in the node database table, such as body, creation date, and so on, is written into the database automatically.

<module_name>_update

The update hook provides the mechanism for our module to update data for an existing node in the database. The update hook is also the most likely location to implement the code necessary to support node revisions for your module.

<module_name>_delete

The delete hook allows the module to take additional action when a node is being deleted from the database. Any module specific tables can be cleaned up at this time.

URL design
Drupal uses its menu system to define the navigation for the Web site. When building custom modules, you can specify how you want your module to serve the content based on the URL. When a page request is received, the system finds the closest match based on a hierarchical structure of paths. If a path is registered, it uses the defined function as a callback to produce the content presented. Any portion of the path can be used to select how the content is presented. For instance, if the path is /announcement/15/edit, an edit page for the node with id = 15 will be presented, in contrast to the path /announcement/15/view where the content of the node will just be displayed. The callbacks are defined in the <module_name>_menu hook.
Drupal also has a mechanism for defining the use of a tabbed interface. These tabs are specified in the menu system as "local tasks." When defining local tasks you can designate one as the default. The default local task is the first task presented to the user when they view a piece of content. We recommend that you always designate a default local task when using this feature.
The <module_name>_menu returns an array of menu specifications. The code snippet in Listing 5, repeated from above, shows one such specification to define a simple callback for a typical custom module.

Listing 5. One item from a code snippet of the menu hook

$items[] = array('path'     => '<module_name>', 
           'title'    => t('Module Name'),
                 'access'   => user_access('access content'),
                 'type'     => MENU_SUGGESTED_ITEM,
                 'callback' => '<module_name>_page');

In the specification the attributes include:

Path: When this matches the URL request, this item is in use.
Title: The title of the menu item.
Access: The value of this attribute determines whether or not the current user can access the content specified by this item.
Type: The type of menu specification.
Callback: The function called to produce the displayed content when this item is in use.

There are several different types of menu specifications, including:

MENU_NORMAL_ITEM: The default type used for menu items, and they show up in the menu tree.
MENU_ITEM_GROUPING: Groupings of items that simply list sub-pages to visit.
MENU_CALLBACK: Registers a function that is invoked to generate the content to present when the URL is accessed.
MENU_SUGGESTED_ITEM: Suggested items from modules may be enabled by the administrator.
MENU_LOCAL_TASK: These pages are rendered as tabs. Other renderings are possible.
MENU_DEFAULT_LOCAL_TASK: Every set of local tasks should also provide a default task that links to the same path as its parent when clicked.

Users
Another top-level object in the system is the user object, which allows you to set up accounts for different users coming to your site. As an administrator you can also create different roles for different access privileges to the content. Users can then be assigned to one or more of these roles. Note that the first user created when you configure your Drupal installation is the only account to have permissions to change any setting within the system.
An administrator can assign users to different roles as defined in the access control section of the Drupal administrative interface. Figure 3 shows the roles created for our fictitious Web site. In addition to the standard ones, we have added roles for administrators, customers, operations, and workgroup leaders.

Figure 3. Define roles to specify the level of user access to the content

Figure 4 shows the administrators screen to assign roles to access permissions within a module. The administrator's interface uses check boxes to enable or disable access privileges for actions related to modules for particular roles. The roles are listed across the top of the table while the permissions, grouped by module, are in the first column. The permissions are the strings specified in the <module_name>_perm hook. Classifying users into roles can segment the responsibility of tasks for different classes of users.

Figure 4. Administrator's interface to enable or disable access privileges

Interface to enable or disable access privilege

Customizing the look of your Web site
Drupal separates the content from the presentation using a theme system. You can theme your content using various theme engines within Drupal. While you can program a theme entirely with PHP, a theme engine provides a framework for development and can save time. Currently the PHPTemplate, XTemplate, and Smarty theme engines are available on the Drupal site. We chose to use the PHPTemplate engine because it is the default engine and offers a consistent use of PHP across the logic layer, the modules, and the presentation layer.
Standard theme functions
Understanding how the core theme code searches for the appropriate theme method is important for module developers. Modules should be written in a way that allows other system implementers to integrate the module's content into the look and feel of their site. Drupal currently searches for three PHP functions that build themed content, in the following order:

<theme name>_<content name>
This function is constructed from the current theme's name and the name of the content, or node type, that is being themed. If the current theme is named ibc, and we are theming the content announcement, then the theme function name would be ibc_announcement.
<theme engine name>_<content name>
This function is constructed from the current theme engine's name and the name of the content. We are using the PHPtemplate engine, so our theme function name for the content announcement would be phptemplate_announcement.
theme_<content name>
This is the last function and the simplest. If we are theming content announcement, the theme function name is simply theme_announcement.

A theme is defined using a collection of files within the Drupal themes directory. Drupal comes with the files you need for a theme and are dependent on your theme engine. You can customize your theme in many ways; we present our approach to altering the presentation of the data to get the xHTML structure, style, and layout we wanted for the Web site.
Template files
PHPTemplate allows you to map specific files, called template files, to specific functions and modules within Drupal. A template file, ending with .tpl.php, uses an array of data passed to it by its associated function or module. Using PHP and xHTML, this data can be manipulated to be presented on the Web page. There are generic templates for existing node types that Drupal provides to help you customize your theme. The page.tpl.php, node.tpl.php, and comment.tpl.php files are examples of the generic templates. They are within the theme directory. The page, defined by the page template, is used to contain the display of any node as defined by a node template.

page.tpl.php: This is probably where you would start customizing your own theme. This is the template that defines the structure of all pages of content displayed by Drupal. Here you can define your global structural elements of xHTML, such as the head and body elements, the include files for style sheets, the skeleton DIV elements that set up the semantics of your content layout, and so on.
node.tpl.php: This template is used to manipulate how to display node data. If you want to theme a node of a specific type, you make a copy the node.tpl.php file and change the filename to node-<type>.tpl.php, where <type> is the name of the node type. We changed the default layout of forum content by using a template called node-forum.tpl.php in the discussions section of the IBC Web site using this method.
comment.tpl.php: This template file controls the layout of a single comment. Comments can be added to pages using Drupal's Comment module.

Overriding existing theme functions
The PHPtemplate engine allows you to map templates to specific theme functions. Theme functions provide generic methods to build Web content that is used by modules providing core functions in Drupal, or by your own modules to extend Drupal.
One example is the theme_links function. Given an array of xHTML anchor elements (links), theme_links will return a string containing these links delimited by a given character. This is an example of a very simple building block. Listing 6 changes the output so that a DIV element with a class attribute of value links wraps the delimited list of links.
There is a special file you can use within an individual theme's directory called template.php. If this file exists, Drupal will use it to allow you to override default actions of the theme system. In the template.php file we can create a function as shown in Listing 6:

Listing 6. phptemplate_links function from the template.php file

function phptemplate_links($links, $delimiter = ' | ') {
  if (!is_array($links)) {
    return '';
  }
  $content = '<div class="links">';
  $content .= implode($delimiter, $links);
  $content .= '</div>';
  return $content;
}

Creating the function phptemplate_links in the template.php file, we instruct Drupal to override the default theme_links function. In the overriding function, we are wrapping the DIV element around the delimited list of links and returning the resulting string.
Theming within new modules
If you create a new module to extend Drupal functions, you need to tell Drupal how you want to display the data generated by the module. To make this extensible it is wise to set up a default presentation of the data within the module that is easily overridden by whatever theming system you, or someone else, choose to use.
Creating the default presentation
To generate the default themed output, we created a function within the module. This manipulates the data passed to it and returns the themed content in a string. An example might be the theming of a list of items in a module called shopping_list_items. The themed output is an xHTML unordered list of the items, as shown in Listing 7:

Listing 7. Theming the output as an unordered list of items

function theme_shopping_list_items($list = array()) {
   $content = '<ul>';
   foreach ($list as $list_item) {
      $content .= '<li>'.$list_item.'</li>';
   }
   $content .= '</ul>';
   return $content;
}

Then, in the part of your module where you build the Web page, you use Drupal theme function to call the theme_shopping_list_items function to return the themed list. The sequence of execution, shown in Listing 8, is then:

Listing 8. Theming a list of items

$tools = array('hammer', 'drill', 'saw');
$content .= theme('shopping_list_items', $tools);

Overriding the output of a module with a theme
As explained earlier, we can use the template.php file in the theme directory to override theme functions. Given the example above, assume we want to change the default action of displaying a list of items generated by the shopping_list_items module from an xHTML unordered list to an xHTML definition list, shown in Listing 9. We create this function in the template.php file or in the node module file.

Listing 9. Theming the output as a definition list

function phptemplate_shopping_list_items($items = array()) {
  $content = '<dl>';
  foreach ($items as $list_item) {
    $content .= '<dt>'.$list_item.'<dt>';
  }
  $content .= '</dl>';
  return $content;
}

Since Drupal knows that our theme is using the PHPtemplate engine, it will automatically override the theme_shopping_list_items function in the shopping_list module with this new function. The result is an xHTML definition list of your tools. Taking this one step further, we can tell Drupal to use a template file to define the presentation of this list by defining the file name within this overriding function, as shown in Listing 10.

Listing 10. Function using a template file for theming

function phptemplate_shopping_list_items($items = array()) {
  $template_file = 'shopping_list_items';
  $content = _phptemplate_callback('shopping_list_items', 
                                   array('items' => $items), $template_file); 
  return $content;
}

Where the template file might contain the following code:

Listing 11. Code fragment from template file to present the list of items

<dl>
<?php foreach ($items as $list_item) : ?>
 <dl><?php print $list_item; ?></dl>
<?php endforeach; ?>
</dl>

Here we are using our knowledge of the PHPtemplate engine. The _phptemplate_callback function connects our call to phptemplate_shopping_list_items to a template file called shopping_list_items.tpl.php with the variable named list_items set to the $items array. This method of theming content is preferred because it cleanly separates the bulk of the PHP code from the xHTML.
Content structure and style
We describe the mechanics of using Drupal's theming system to extend and modify the default presentation of content. An additional aspect is to consider the structure of the content generated by each node and the overall style applied to that structure. Using the PHPtemplate engine allows Web designers to maintain structured xHTML for the data generated by modules. This option also allows the use of Cascading Style Sheets (CSS) to alter the presentation or style of this structure. We found it helpful to keep the data production within the module and xHTML production within the templates to preserve the separation of data and presentation.
The structure of the overall Web page is shaped by the page.tpl.php file within the theme directory. In this file, xHTML can be used to define the basic layout of a Web page into which other node content is included. Since the location of the header, body, sidebar, and footer remain the same in our Web site, these structures are defined here.
We were careful to use the correct xHTML markup for our navigational elements, section headings, and so forth, so our Web site content is still presented in a reasonable format even if the styling is not available.
One of the variables presented to this template by the Drupal theme system can flag whether the front page is being displayed. With minimal PHP, we used this variable to help us structure the xHTML slightly differently than the sub-pages of the Web site.
Using the methods mentioned in the previous section, we used template files for all node generated output, therefore controlling the content structure in one theme directory. The output of each node template was structured consistently, usually contained within a DIV element whose class attribute value would describe the template being used. Not only did this help the styling of the content, but provided a debugging aid when looking at page source to determine which template generated what content.
We referenced the screen and print media style sheets in the Web page header as defined in the page.tpl.php file. To categorize and manage the style, we chose to break the CSS styling into separate files and include them into the main screen media style sheet file. The base styles of common xHTML elements were contained within one CSS style sheet, the layout in another, and the style modifications to the Web site sections in their own files. As with the template files, all of the style sheet files were contained within the theme directory.

Node-building sequence
In this section we'll explore how Drupal builds a node. It is useful to understand the sequence in which Drupal collects the information for a particular node, how the core system interacts with a module, and how this node is rendered before being presented within the Web page. This is intended as an overview, so some level of detail will remain outside the scope of this section. Figure 5 shows the flow of a node building sequence.

Figure 5. Summary flow of the node building sequence for a View operation
Summary of the node building sequence.

See a larger version of this figure.
The path in a URL request is structured so that /node/, or the node type, is followed by the node id and then the node operation. If the path is /node/15/edit, this tells Drupal that an edit form for node 15 should be displayed. The only exception to this structure is when the URL path is /node/add or /node/add/<node_type> and Drupal knows to apply the Add operation.
In this section you learn about the following four operations:

View: The default operation that builds a node page for viewing only.
Add: The operation that presents a form with which to add a new node.
Edit: The operation that presents a form to edit an existing node.
Delete: The operation that deletes the node from the Drupal system.

Remember that the menu system knows what function to call based on the URL given. We will start this explanation of the node building sequence at the point where the menu system calls the node_page() function in the node.module.
The first thing Drupal needs to do is determine the operation. If no operation is found following the node id in the URL, a default operation of view is assumed.
The View operation
Before any rendering of the node can proceed, a container for all the data associated with this node is created. This node object is populated with data from the database record in the node and node_revisions tables, whose primary key field value is the same as the node id in the URL. This data includes the node type, title, teaser, body, creator, and creation time.
Next, any extended data is applied to this node object. This is done through two hooks, load and nodeapi. The nodeapi hook provides another way for any module to extend Drupal's core operations: load, view, prepare, delete.
Since the node_type is already known, Drupal uses this to establish whether a <node_type>_load() function exists. For example, if the node type is announcement, then the announcement_load() function is called, where it might extend the default node information with a publish and expiration date for the announcement.
Now, Drupal invokes any nodeapi hooks in all the available modules. This function call includes an argument signifying that Drupal is loading the node object and allows the insertion of extra data into this object from any module.
Drupal then stores the node title, which it can use for inclusion in the Web page title later in the request life cycle.
Drupal now starts the process of rendering the node object data into content. The default action is to create and store the themed output for the node body and teaser. If Drupal finds a <node_type>_view() hook, then this will be called to override the theming of these content fragments. For example, if the node type is announcement, then the announcement_view() function might return a themed content fragment for the publish and expiration dates of an announcement, in addition to the body and teaser content.
As with the load section of this sequence, Drupal now looks for any nodeapi hooks in all the available modules. This function call includes an argument signifying that Drupal is theming the node object data and allows any module to change or extend the content in the themed body fragment. This is then stored in the node object.
Links are another type of content that can be added to the node object. They offer additional themed Web links to the node content, and Drupal allows any module to add these through the link hook.
Drupal then checks if comments should be rendered for this node. It uses any comment data stored in the node object to theme the content fragments required before storing these back in the node object.
Finally, the node object, with all its data and themed content, is passed to the Theming system for rendering as a themed node. At this point our node is fully built and ready for display.
The Add operation
When the URL path tells Drupal to add a node, the node building sequence is significantly different from the View operation. First, Drupal checks to determine whether the node type in the URL path exists and, if it exists, if the user making this request has the authority to create a new node. If these conditions are met, Drupal starts to assemble a form required to add a node of this node type. If not, a page is presented listing the available node types.
As with the View operation, Drupal creates a node object that stores any data that may be used to render the form. As part of the preparation of the data for this node object, Drupal invokes the <node_type>_prepare() hook, if it exists. This provides the opportunity for the associated module to preprocess any data that requires inclusion into the node object.
To allow any other modules the ability to append or modify the node object, all nodeapi hooks are called with an argument signifying that Drupal is preparing to show the add form.
Now Drupal constructs the data structure that describes the form widgets given the node object data. Before rendering the form, the <module_name>_form_alter() hook is invoked in any modules, allowing the modification of the form data structure. For example, the taxonomy module can use its form_alter hook to insert a form to select classification terms defined for this node type.
Finally, the form data structure is used to render the resulting node presenting the form.
The Edit operation
The Edit operation is similar to the Add operation except a node id is provided in the URL path.
When building a node using the Edit operation, Drupal once again creates a node object to store the data it uses to render the resulting page. As described in View operation, the <module_name>_load and <module_name>_nodeapi hooks are called to allow modules to append or modify the node object data. Of course, if the given node id is not found in the database or the access permissions to edit this node are forbidden, then an appropriate response is presented on the Web page through the Drupal message system.
In the situation where the node id is found and access to Edit is allowed, Drupal follows a process similar to the one described in the Add operation. However, since the node object contains data associated with the given node, the form data structure presents that data within the form widgets when they are rendered.
The Delete operation
Drupal handles the Delete operation in a slightly different way compared to the other operations. While the process creates and populates the node object like the View and Edit operations do, this data is not used in the same way to render the node or form to edit the node data. Instead, the access permissions to delete a node are checked. Drupal then creates a simple form that is rendered to a Web page asking the user to confirm this delete operation.
While the point of this section is not to describe the Drupal form submission process, it is useful to know that the <module_name>_delete and <module_name>_nodeapi hooks are invoked to allow modules to clean up any extended database tables or variables associated with this node type.

Summary
In this article you are introduced to the concepts, terminology, and techniques used in Drupal. These building blocks form the core of the Drupal approach. You learned about:

Nodes
Blocks
Modules and the hook interface
URL design and the menu system
Users and permissions
Theming the look of your Web site
The node building sequence

Even though this is a partial introduction, these concepts are key to your understanding the inner workings of Drupal. As soon as you know the basics, it is easier to move forward customizing your environment and Web site.
The next article in this series, Part 6, extends Drupal with a custom module to create announcements for our Web site. You'll get more details about our module, including specific examples of code.

Resources
Learn

Learn more about this series, where the Internet Technology Group team describes a fictitious organization that requires a customized Web site that includes, among other things, document storage, discussion groups, specialized workgroups, conference scheduling, and schedule session descriptions.
The Drupal site has useful documentation relevant to this article:
RSS feed for this series. (Find out more about RSS.)
Stay current with developerWorks technical events and webcasts.

Get products and technologies

Part 14 provides the complete announcement module download.
Build your next development project with IBM trial software, available for download directly from developerWorks.

Discuss

Participate in the discussion forum.
Participate in developerWorks blogs and get involved in the developerWorks community.

Tech News and Updates

Monday, February 28, 2011

Using open source software to design, develop, and deploy a collaborative Web site, Getting started with Drupal

About The Author

Techcloud

No comments:

Post a Comment

Labels

Popular Posts

Followers