I recently had a conversation with a client who was confused by Drupal terminology and didn’t know the difference between content types, taxonomies, and custom entities. This is a fairly common question we get asked by clients that are new to the content management system.

Drupal allows you to create, organize, and present data using a few different mechanisms - content types, taxonomy terms, and entities. There is a lot overlap between these - each is fieldable, each can have associated metadata and URLs, and can be presented in pretty custom ways to end users. So, you see where a new user’s confusion stems from.

Here is how we define these mechanisms to our clients and our own beliefs around when you should use each.

Content Types:

A content type, simply put, is a way to represent different types of content that will be published using your CMS. Content types typically have an author(s), publishing date, may be linked to within a menu, and have some associated workflow. Content types can represent anything from a static page, to a blog post, to an event - each having different fields associated with them.

We typically derive what content types to use on a client site by working with them through some  engagement mapping exercises. The first questions to answer are:

1. What are your users’ goals?

2. How can you meet those goals?

3. What interaction/transaction needs to take place in order for a user’s goal to be met?

Once you have the interactions and transactions defined, it is fairly easy to then define content types. As an example, if you users need to register for trainings, and you can meet that need by providing an online registration system, the content type you need for that transaction is a “Training”.

Here are some questions that can help you determine whether the data you have available should be represented in Drupal using a content type:

1. Do multiple people need to be involved in creating, reviewing, or managing this content?

2. Does your content need to have any workflow around the creation, editing or management of it?

3. Will you need to control who has access to your content in its entirety or certain elements of it?

4. Will your content need to have an associated metadata (for SEO or content portability)?

Taxonomies

Taxonomies are data objects within Drupal used to categorize content using a shared vocabulary. The most common example of this is tagging a blog post. Most blogging software allows you to associate some terms with the post in order to allow people who are consuming your content to find posts that is similar in subject matter. Drupal taxonomies are often associated with a content type through various field types, so that you can control how people are allowed to associate a term(s) with a piece of content (i.e. restricting a content creator to only associating only one term from a vocabulary with a piece of content).

Like content types, you can add any number of custom fields to a taxonomy vocabulary. If you want to associate an icon with terms in a vocabulary to make the display of terms more visual, then you can easily add an image field. We typically we recommend only adding fields to vocabularies if we need to store related metadata. If you need to do things like display icons related to a taxonomy term, do it at the theme layer.

Another common use case for taxonomies is creating a hierarchy of content. Since taxonomy has built-in support for parent-child relationships, you can easily extend that to content types by adding a vocabulary with some hierarchy to it.

Custom Entities

Entities are somewhat of an abstract concept for people new to Drupal.  An entity is a form of data that you want to represent in the system. Some of the data objects within Drupal core - content types, users, and taxonomies - are entities. These entities can meet the majority of the data needs of most clients, but there are some cases where you need a custom entity to represent data you want to display to end users.

You probably need to create a custom entity if:

1. You data is representative of something that is not content

2. You don’t need any workflow or any of Drupal’s core editorial tools to manage data

3. You don’t want your data to appear within search results

4. Your data will not be listed in a Drupal menu

5. People will be able to interact with this data in a very customized interface, such as a game

Here are some use cases for creating a custom entity:

• You need to create and manage ads that are displayed on your website

• You need to manage product inventory in an online store

• Your Drupal website is powering a project management system

• You need to manage contact information for people who are not users of your website

Custom entities require programming knowledge, so this is something you will need to work with a developer to do. While this may sound complicated, it may just save you from the pains of trying to wedge your data needs into a content type, which may not be the most appropriate solution for your needs.

In our next blog post, we will list some the common pitfalls to avoid when modelling your content within Drupal. Stay tuned!