CHAPTER 7 ■ WORKING WITH NODES

Creating a Node Type with Custom Content Types

Although creating a node module like you did with job_post.module offers exceptional control and performance, it’s also a bit tedious. Wouldn’t it be nice to be able to assemble a new node type without doing any programming? That’s what Drupal core’s custom content types do for you.

You can add new content types (such as a job_post content type) through the administrative interface at Structure -> Content types. Make sure to use a different name for the node type if you have job_post.module enabled to prevent a namespace collision. In the job_post.module example, you needed three fields: job title, job description (the node’s body), and the name of the company posting the job. In the job_post module, you had to manually add the body field and the name of the company that posted the job. Using Drupal core’s custom content types, you can eliminate all of the programming and simply create the node through the user interface. Drupal core handles all of the tasks of creating the tables, the insert, update, delete, access controls, and viewing nodes.

Restricting Access to Nodes

There are several ways to restrict access to nodes. You have already seen how to restrict access to a node type using hook_access() and permissions defined using hook_permissions(). But Drupal provides a much richer set of access controls using the node_access table and two more access hooks: hook_node_grants() and hook_node_access_records().

When Drupal is first installed, a single record is written to the node_access table, which effectively turns off the node access mechanism. Only when a module that uses the node access mechanism is enabled does this part of Drupal kick in. The function node_access_rebuild() in modules/node/node.module keeps track of which node access modules are enabled, and if they are all disabled, this function will restore the default record, which is shown in Table 7-2.

Table 7-2. The Default Record for the node_access Table

In general, if a node access module is being used (that is, one that modifies the node_access table), Drupal will deny access to a node unless the node access module has inserted a row into the node_access table defining how access should be treated.

Defining Node Grants

There are three basic permissions for operations on nodes: view, update, and delete. When one of these operations is about to take place, the module providing the node type gets first say with its hook_access() implementation. If that module doesn’t take a position on whether the access is allowed (that is, it returns NULL instead of TRUE or FALSE), Drupal asks all modules that are interested in node access to respond to the question of whether the operation ought to be allowed. They do this by responding to hook_node_grants() with a list of grant IDs for each realm for the current user.

157

CHAPTER 7 ■ WORKING WITH NODES

What Is a Realm?

A realm is an arbitrary string that allows multiple node access modules to share the node_access table. For example, acl.module is a contributed module that manages node access via access control lists (ACLs). Its realm is acl. Another contributed module is taxonomy_access.module, which restricts access to nodes based on taxonomy terms. It uses the term_access realm. So, the realm is something that identifies your module’s space in the node_access table; it’s like a namespace. When your module is asked to return grant IDs, you’ll do so for the realm your module defines.

What Is a Grant ID?

A grant ID is an identifier that provides information about node access permissions for a given realm. For example, a node access module—such as forum_access.module, which manages access to nodes of type forum by user role—may use role IDs as grant IDs. A node access module that manages access to nodes by US zip code could use zip codes as grant IDs. In each case, it will be something that is determined about the user: Has the user been assigned to this role? Or is this user in the zip code 12345? Or is the user on this access control list? Or is this user’s subscription older than one year?

Although each grant ID means something special to the node access module that provides grant IDs for the realm containing the grant ID, the mere presence of a row containing the grant ID in the node_access table enables access, with the type of access being determined by the presence of a 1 in the grant_view, grant_update, or grant_delete column.

Grant IDs get inserted into the node_access table when a node is being saved. Each module that implements hook_node_access_records() is passed the node object. The module is expected to examine the node and either simply return (if it won’t be handling access for this node) or return an array of grants for insertion into the node_access table. The grants are batch-inserted by node_access_ acquire_grants(). The following is an example from node_access_example.module. In this module, hook_node_access_records checks to see if the node is private—if so, then grants are set to view only. The second grant checks to see if the user is the author of the node—if so, then all grants (view, update, delete) are set.

function hook_node_access_records($node) {

//We only care about the node if it has been marked private. If not, it is

//treated just like any other node and we completely ignore it.

if ($node->private) { $grants = array(); $grants[] = array(

'realm' => 'example', 'gid' => 1, 'grant_view' => 1, 'grant_update' => 0, 'grant_delete' => 0, 'priority' => 0,

);

158

CHAPTER 7 ■ WORKING WITH NODES

//For the example_author array, the GID is equivalent to a UID, which

//means there are many many groups of just 1 user.

$grants[] = array(

'realm' => 'example_author', 'gid' => $node->uid, 'grant_view' => 1, 'grant_update' => 1, 'grant_delete' => 1, 'priority' => 0,

);

return $grants;

}

}

The Node Access Process

When an operation is about to be performed on a node, Drupal goes through the process outlined in Figure 7-8.

159

CHAPTER 7 ■ WORKING WITH NODES

Download from Wow! eBook <www.wowebook.com>

Figure 7-8. Determining node access for a given node

160