The ability to create custom content types is core to Drupal’s flexible architecture. One of the most powerful ways to customize content types is by adding additional data, such as dates and locations to event types or pricing and images to product types. The ability to extend content objects is a must-have in top tier content management systems. Drupal, like many other top CMS systems, has a long history of being able to extend content with modular programming. But where Drupal really stands apart is in its' ability to extend content types without having to write code. Drupal gives non-programmers the ability to do this via its admin.
If you’re new to building websites using a CMS, it might be a little hard to fully appreciate the elegance that the field system gives us. To understand the problem that field solves, let’s look at an example from our demo site.
Using the Inline Approach
In a previous video, we created new content type for products. It has containers for a product name and description, but what if we wanted to add additional data about our products such as pricing and model IDs? Well the first thing we’ll try to do is just add this information into our body content. We do that by going to ‘Edit’, and we paste the information we want at the top of our page. Then I’m going to scroll down and I’m going to change the text format to full HTML so an image will show up, but I’ll just click ‘Save’. This certainly does work to display the additional data to the site visitor, but it is limiting, as far as enabling consistency and advanced features around this data. To illustrate one aspect of what I’m referring to, let’s create another product. I’m going to do this in another tab. So go to add content, and then over in this tab, I’m going to add a yellow widget. Paste in some content. Switch over to full HTML to show my image, and click ‘Save’.
Now let’s switch back and forth between these two, and we can see that there’s some real inconsistencies. Our images are different sizes, and our text is formatted somewhat differently. Some data is even missing! This is one of the main problems of the inline approach. It’s that we’re relying on our node authors to maintain consistency for us.
Using the Field System
But if we use the field system, we can maintain consistency in a more structured way across all nodes of our content type. Now let’s take a look at the fields approach. I’ve already gone ahead and pre-configured a new version of our demo to use fields for our additional data. In the next several videos, I’ll walk you through how to actually do this for yourself, but for now, I just want to show you the end result.
One of the main differences, we’ll notice, is on our node ‘Edit’ form. Now we have discreet fields for entering these different pieces of information. So here’s an image field, here’s a numeric pricing field, and here’s a model field. The other thing that we can do, is we can set some of these to be required, that way node author’s can’t leave this information out before submitting their nodes. And as you might suspect, we look at our two different nodes; they look pretty much the same. We can also change formatting across all nodes, doing it in one single place.
An example of that might be going to structure, content types, manage displays, and maybe we want to remove our labels. We click ‘Save’, and now our labels are gone. I go back over to my yellow widget, hit refresh, and they’re gone there also. We couldn’t do that with the inline process, otherwise we’d have to go to each node and individually edit the content.
Additional Features of Fields
But... fields is not just about controlling formatting. Fields enables us to treat data as discreet information which we can build advanced features around. So for example, we might want to have a products listing that we can then sort by price. If we didn’t have the pricing information as a discreet piece of data, then we wouldn’t be able to do this kind of sort. There are more advanced examples also, such as, for example, we might want to use the price to calculate a total for an online purchase, or maybe we want to use the model ID to do inventory look-ups. If this data was just embedded into the body content, there’d be no reliable way to give it special treatment. So let’s take a deeper look at what fields is doing behind the scenes.
The first thing that fields does, is gives us a way of storing our data. Much of this is done in your site’s database, but it can also store into files or other resources. So what’s really kind of neat, is that when you create a new field, the fields system automatically alters your database to support intelligent storage of the data. No DBA required. The next function fields manages, is input widgets that allows users to enter their data. Input widgets are often familiar web forms — such as text fields, check boxes, select boxes — or even more advanced things, such as file upload fields.
The last thing that fields does is to help you control and format the output. Sometimes output is fairly straightforward, but for some types of fields (such as dates or images), they can help you do some pretty sophisticated formatting.
The fields system is one of the killer apps that makes Drupal so powerful and flexible. It’s really a pretty clever solution to an important challenge in database driven web-development. We all greatly appreciate the efforts of the creators of the CCK module, which is a predecessor of fields in earlier version of Drupal, and to the core contributors that work so hard to bring it into Drupal core for Drupal 7. In the next several tutorials, we’ll work through several examples of how to use the power of fields to extend our content.