Last week, I wrote a post about the differences between content types, taxonomies, and entities in Drupal, and how you should use each. Now, even with having a strong understanding of how to use these mechanisms, there is still plenty of room to mess up when developing a content model. Here are ten lessons we have learned over the past seven years of building Drupal-powered websites and apps:

1. Using content types to represent content assets

A very common mistake made in Drupal is using a content type to represent things like photos, videos, etc. that are then associated with other pieces of content. This stems from the poor support for media management that has been available within the system. Developers had to give direct access to a file directory on the server for website administrators to upload and manage images and video, which was less than elegant.

The alternative was to create a content type for photos, videos, etc., and use node reference fields to allow users to add those assets to a node. The downside of that is you now have hundreds, if not thousands, of individual nodes that represent what should be represented within a field on a content type.

With the introduction of entities in Drupal, and the release of the Media module, media management in Drupal has gotten better. We default to using the Media module because it removes all the clutter of having nodes that represent assets within the content administration screen, and creates a nice interface where website administrators can view, edit, and delete media files.

2. Using taxonomy to represent content

Taxonomy vocabularies are meant to categorize content, not represent content. This seems likes a no-brainer, but we have come across many websites that use taxonomy as a way to create content types.

A good rule of thumb is if the terms in your vocabulary are not repeatedly used across multiple pieces of content, or if the metadata association with your vocabulary terms is what you hope for your readers to engage with more than the term itself, it should probably be a content type.

3. Using a content type to organize other content types

Unless you are creating a hierarchy to your content (such as including articles within a newsletter issue), content types shouldn’t be used to organize content. Taxonomy vocabularies are fieldable if you need to associate any metadata with vocabulary terms. We, as much as possible, try to leverage taxonomies over content types so we can make the workflow for content editors more streamlined.

4. Creating new fields to represent the same type of data as existing fields

Drupal creates a custom multiple tables in your database for each field that you create on a content type. Your database can quickly bloat, and queries for content can begin to impact performance.

Drupal allows you to reuse fields that you have already created in the system on multiple content types. As an example, if you are adding a thumbnail image to a Blog Post and Event content types, then you can easily reuse the same field for each. This will save you some performance hits and time in building out your content types.

5. Creating too many content types

It is easy to fall into the trap of creating a content type for everything on your website. We have seen websites with upwards of twenty content types, with some representing the same type of content.

Think very broadly when creating content types. You may not need two blog content types, one for your rapid response blog versus one for your policy blog. Even if these two types of posts have slightly different data models, think of you you can leverage conditional fields or taxonomies to categorize this type of content so that it will give the editor the fields they need to produce content and allow you to present that content in unique places across your website.

6. Creating content types content creators/editors don’t have the capacity to produce

It is easy to listen to your clients and create the content types that they ask you to create. Seriously ask yourself “does my client have the capacity/resources to develop the type of content they are asking for?” Most times, the answer is no.

Content management systems are like self-serve ice cream bars. You think you can handle the six large scoops with four different toppings until you take that third bite. The same thing with content types - clients can tend to want all the content types they think they will produce, but the reality is they won’t.

Take care to really understand the ways your clients product content and what they can realistically produce to meet their desired goals. Also, perform research into what content their audience(s) really want and have the tough conversation with your client about eliminating any content types that aren’t necessary to meet their users’ needs.

7. Allowing website administrators to format content within the WYSIWYG editor when they don’t need to

I won’t dive into this too much to avoid the content blobs versus chunks debate in our comment stream. Looking at this from a sheer editorial experience standpoint, it can be easier for content creators to populate fields rather than having to format content within a WYSIWYG field.

8. Using fields to manage presentation of content

Fields on the content types should not be used to manage how content is presented to the end user. I have seen fields used to assign classes to content fields; assign nodes to regions of a page; and even ordering nodes within a listing. There may be some edge cases where doing this makes sense, but it is more appropriate to leverage the tools within Drupal to manage presentation of content, such as Panels, Views, Nodequeue, etc.

These are just some of the most common pitfalls that were top of mind for our team. Are there other pitfalls you have found when modelling content within Drupal?