Drupal 7 CMS to Add Content Type Extensibility for Dummies

By Dee-Ann LeBlanc (@deele) Jun 25, 2009

2 comments

Over the years, the Drupal (news, site) web content management system has had the same problem as any other growing software project: deciding which features are important enough to belong in the core of the software.

One such candidate feature — which the Drupal team has discussed since 2004 — is that of enabling CMS administrators to define custom content types, or fields for the system.

The Content Construction Kit (CCK), an add-on module for Drupal, has handily taken care of this need for years. In Drupal 7, it will no longer be needed. But even more, we'll be getting some tasty semantic web features as part of the changes.

The Drupal 7 Solution

CCK itself isn't really being moved into core. Instead, a major rethink of Drupal internals is leading to a new way of dealing with pieces of information in the system. In this rethink, extensible content fields will become native to the core of Drupal.

This extensibility is coming in the form of something called Fields. The foundation is the internal re-architecting wrapped up in an API. On top of the API will come a user interface that will be a core part of the Drupal Administration web application.

Fields, as they are called, can be of any datatype and can be glued to any entity in the system (with proper entity definitions). By default, both the node and the user entities will support extensible fields.

For those new to the node concept, in Drupal, each item of content in the system is called a "node", and each node belongs to a single content type. Examples of nodes include pages, blog posts and news items.

Drupal 7 Fields - Create Screen (Draft Mock-up)

So with Drupal 7, the idea is that via the out of the box GUI, Fields can be added, edited and managed.

In true to Drupal fashion the design of this functionality has been abstracted out and generalized as much as possible. So once a field is defined, it exists as its own entity and can be attached (on an instance basis) to any number of other system entities — assuming they are Fields-enabled.

These are the basics, but there's more.

Where We Came From

In Drupal 6 and previous versions, content all centered around the idea of nodes, whether these nodes were Stories, Pages or bound to some other name.

Drupal 7 will focus more on Fields as first class citizens. For an example, Dries Buytaert offered a collection of events in Drupal 6 as you might see them in a relational database.

Drupal 6 events shown as you might traditionally expect to see them, in a relational database model.

But in what Buytaert envisions for Drupal 7, fields will be tied together with "semantic sugar." This sugar is essentially a description, explaining how the data in two fields is related. So, for example, if you're in a band that's performing at an event, rather than taking the relational database approach above, you might try something such as you see below.

Field contents linked together by how they're related, as Buytaert envisioned initially for Drupal 7.

Where It's Going

This subject, predicate, and object format just discussed matches up nicely with RDF (see our write-up on RDFa in Drupal, it's an interesting and highly related project). So, essentially, making fields a core part of Drupal makes Drupal even more ready for the semantic web.

Just to make sure this discussion stays on the ground, and doesn't float off as pie in the sky, Buytaert says that the Drupal Field API has already been committed to the Drupal 7 development branch. Thanks to the refactoring, he says, "it will be possible to attach fields to nodes, users and taxonomy terms, and by extension, to any other entity type that wants them." In fact, by implementing a set of hooks, any entity can become "fieldable".