The Engagement 4Cast
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:
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.
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.
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.
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.
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.
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.
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.
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?
4Site Interactive Studios is a talented troupe of web professionals who are passionate about creating tools to support digital marketers. We love to hear from our community! Reach out to us with your thoughts and questions. And don’t forget to subscribe below to get notified when we post new blogs – no spam, just content👍🏼
Subscribe & stay ahead of the crowd with sage marketing tips and predictions.