How to Use the CCK Framework in Drupal

posted Jun 22, 2011, 1:29 AM by admin@

CCK is an extremely flexible framework for creating forms to enter content. Although the Drupal core provides the ability to create different content types (such as a Job Opening or Application), it does not yet provide a mechanism for adding fields to the newly created types. Until CCK fields become integrated into Drupal core (which is expected in future releases), installing CCK should be the first step in nearly any Drupal website.

Upon installing a new copy of Drupal, there are two content types provided: Story and Page. Both are fundamentally the same thing—a form that contains a Title field and a Body field. Any additional content types that are created will also contain a Title field and (optionally) a Body field; it takes an add-on module like CCK to add additional fields to a content type. Figure 3.2 depicts the Story content type as it appears prior to adding fields with CCK.

Figure 3.2. The Story content form, as presented to an authenticated user on a new Drupal site

Attached Image

After enabling the CCK module, any number of custom fields may be added to any content type. Combined with Drupal core’s ability to create any number of custom content types, CCK lets you create any number of completely customized forms for adding content. Figure 3.3 shows the same form after adding a few custom fields, such as an additional text field, an image field, and a set of radio buttons.

Figure 3.3. The Story content type form, after adding custom fields

Attached Image

After adding the fields, CCK can automatically handle saving information to the database, and after data is submitted, presenting this information in a variety of ways.


Functionally, CCK is set up into two end-user pieces. The first of these are fields, which allow a user to save data into your site. Fields represent the type of data that needs to be saved, such as integer, decimal, or text. When choosing a field to add to a content type, the first decision you need to make is what kind of data is being stored “behind the scenes” in the form. Will the information entered into the form be something basic like text or numbers, or something more special like a relationship to another node or user? The field types included in CCK “core” are displayed in Table 3.1. Other modules, such as Fivestar (, ImageField (, and Date (, add more field types to CCK. These CCK field modules are covered later in the book, in Chapters 4, 7, and 9, respectively. A full list of available CCK field types is available at

Table 3.1. Built-in CCK field types

Field type

Common uses


The most efficient way of storing a number. Use for product numbers, identifiers, or whenever you’ll have an exact number of something, like track numbers on an album or number of attendees at an event.


An efficient way of storing numbers to a certain decimal point. Useful for currency amounts.


The most accurate way of storing numbers that need a high level of precision, such as scientific measurements.


Can store any string of text. Useful for names and descriptions, and also for longer full-text content such as biographies.

Node Reference

Can reference any node on the site in a field. Useful when one piece of content is related to another piece of content.

User Reference

Can reference any user on the site in a field. Useful when associating a user with a certain piece of content, such as a coordinator or contact person for an event.

CCK or Taxonomy?

Both the Taxonomy module and CCK allow you to create select lists on the form for creating content. Here are a few guidelines to help you choose one or the other:

  • The primary purpose of Taxonomy is to create categories, so if you’re putting things into categories, you should generally use the Taxonomy module. If you ever make a CCK field called “Category,” think twice. The Taxonomy module was made for that exact purpose, and many existing modules provide integration directly with the Taxonomy module.

  • Taxonomy provides hierarchies of categorization that are very easy to order and organize. If your categories need to be put into a tree, Taxonomy is a good choice.

  • Taxonomy provides only a “Title” and “Description” for categories. Situations that require more information to be attached to categories would benefit by creating a content type for the category, then creating a CCK node reference field to select nodes in that category.

  • A general rule of thumb is that if you can remove the field and the content type still makes sense, use Taxonomy. An article filed under a “Technology” category is still an article if you remove the category association, so Taxonomy is a good fit. If the field is part of a piece of content, such as an album’s recording artist, then CCK is generally a better choice.


Once the type of data is determined, then it’s time to think about how it should look in the form. In CCK lingo, the form elements are called widgets. Do you want a drop-down select list, or a group of radio buttons? Checkboxes or an autocomplete text field? Choose the widget that makes the most sense for the user entering the data. Note that the widgets available will vary based on the field type chosen.

The widget types included in CCK core are displayed in Table 3.2. As with fields, add-on modules often expose additional widget choices.

Table 3.2. Built-in CCK widget types

Widget type

Common uses

Text field

This widget allows a single line of text to be entered, such as a name or phone number. Either plain text or formatted text entry is supported.

Text area (multiple rows)

Use this widget for entering a larger paragraph of text, such as a biography or a product description. Either plain text or formatted text entry is supported.

Single on/off checkbox

Use when something can only be answered “yes” or “no”; for example, a field that asks whether a user would like to be added to a mailing list.

Checkboxes/Radio buttons

Use when there are multiple options to select from; checkboxes will be used for fields that support selecting multiple values, radios for a single value only. In most cases, a “Gender” field makes sense as a radio button selection, whereas a “Favorite colors” field makes sense as a collection of checkboxes.

Select list

An alternative to checkboxes and radio buttons is a drop-down select list. Useful when there are many different options to choose from and it would be cumbersome to display each inline as a separate choice.

Autocomplete text field

This widget displays a text field that, as it’s typed into, displays results that start with the letters entered. Typing “st” would bring up terms like “Stewart,” “Studebaker,” and “Style.” Useful when there are a huge number of options to choose from and displaying them all in a select list would be too much to sort through. However, it requires users to have an idea of what they’re searching for.


Complementing the configuration of field input, formatters allow you to adjust how the data will be output when it is displayed to the users of your site. For example, decimals could be displayed with or without commas to indicate thousands, such as in Figure 3.4,

Figure 3.4. Configuring the display of a field formatter

Attached Image

Other modules may add additional formatters, giving you a plethora of ways of displaying information. The ImageCache module is an example of such a module; it allows the display of resized images.

Keep in mind that the formatters available depend on the type of the data, making it very important to set up a field as an integer, decimal, or float if you’ll be displaying numbers. CCK won’t let you change the data type after the field has been set up, so if you need to change the type of field from text to integer (or any other conversion), you’ll need to delete the field and add a new one with the desired type.


Learn more about this topic from Using Drupal. 

With the recipes in this book, you can take full advantage of the vast collection of community-contributed modules that make the Drupal web framework useful and unique. You'll get the information you need about how to combine modules in interesting ways (with a minimum of code-wrangling) to develop a variety of community-driven websites -- including a wiki, publishing workflow site, photo gallery, product review site, online store, user group site, and more.