CHAPTER 7 ■ WORKING WITH NODES
Providing Information About Our Node Type
Now you’re ready to add hooks to job_post.module. The first hook you’ll want to implement is hook_node_info(). Drupal calls this hook when it’s discovering which node types are available. You’ll provide some metadata about your custom node.
/**
* Implements hook_node_info() to provide our job_post type. */
function job_post_node_info() { return array(
'job_post' => array( 'name' => t('Job Post'), 'base' => 'job_post',
'description' => t('Use this content type to post a job.'), 'has_title' => TRUE,
'title_label' => t('Job Title'), 'help' => t('Enter the job title,
job description, and the name of the company that posted the job'),
),
);
}
A single module can define multiple node types, so the return value should be an array. Here’s the breakdown of metadata values that may be provided in the node_info() hook:
"name": The human-readable name of the node type. Required.
"base": The base string used to construct callbacks corresponding to this node type (i.e., if base is defined as example_foo, then example_foo_insert will be called when inserting a node of that type). This string is usually the name of the module, but not always. Required.
"description": A brief description of the node type. Required.
"help": Help information shown to the user when creating a node of this type. Optional (defaults to '').
"has_title": Boolean indicating whether this node type has a title field. Optional (defaults to TRUE).
"title_label": The label for the title field of this content type. Optional (defaults to “Title”).
"locked": Boolean indicating whether the administrator can change the machine name of this type. FALSE = changeable (not locked), TRUE = unchangeable (locked). Optional (defaults to TRUE).
144
CHAPTER 7 ■ WORKING WITH NODES
■ Note The internal name field mentioned in the preceding list (base) is used for constructing the URL of the “Create content” links. For example, we’re using job_post as the internal name of our node type (it’s the key to the array we’re returning), so to create a new job_post, users will go to http://example.com/?q=node/ add/job_post. Usually it’s not a good idea to make this modifiable by setting locked to FALSE. The internal name is stored in the type column of the node and node_revisions tables.
Modifying the Menu Callback
Having a link on the “Create content” page isn’t necessary for implementing hook_menu(). Drupal will automatically discover your new content type and add its entry to the http://example.com/?q=node/add page, as shown in Figure 7-2. A direct link to the node submission form will be at http://example. com/?q=node/add/job_post. The name and description are taken from the values you defined in job_post_node_info().
Figure 7-2. The content type appears on the page at http://example.com/node/add.
If you do not wish to have the direct link added, you could remove it by using hook_menu_alter(). For example, the following code would remove the page for anyone who does not have “administer nodes” permission.
/**
* Implements hook_menu_alter(). */
function job_post_menu_alter(&$callbacks) {
//If the user does not have 'administer nodes' permission,
//disable the job_post menu item by setting its access callback to FALSE. if (!user_access('administer nodes')) {
$callbacks['node/add/job_post']['access callback'] = FALSE;
//Must unset access arguments or Drupal will use user_access()
145
CHAPTER 7 ■ WORKING WITH NODES
// as a default access callback. unset($callbacks['node/add/job_post']['access arguments']);
}
}
Defining Node-Type–Specific Permissions with hook_permission()
Typically the permissions for module-defined node types include the ability to create a node of that type, edit a node you have created, and edit any node of that type. These are defined in hook_ permission() as create job_post, edit own job_post, edit any job_post, and so on. You’ve yet to define these permissions within your module. Let’s create them now using hook_permission():
/**
* Implements hook_permission(). */
function job_post_permission() { return array(
'create job post' => array(
'title' => t('Create a job post'), 'description' => t('Create a job post'),
),
'edit own job post' => array( 'title' => t('Edit own job post'),
'description' => t('Edit your own job posting'),
),
'edit any job post' => array( 'title' => t('Edit any job post'),
'description' => t('Edit any job posting'),
),
'delete own job post' => array( 'title' => t('Delete own job post'),
'description' => t('Delete own job posting'),
),
'delete any job post' => array( 'title' => t('Delete any job post'),
'description' => t('Delete any job posting'),
),
);
}
Now if you navigate over to People and click the Permissions tab, the new permissions you defined are there and ready to be assigned to user roles.
146
CHAPTER 7 ■ WORKING WITH NODES
Limiting Access to a Node Type with hook__node_access()
You defined permissions in hook_permission(), but how are they enforced? Node modules can limit access to the node types they define using hook_node_access(). The superuser (user ID 1) will always bypass any access check, so this hook isn’t called in that case. If this hook isn’t defined for your node type, all access checks will fail, so only the superuser and those with “administer nodes” permissions will be able to create, edit, or delete content of that type.
/**
* Implements hook_node_access(). */
function job_node_access($op, $node, $account) { $is_author = $account->uid == $node->uid; switch ($op) {
case 'create':
// Allow if user's role has 'create joke' permission. if (user_access('create job', $account)) {
return NODE_ACCESS_ALLOW;
}
case 'update':
//Allow if user's role has 'edit own joke' permission and user is
//the author; or if the user's role has 'edit any joke' permission. if (user_access('edit own job', $account) && $is_author ||
user_access('edit any job', $account)) { return NODE_ACCESS_ALLOW;
}
case 'delete':
//Allow if user's role has 'delete own joke' permission and user is
//the author; or if the user's role has 'delete any joke' permission. if (user_access('delete own job', $account) && $is_author ||
user_access('delete any job', $account)) { return NODE_ACCESS_ALLOW;
}
}
}
The preceding function allows users to create a job post node if their role has the “create job post” permission. They can also update a job post if their role has the “edit own job post” permission and they’re the node author, or if they have the “edit any job post” permission. Those with “delete own job post” permission can delete their own job post, and those with “delete any job post” permission can delete any node of type job post.
One other $op value that’s passed into hook_node_access() is view, allowing you to control who views this node. A word of warning, however: hook_node_access() is called only for single node view pages. hook_node_access() will not prevent someone from viewing a node when it’s in teaser view, such as a multinode listing page. You could get creative with other hooks and manipulate the value of $node- >teaser directly to overcome this, but that’s a little hackish. A better solution is to use hook_node_grants(), which we’ll discuss shortly.
147