Content modelling in Drupal: The accidental content strategist

In my previous article on content modelling, I tried to be platform-agnostic; most of what I said there can be applied to a website built in any content management system.

But when you get down to the nitty-gritty of content modelling, the platform you choose can make a big difference.

The platform I know best is Drupal. Drupal is a very powerful CMS that lends itself particularly well to structured content. But if you're a content strategist or information architect and you've never worked with Drupal before, there are a few basic things you should know before you get started. This article talks about a few of them.

In a later article, I'll talk about some of the issues that can crop up when the rubber hits the road, and you try to implement your content model in Drupal. But in the meantime, here are some things you need to know about Drupal itself.

Drupal is agnostic about structure: you decide almost everything for yourself.

This is one of the biggest culture shocks people experience when moving to Drupal from a platform like WordPress. When you install a Drupal website (at least if you're using the default version of Drupal rather than a distribution), you're presented with something that closely resembles a blank slate:

default drupal installation

Unlike installing WordPress, where you more or less end up with a website that you can start adding content to straight away — as long as you're happy with the built-in structure of pages and posts, categories and tags — in Drupal you build or configure almost everything yourself, often from scratch. This includes content types, menus, blocks, page layouts, and content lists or indexes (like the "recent blog posts" list on a home page, for example).

This blank slate approach gives Drupal a lot of flexibility: if you want to build a specialised index page that shows only certain fields from blog posts written by certain authors in certain categories, with custom sorting rules and a random post thrown in at the beginning just for kicks, that's easy to do in Drupal — almost as easy as building a bog-standard blog index page, since both are things you need to build from scratch.

When I say you're "building" this page, I'm not taking about code: all this configuration can be done from within the admin interface of Drupal. (In the above case, you'd have to install the Views module and its dependencies alongside Drupal core, but that's also something you can do from the admin interface.) One of the truly cool things about Drupal is the amount of power it puts in the hands of people who can't write a line of code.

But the flexibility and power of Drupal that make it a great tool for sites with complex content needs and a lot of customisation, also make it a less than ideal tool for someone who just wants to get a decent-looking website up and running as quickly as possible. Building your uncle a 5-page brochureware site for his fishing tackle business? Drupal is probably not the right tool for the job.

Drupal site builders are content modellers by default.

As I've already said, one of the things you need to create when you build a new Drupal site is a set of content types. Drupal gives site builders a great set of tools for creating content types and adding fields to them, and almost everyone who builds a Drupal site will end up creating some custom content types.

In other words, the process of content modelling that I talked about it in my previous article is baked into the activity of building a Drupal site. Drupal people are familiar with the basic concepts of content modelling in a way that people who use other platforms may not be. Every Drupal site builder is an accidental content strategist, even if they don't know it.

Of course, that doesn't mean Drupal people are always good at content modelling! But it does give them a great head start.

You’ll almost certainly need contributed modules to get your content model working.

The Views module that I referred to above, used to construct things like lists of blog posts, is not actually part of the core Drupal software. It's a module that's been developed by members of the Drupal community, and made available to anyone building a Drupal site. Views just happens to be the most popular of all contributed Drupal modules — so much so that it's set to become part of core in Drupal 8.

It's not just Views, though: you'll find yourself having to install contributed modules to do many things in Drupal that might seem quite basic, like setting up an automatic URL structure for newly created content (you'll be using Pathauto for that), or adding a field to one of your content types that references a date (that's Date module), an address (Address Field), or another piece of content (Entity Reference).

In Drupal, most content lives in entities.

This is where it gets a bit complicated. Rather than trying to explain myself what entities are, I'm going to refer you to the page about entities on Drupal.org. But the entity system (part of Drupal from version 7 onwards) is one of the things that makes Drupal so powerful and flexible, so if you're going to be working on a Drupal site, you owe it to yourself to get familiar with it.

The two major things you need to know about entities are:

  • Entities include not just nodes (Drupalese for items of content), but taxonomy terms, users, comments and much more.
  • If it’s an entity, you can add fields to it. In fact, exactly the same types of field are available to every entity type. The first time you want to store phone numbers for your users, or add images to taxonomy terms, you'll understand the power this gives you.

You can build a Drupal site yourself — even if it’s just to prototype and test your content model.

Until a few months ago, although I'd been working with Drupal sites for years, I hadn't ever actually built a Drupal site. That all changed when I heard a remark made by jam during a conference talk, to the effect that the unique thing about Drupal is the power it puts in the hands of non-developers. Hell yeah, I thought. As a non-developer, I should be taking advantage of this power to try out my content modelling ideas in Drupal, rather than relying on my developer colleagues (obliging as they are) to build things like content types and views for me.

So I watched the basic site building series of videos at Drupalize.me and I haven't looked back since. Drupal is a simply fantastic tool for prototyping a content model, trying things out, seeing what works, and refining your ideas. In some cases, I've even been able to hand my prototype over to our developer and save a lot of their time, as they don't have to replicate the work I've already done, but can concentrate instead on theming and more advanced configuration.

This article is the first of two based on a talk Angus gave at DrupalSouth Melbourne. Look for Part 2, about common issues when implementing a content model in Drupal, very soon!


« back to blog index