CCK

Application: 
OSU Drupal 6

 

Drupal's Content Construction Kit (CCK) is a very feature rich, complex module that allows a site's administrator or advanced author the ability to create new content types that contain custom fields.

This is useful for creating nodes that all fit together in a collection.  A good example is an Employee content type which allows site contributors the ability to quickly create pages for faculty/staff members.  Custom fields can be specified such as: date started, position, phone, and e-mail contact information, etc. This saves contributors time by making it so the display of this information is automatically taken care of, requiring them only to enter the necessary information into a provided field.

CCK also allows a permitted user the ability to add custom fields to existing, core content types.  For example, if you wanted to add an image upload field to a Page content type, CCK would be the tool to use.

All CCK field types will include at least one form element, or Widget, which is an item such as a file uploader, drop down box, radio button set, or checkbox, amongst other things.  Some field types provide several different widgets.  After a widget is selected, it can then be configured so it works in a desired way.

Additionally, multiple fields can be placed into groups, which can then be displayed as a collapsible fieldset in the submission form.  These fieldsets are similar to the default collapsible fieldsets that already exist, such as the Menu settings or Input format fieldsets.

File Uploader Widget

cck uploader widget

Select Box Widget

cck select box widget

Fieldset Group

cck fieldset group

CCK also provides the ability to display some elements in different ways. For example, a custom field label, such as Phone Number, can be made to display inline with its field, above its field, or to hide. Fields can be hidden from view as well.

Custom content types can be both imported and exported very easily.  This is a great time saver for site administrators who may work on more than one site but would like to have some similar features between sites.

Building a Custom Node Type

Application: 
OSU Drupal 6

 

Custom node types are...well...custom.

There are a few different reasons a site architect might want to create a custom node type. Generally speaking, though, the most common reason is to keep similar data items lumped together and to ensure that data collection is consistent throughout that particular data object.

Other common reasons to create a custom node type include providing the ability to categorically separate the content using the Views module and to provide granular access control to selected data objects.

A custom node can be as simple or as complex as you, the architect, need to make them.  Sometimes, they can get very complex.

sample complex node submission form next to complex node view

In the following section, we'll focus on building a custom node type from scratch.  In particular, we'll pay special attention to some added tools you can leverage to help keep your data in good shape as well as a large variety of different field types you have at your disposal.

Planning Your Custom Node Type

Application: 
OSU Drupal 6

 

A plan is an incredibly valuable tool where custom content types are concerned - especially complex ones.

Following are the main things you need to consider when creating a plan for a custom content type:

What Custom Fields Are Needed?

The first thing you need to do is make a list.  What fields do you need on your node submisison form?

Which Data Elements, If Any, Should Be Required?

A data element is a single, unique piece of data that exists on your custom node type.  It can be something like a First Name field or a Birthdate field.

Some pieces of data are things that every data object will possess.  As an example, if you were creating a custom node type that collected information about a person, each person in that data set will have a First Name.  Therefore a First Name field should be required.

Other pieces of data are things that not every data object will possess.  Returning to our person example, some people may have a college degree whereas others may not.  Requiring a College Degree field on a node submission form that will be used by a wide variety of people with different educational backgrounds is not a good idea because some people may not possess the data that should be entered in that field.  If a required field is left empty, the form can not be submitted.

So, determine ahead of time what fields should be required and really consider how this applies to the entire group of data objects you will be handling.

What Field Types Should Be Used?

CCK is a widely extended module.  What this means is that lots of different people and organizations have created many different sub-modules that work with CCK.  These sub-modules do different things such as formatting addresses, uploading files, manipulating images, etc.

Central Web Services has added many different sub-modules that can be used to help increase the usability your node types.  Determine which ones you will want or need to get your job done.

Should Certain Fields Be Grouped Together?

Sometimes different data elements fit together in groups.  A good example is an address.  Somebody's address consists of a street name and number, a city, a state, and a zip code.  For effective data handling reasons, each one of these items should really be a separate element, existing in what is called a "normalized" state...but they still all fit together.  To group this data set together, we would use something called a fieldgroup.

In What Order Should Data Elements Appear On The Submission Form?

The order that your data fields are presented to your content contributors (aka your data entry operators) is really important.  Nothing frustrates a data entry operator more than having to tab around on a page to enter data that should really be presented in a particular sequence.  Additionally, having these items out of order opens the door to potential errors and other inefficiences that you really just don't want.  Determine the workflow of the page beforehand.

Defining Your Custom Node Type

Application: 
OSU Drupal 6

 

All custom node types need to be defined.  What this means is that you must name the node type and provide Drupal some basic information about it.  This information is then included as administrative data on the Content Type manager.

So, let's create a Supplier custom content type.  This particular content type will be used to track and display supplier information.

To define our Supplier content type, do the following:

Go to Admin menu > Content management > Content types > Add content type.

You'll be presented with four different fieldsets on this screen.  The important thing to remember, when working with configurations, is that often times there is no "wrong" configuration.  The configuration of custom features, such as a custom content type, is up to the architect.  In this case, feel free to follow along, step-by-step, but understand that many of these settings can be changed as needed.

  • The Automatic title generation fieldset:
    • This is an advanced configuration that is discussed in depth in the Automatic Nodetitles article within this book.  We won't cover it in this example.
  • The Identification fieldset:
    • This information shows on the Content type manager administrative interface.  It's the list that is presented when you go to Admin menu > Content management > Content types.  This is also where you define the table name of the content type in the database.
      • In the Name field, enter Supplier
        • This should be "human-readable", which means you would enter the text in the format that a human being can easily read.
      • In the Type field, enter supplier
        • This should be "machine-readable", which means you need to enter the text in a very specific format. Use all lowercase, alpha-numeric characters.  Replace any spaces with underscores.
      • In the Description field, enter some information describing the node type.  For example, what purpose does it serve on the site?  You can use HTML in this text area.
  • The Submission form settings fieldset:
    • This is some default display information that will appear on the node submission form - the blank form that you see when you create a new piece of content.
      • In the Title field label field, enter Company Name.  This is the name of the field you wish to display to your user.  This is the standard Title field that shows in all node submission forms...the name that you put in this field only displays as a label.
      • In the Body field label field, enter Description.  This will change the label of the large Body text area that appears as a default for your use.  Similar to the Title field label, this changes only the label that is presented to your users.
        • Under different circumstances, you may not wish to use the Body field that is supplied as a default.  If this is the case, remove the title from the field and Drupal will then ignore the field.
      • Leave the Minimum number of words selection at 0.  This is used to force a user to type a meaningful amount of text in the field, versus something like a spam submission from a user.  This doesn't apply in our situation as our user list at OSU is very controlled.
      • In the Explanation or submission guidelines field, type Enter some description information about this supplier.  This field is used to help instruct your content author regarding the use of the content type.
  • The Workflow settings fieldset:
    • This fieldset contains configuration information related to how your content "behaves" when it's submitted.  For example, do you want it to publish automatically or save as a draft, when the content is submitted?
      • In the Default options, select Published.
        • The Promoted to front page option is generally used for a blog-style front page, which the OSU Drupal 6 installation does not, by default, use.  Most often, it's best to keep this option disabled.
        • The Sticky at top of Lists option is generally used for forum content, which is not included in the OSU Drupal 6 installation.  This option should typically be disabled.
        • The Create new revision option is a great option for content that requires automatic revision tracking, but we don't need it at this point so leave it disabled.
      • In the Multilingual support options, select Disabled.
        • Drupal is capable of providing a site that displays multiple languages.  This requires a great deal of set-up and authors who can create content in different languages, though, so we'll leave this disabled.
      • In the Attachments options, select Disabled.
        • This feature provides a file uploader that's used to upload and attach content to your node.  We won't be using it in this example so leave it disabled.  The Upload Path Settings fieldset is used by this feature to automaticlaly place files in pre-determined locations.  Since we have the uploader disabled, we do not need to set any upload path settings.

After all configurations are completed, click the Save content type button at the bottom of the screen.

definition screen for supplier content type

After saving your configurations, you will be redirected back to the Content type manager.

content type manager with supplier row added and confirmation message that supplier type has been added

Progress to Date: Custom Content Type Definition

Application: 
OSU Drupal 6

 

After your custom content type is defined, if you were to immediately create content in it, it would look something like this:

Node Submission Form

content submission form with no extra fields added

Add Title

title added

Add Description

description added

Node Saved

supplier node saved

It doesn't look like much yet, but stick around and we'll add some more fields in to make this a bit more interesting.

Automatic Nodetitles

Application: 
OSU Drupal 6

When working with data, which is, in large part, what Drupal does, it's usually best to have your data normalized, when possible.

What this means is that long strings of data that can be logically broken down, should be.

For example, instead of having a field that has the entire name "John Doe" in it, a developer would typically add a "First Name" field and a "Last Name" field.  This makes querying for particular pieces of data much easier.

On some content types, though, this might be redundant.  A good example is an Employee based content type.  The Title, which is a required field, would be the person's name, and then you may have a "First Name" field and a "Last Name" field to do some querying with in Views.

Wouldn't it be easier if the title just built itself?

Well, it can, through the use of the Automatic Nodetitles module, a contributed module that allows permitted users the ability to construct titles based off of data that is stored within existing fields on a content type.

With Automatic Nodetitles, the site builder can choose to either hide the title field entirely on the node submission form, or leave the title field visible on the submission form whereby it will auto-fill only if the title field is left blank.

Custom Content Type with Renamed Title Field
(Name to be displayed)

original custom content type with title field renamed

Read on to learn more about how to configure these settings.

 

 

 

Custom Content Type with Title Field Hidden Via Automatic Nodetitle Configuration
custom cotnent type with title field hidden

 

 

Configure Automatic Title and Hide Title Field

Application: 
OSU Drupal 6

The first available option in an automatic title configuration is to create the title and keep the title field hidden from your user so they don't even have to see it.  This option can be configured by doing the following - please note that a custom content type is used in this example:

Go to Admin menu > Content management > Content types > Edit content type of your choice.

Once on the Edit screen for your custom content type, click on the Automatic title generation fieldset to open it.

Check the Automatically generate the title and hide the field option.

automatic title generation fieldset on cck edit panel with "automatically generate the title and hide the title field" option checked

The next thing to do is to add some token values, which are kind of like data placeholders.  A token value tells the system to find the specified data in the form you're on and to put that data where the token indicates.  Tokens are found in the Replacement patterns fieldset.  Click on this fieldset and do not be alarmed when when it opens, there is a lot of stuff in there that can be confusing to someone who is new to token use.

Scroll down the list until you find the name(s) of the field(s) you want to use.

very large list of token values in replacement patterns fieldset

Once you have located the fields, copy the token value, including the brackets, and paste it into the Pattern for this title field.  If you use multiple fields, put a space between each token.

first name and last name tokens added to "pattern for this title" field

Once you are finished adding the token values you want, click the Save content type button at the bottom of the page.

Now, when you go to create this particular type of content, you will see no title field whatsoever.  In this particular example, the title will be created by the combination of the First Name and Last Name fields.

custom content type with no title field

This option has both benefits and drawbacks.  It does completely hide the field and keeps the user from accidentally entering anything in it, but if there happens to be a typo made in one of the fields used to construct the title, the only way to correct the issue is to unhide the field, which requires the intervention of a user who is permitted to configure this setting, which, in the OSU Drupal 6 installation default, would be an advanced author or administrator.

Configure Automatic Title and Display Title Field

Application: 
OSU Drupal 6

The third available option in an automatic title configuration is to create the title and keep the title field visible to your user so they can adjust it if necessary.  This option can be configured by doing the following - please note that a custom content type is used in this example:

Go to Admin menu > Content management > Content types > Edit content type of your choice.

Once on the Edit screen for your custom content type, click on the Automatic title generation fieldset to open it.

Check the Automatically generate the title if the title field is left empty option.

automatic title generation fieldset on cck edit panel with "automatically generate the title if the title field is left empty" option checked

The next thing to do is to add some token values, which are kind of like data placeholders.  A token value tells the system to find the specified data in the form you're on and to put that data where the token indicates.  Tokens are found in the Replacement patterns fieldset.  Click on this fieldset and do not be alarmed when when it opens, there is a lot of stuff in there that can be confusing to someone who is new to token use.

Scroll down the list until you find the name(s) of the field(s) you want to use.

very large list of token values in replacement patterns fieldset

Once you have located the fields, copy the token value, including the brackets, and paste it into the Pattern for this title field.  If you use multiple fields, put a space between each token.

first name and last name tokens added to "pattern for this title" field

Once you are finished adding the token values you want, click the Save content type button at the bottom of the page.  Please note that, when creating this content type, your users will have to be coached to not enter anything in this field.

Adding Fields to a Custom Node Type

Application: 
OSU Drupal 6

 

Once your custom content type is defined, custom fields can then be added.

As is often the case with Drupal, there is no "right or wrong" here.  How a custom content type is built is completely determined by the person building it.

The first thing we need to do to add fields to our Supplier content type is get into its field manager.  To do this, from the Content type manager, in the Supplier row, click on the manage fields link.

click manage fields link in supplier row

You will then be taken into the Supplier content type's field manager...

supplier content type field manager

Add a Text Field

Application: 
OSU Drupal 6

 

The Text Field data type is, perhaps, the most common data field type used in custom content development.

In this example, we'll add a Contact Name field to capture the name of our supplier contact.  To add this field, do the following:

adding the contact name field

After saving, you'll be redirected into the configuration panel for the Contact Name text field.

contact name text field configuration panel

 

E-mail Field CCK Widget

Application: 
OSU Drupal 6

 

The Email Field CCK Widget provides a flexible custom field option for an e-mail address.  This widget can be used in a custom node type to automatically display e-mail addresses as either a mailto link (default) or as a link to a web-based mailer within your Drupal site.

This feature is an excellent one to use as it helps limit an unscrupulous organization or individual's ability to harvest e-mail addresses on the web through the use of spam bots.

Please Note...

This module will not "automatically update" or replace existing fields that are being used to hold e-mail data.  It is strongly suggested that this tool be used as a replacement for existing fields that contain e-mail data.  The replacement process is manual.  For instructions on how to do this, please see our FAQ "Can I Easily Replace My Old E-mail Text Fields with the E-mail Field CCK Widget?"

Adding the Email Field

To add an Email field to your content type, do the following:

From within the Field Manager:

Enter a label name in the New field text box, enter a field name in the Field Name box (remember, all small letters, alpha-numeric, and underscores only), and select Email from the Field type drop down menu.

Click the Save button when finished.

new field being added in supplier cck field manager

Configure the Email Field Widget

Once inside the Email Field configuration panel, make any desired adjustments, and then click the Save field settings button.

email field configuration panel

Reorder New Email Field

Once returned to the Field Manager, reorder your field, if desired, by dragging the field into position with your mouse.

Click the Save button when completed

dragging new field into place with the mouse

Configure Email Field Display

After the Email field is created and configured, the display can be configured as well.  In this case, the Display configuration determines how the field will function.

There are two different ways the Email field can work:

  • Mailto link
    • Opens up a portal that can connect to an email client.  Keep in mind, that not all users will have an email client configured on their computers.
  • Contact Form
    • Redirects user to a form within the site from which an email can be created and sent.

The Contact Form method is preferred as it removes several additional steps for your users.  It is also an option that can be used, even if a person doesn't have a mail client that is included in the mailto options.

To select the Contact Form method, in both the Full Node and Teaser View columns, select Email Contact Form from the drop down.

Click the Save button.

selecting contact form method from display fields configuration

So now that the Email field is configured, let's take a look at how it works...