C H A P T E R 7

■ ■ ■

Working with Nodes

This chapter will introduce nodes and node types. I’ll show you how to create a node type in two different ways. I’ll first show you the programmatic solution by writing a module that uses Drupal hooks. This approach allows for a greater degree of control and flexibility when defining what the node can and can’t do. Then I’ll show you how to build a node type from within the Drupal administrative interface. Finally, we’ll investigate Drupal’s node access control mechanism.

■ Tip Developers often use the terms node and node type. In Drupal’s user interface, they are referred to as posts and content types, respectively, in an effort to use terms that will resonate with site administrators.

So What Exactly Is a Node?

One of the first questions asked by those new to Drupal development is, “What is a node?” A node is a piece of content. Drupal assigns each piece of content an ID number called a node ID (abbreviated in the code as $nid). Generally each node has a title also, to allow an administrator to view a list of nodes by title.

■ Note If you’re familiar with object orientation, think of a node type as a class and an individual node as an object instance. However, Drupal’s code is not 100% object-oriented, and there’s good reason for this (see http://api.drupal.org/api/HEAD/file/developer/topics/oop.html).

There are many different kinds of nodes, or node types. Some common node types are “blog entry,” “poll,” and “forum.” Often the term content type is used as a synonym for node type, although a node type is really a more abstract concept and can be thought of as a derivation of a base node, as Figure 7-1 represents.

The beauty of all content types being nodes is that they’re based on the same underlying data structure. For developers, this means that for many operations you can treat all content the same programmatically. It’s easy to perform batch operations on nodes, and you also get a lot of functionality

137

CHAPTER 7 ■ WORKING WITH NODES

for custom content types out of the box. Searching, creating, editing, and managing content are supported natively by Drupal because of the underlying node data structure and behavior. This uniformity is apparent to end users, too. The forms for creating, editing, and deleting nodes have a similar look and feel, leading to a consistent and thus easier-to-use interface.

Figure 7-1. Node types are derived from a basic node and may add fields.

Node types extend the base node, usually by adding their own data attributes. A node of type poll stores voting options such as the duration of the poll, whether the poll is currently active, and whether the user is allowed to vote. A node of type forum loads the taxonomy term for each node so it will know where it fits in the forums defined by the administrator. blog nodes, on the other hand, don’t add any other data. Instead, they just add different views into the data by creating blogs for each user and RSS feeds for each blog. All nodes have the following attributes stored within the node and node_revisions database table:

•nid: A unique ID for the node.

•vid: A unique revision ID for the node, needed because Drupal can store content revisions for each node. The vid is unique across all nodes and node revisions.

•type: Every node has a node type—for example, blog, story, article, image, and so on.

•language: The language for the node. Out of the box, this column is empty, indicating language-neutral nodes.

•title: A short 255-character string used as the node’s title, unless the node type declares that it does not have a title, indicated by a 0 in the has_title field of the node_type table.

•uid: The user ID of the author. By default, nodes have a single author.

138

CHAPTER 7 ■ WORKING WITH NODES

•status: A value of 0 means unpublished; that is, content is hidden from those who don’t have the “administer nodes” permission. A value of 1 means the node is published and the content is visible to those users with the “access content” permission. The display of a published node may be vetoed by Drupal’s nodelevel access control system (see the “Limiting Access to a Node Type with hook_access()” and “Restricting Access to Nodes” sections later in this chapter). A published node will be indexed by the search module if the search module is enabled.

•created: A Unix timestamp of when the node was created.

•changed: A Unix timestamp of when the node was last modified. If you’re using the node revisions system, the same value is used for the timestamp field in the node_revisions table.

•comment: An integer field describing the status of the node’s comments, with three possible values:

•0: Comments have been disabled for the current node. This is the default value for existing nodes when the comment module is disabled. In the user interface of the node editing form’s “Comment settings” section, this is referred to as Disabled.

•1: No more comments are allowed for the current node. In the user interface of the node editing form’s “Comment settings” section, this is referred to as “Read only.”

•2: Comments can be viewed, and users can create new comments. Controlling who can create comments and how comments appear visually is the responsibility of the comment module. In the user interface of the node editing form’s “Comment settings” section, this is referred to as Read/Write.

•promote: An integer field to determine whether to show the node on the front page, with two values:

•1: Promoted to the front page. The node is promoted to the default front page of your site. The node will still appear at its normal page, for example, http://example.com/?q=node/3. It should be noted here that, because you can change which page is considered the front page of your site at Configuration -> Site information, “front page” can be a misnomer. It’s actually more accurate to say the http://example.com/?q=node page will contain all nodes whose promote field is 1. The URL http://example.com/?q=node is the front page by default.

•0: Node isn’t shown on http://example.com/?q=node.

•sticky: When Drupal displays a listing of nodes on a page, the default behavior is to list first those nodes marked as sticky, and then list the remaining unsticky nodes in the list by date created. In other words, sticky nodes stick to the top of node listings. A value of 1 means sticky, and a value of 0 means, well, unsticky. You can have multiple sticky nodes within the same list.

139