As was discussed earlier, the base of nodes is the title and body fields. Pages and stories are both built from just titles and bodies, but then have different default settings. Similarly, blogs are very basic nodes with just titles and bodies. Drupal adds extra code, however, to make them feel more bloggish. This includes creating a page for each user's blog that collects the posts as well as offering an additional blog API for interactions with outside blog software. The Ann Arbor District Library uses the Blog module to manage a director blog as well as update blogs from different departments. The main page of the site at is built from blog posts being promoted to the front page.

Ann Arbor Distric Library Web site http://aadl.org

The Book module does not let you add information about a book, but it is used to group together a series of page nodes into a larger hierarchal node like chapters in a book. Pairing this with Drupal's revision control system is Drupal's answer to a wiki. While not quite a wiki, it provides a very powerful way for a community to co-author a Web document (see figure 20)

Drupal makes it very easy to create new nodes, but not always so easy to provide links to nodes that are referenced by a number. A URL of /node/1234 doesn't provide the same level of awareness as one with an address of /about or /contact. The Path module provides an additional, collapsed interface at the bottom of nodes that allows users with the proper permission to provide an alternate node path. This would be especially useful for libraries that might want to maintain a current site structure during an upgrade to Drupal. Using the Path module would preserve the URLs of pages that might be referenced by external links. This also allows a library to create shorter and more descriptive URLs for inclusion in print advertising.

The Poll module provides an interface for asking a question with a number of possible answers. Additional code in the module manages the full poll experience, including restricting potential voters from seeing the results until after they submit their vote. Administrative controls allow you to set options, including whether or not users can change their votes and deciding who can see the way different users voted. The Poll module also enables a special block that displays the latest poll. Libraries could use polls on their site to garner feedback about new programs or to give users a chance to interact by voting for a favorite book character (see figure 21)

Libraries can use the Profile module to create profiles for users on a Drupal site. Profiles extend the user account information and allow the inclusion of custom fields. This could be used to hold patron barcodes, addresses, or other needed information. It should be noted, however, that profiles do not have a mechanism for moderation or security. If it will be necessary to approve content before it goes live, then the contributed Biography module would be a better choice.

In addition to the content embedded in a node, you can also attach files to a node using the Upload module. This module provides extensive administrative control over the type and size of files that can be attached to a node. Permissions can be set for individual file size as well as combined size for all uploads. Files are attached through a standard browsing interface, and then managed for display or deletion within the node. Multiple files can be uploaded to a single node, though only the first will be sent as part of the RSS feed (see figure 22).

The default forums provide a basic level of interaction, but if you want to really add forums as a social component on your library Web site, it may be better to install the Advanced Forum module. This adds additional display features, including user icons and the number of posts a user has made.

Drupal core has the Profile module, which lets you add new information fields to the user information. The Profile module predates CCK and works differently from CCK. In addition, CCK works only on content nodes, not on other pieces of data in Drupal, such as users. Even though it is younger, CCK has many advantages over the Profile module, including many more contributed modules. As of Drupal 5, Views worked only with nodes and did not produce lists of users, so if you wanted user displays with Views, you needed a way to create a unique node for each user.

The Biography module lets you create a node for each user. It was designed for bio sections on Web sites so that users on community sites could have a page with their biographical information. There are also other modules that create unique nodes for other users, such as Nodeprofile, which was created explicitly for using CCK and Views with users.

We have found that we use the Biography module when we want the user information to be displayed as a public profile. For our student sites, where we keep information such as full name, teacher, grade, etc., we use the core Profile module. For one thing, the core modules are extremely reliable, and we want to be certain of safeguarding the information for privacy issues (not that we are storing anything more private than teacher and grade). But being part of core, the Profile module also integrates well with some other very important modules, such as User Import, which imports users from a comma delimited text file, creates the users, and fills in the appropriate profile fields.

Image support in Drupal can be a little frustrating. You want a module that lets you upload your images to your content, but it can take a couple of modules and a little work in the admin pages to make this happen. Using CCK, you can use the ImageField module to create a new field in your content type for uploading and attaching images to your content. Then using the ImageCache module, you can get these images automagically resized to predefined sizes. You can use these predefined sizes in your node teaser views, full views, or in any lists created by the Views module.

Nodequeue is a very simple module that creates lists of nodes. For example, a library could create a Nodequeue of featured book reviews. At the bottom of every book review node, there would be a link to either add the review to the featured list or remove a review from the list. Nodequeue lists can then be displayed as blocks in a variety of spots on a site (see figure 23).

The Pathauto module extends the power of the Path module by automatically creating the path that is used based on the user's configurations. Generally, the most popular configuration is to creates paths from the node type and the titles. By necessity, the spaces will be replace with underscores, so you will often see sites with page URLs that end in something like /how_drupal_will_save_world.

The Signup module lets users sign up for any node that the administrator configures. This is a great quick way to add registration to workshops on your site. Instead of using an outside site for registration, your users can register right from your Web site, get e-mail confirmation, and even get an e-mail reminder a couple of days before the event happens. The Signup module lets you define what fields the user needs to enter. As of this writing, the Signup module requires that you to do a slight amount of “hacking on code” if you want anything more than a name and phone number on your registration form. This is documented in the Signup module, specifically in the Signup.theme file.

Drupal has a very basic but powerful work flow built in with the node's publishing options. But if you need to add more layers to your work-flow process, you will want the Workflow module. Designed for online newspaper sites, the Workflow module is flexible enough to fit a wide variety of workplace settings. We are using it to provide a higher level of moderation to prevent any student-created content from going live on a site before it is approved by a librarian (see figure 24).

If you want to provide a link in your node, the best option is to use the Link module. There are other modules that you might come across with similar names—Weblinks and Links—but the Link module seems to handle adding links most successfully.

The NodeReference field creates a field that acts as a pointer to another node. It is the flexibility of CCK that makes this so powerful. In our book reviews, for example, we have a NodeReference field to points to the original item node that the review was written from. We can then index the book review along with the item node, so terms and tags used in the Bookreview node will also be found by the search tool in Drupal.

Drupal gives you an attachment field. The thing is, your users could potentially put anything there. So you might be doing a poetry unit and you want the students to create a podcast about their poem as well as create a document expounding on the poem. Of course, you're going to want to create an RSS feed of the podcasts, but you need to differentiate between the podcast and the document. If the students just upload them using the generic attachment option, you're going to have to write your own piece of code that figures out the document type, and it will not be pretty. The easy way to do this was to just have two upload fields, one asking for the podcast and one for the document. Then everything looks pretty, you can go into Views and tell your view which field is the podcast, and your RSS feed works without a hitch.

Other CCK fields can do some very specialized things. You will need to read the documentation and be sure that you need the functionality before you install some of them. For example, there is a Fullname module that lets you enter a first and last name as separate fields and maintains that relationship.This will then allow you to manage how names are displayed and provide last-name sorting in views. At the same time, however, the module is not fully developed; there are annoyances, like a label for a middle name even when you have configured it to ignore the middle name. So if you do not need all the specialized functionality of some CCK fields, you may be happier just using the basic fields supplied as part of the base CCK package.

A final module type that must be considered are those that provide WYSIWYG editing. There are ongoing discussions within the Drupal community about the inclusion of WYSIWYG modules; some see them as a potential security risk, while others tout the usability factors.¹ There will be more conversation and development, but for now our recommendation is to use one of the WYSIWYG editing options. By setting up a very lightweight set of buttons in the editor we use, TinyMCE, we have been able to maintain the security of the site while also providing users with a more familiar text-editing environment (see figure 25)

One of the biggest challenges in developing a new Web site is getting user buy-in. This task becomes even more daunting when you are looking at a content management system that includes distributed work, constant updates, and an otherwise increased level of user input and interaction. Being able to reassure users new to Web site participation that they will not have to use any of that “code stuff” is a huge benefit. We provide a WYSIWYG editor with buttons for bold, italics, underlining, linking, and bulleted/numbered lists. An additional “Paste from Microsoft Word” button attempts, with reasonable levels of success, to replicate the formatting that was established in the word processor. Though addition of fonts, colors, and emoticons can cause problems, we have not seem many difficulties with this basic setup. Any issues that are encountered will need to be addressed; in our opinion this is a non-negotiable item for getting user involvement in a Drupal Web site.

Having said that, please note that this only really applies to a small group of content contributors. TinyMCE, like most of the other WSIWYG editor modules, lets you define profiles that determine who can use the enhanced editor and what buttons they will see. For anonymous users adding comments, or even patrons filling out a purchase request, this is just not necessary. For staff who are being asked to write longer posts where they might need to underline titles or include bullets, a WYSIWYG editor is essential.