Structured Content

Introduction

Ever since Drupal 5 (2006), Drupal has had "fields in core", meaning site builders can create their own content types and add any number of fields to them using the administration interface - no code required.

While this may sound a bit dull, it opens up a range of features: from quickly creating web application prototypes to building searchable product catalogs, Content Types and Fields let you move from unstructured content to structured content.

Unstructured vs. Structured content

To illustrate the difference between unstructured and structured content, let's look at an example.

A Hotel Scenario

A hotel has 50 rooms. Their Drupal site uses 50 nodes of the type Basic Page to represent these 50 rooms.

They use the title field for the name of the room, and the body field for the room description, price, and a few small photos.

They build a menu for the rooms, to which they add 50 links, one for each of the pages that represent a room.

So far, there's nothing terribly wrong going on here, but this approach does raise a few potential concerns:

Views are difficult

Since Drupal has no concept of what a room is or which nodes might be rooms, creating a view to list only the 50 room nodes will be hard. Not impossible, but hard and messy. Not an ideal situation.

Searching and filtering is difficult

Important data (price, size, facilities, ...) are all part of the body field, so it is not possible to create any kind of searchable, filtered list of rooms. You won't be able to let users find rooms in a certain price range, or having certain other features, because Drupal doesn't know about these features: it only knows about a body field with lots of text content.

Consistent layouts are difficult

Since all content goes in the body field, and the only "layout tool" is the rich text editor, It will take considerable manual effort for the content editor to make sure the 50 room pages look the same, have their image thumbnails the same size, and located in the same place.

Even worse, for every layout change that concerns rooms, all 50 room pages need to be manually updated and tested across browsers and devices.

Consistent design is difficult

Drupal lets you provide a style template for each Content Type: one for Articles, one for Basic Pages, and so on. However, if the hotel site uses Basic Pages for everything, it becomes difficult to style the room pages differently from other pages.

Display modes and partial display of room data is difficult

Drupal has the concept of display modes. The 'Full' and 'Teaser' modes, available on all Content Types by default, are an example of this. Each view mode specifies which of the Content Type's fields will be shown. The Full display mode typically shows all fields, while the Teaser mode only shows a summary of the body field, and a selection of other available fields.

If all of a Content Type's data is stored in the body field, rather than in separate fields, the hotel can't use these display modes to specify different ways of displaying its rooms.

Access control is difficult

Generally, you can configure administrative privileges on a per-Content Type basis. This lets you create specific roles for specific people allowing them to perform specific tasks:

• users with the role 'article editor' can edit Articles
• users with the role 'page editor' can edit Basic Pages
• ...

However, if Basic Pages are used for all types of content, there's no way to create a role that says 'users of the role [x] can edit rooms', because, again, Drupal does not understand the concept of 'room'.