Tanner J. Ferguson

Distinctions between Entity Types in Drupal

October 23, 2014

In the days of Drupal 5/6 and CCK, different kinds of content were handled in different ways, and had various advantages and disadvantages. While the ubiquitous Node, when coupled with CCK, is very much the same in Drupal 7 as it was in those days, other kinds of content, like User accounts & Taxonomy didn't share the same power of custom fields that Nodes with CCK did. User accounts had their own stripped down version of fields that had little in common with Fields as we commonly know them, and Taxonomy was very much suited to its heirarchical categorization ability and not much more. This resulted in various workarounds, as well as the mentality of "everything is a content type".

All of that (well, almost all) changed with Drupal 7 and the introduction of Fieldable Entities. Now Nodes, User Accounts, and Taxonomy Terms can all use fields powered by the same Field API. So now out of the box we have at least 3 different kinds of entities to use for structuring our data. Factor in various Contrib solutions like Organic Groups and Entity Construction Kit, and it doesn't take much thinking (or overthinking) to find yourself wondering what Entity type is best suited for the job.

With great power comes great responsibility

With all of the flexibility we now have, its arguably feasible to use just about any Entity type to get the job done. It's important to remember there are still key differences in Entity types - after all, if there weren't any differences, there wouldn't be a need for the overarching Entity API. Below are some general guidelines I try to follow - feel free to share yours as well.

  • Nodes - Any content that will be seen as a full page display of its own should be a node.
  • Taxonomy - If you need simple categorization options, consider a Select list field. If your categories need extra data like descriptions, images, etc, go with Taxonomy. If you need heirarchy, where options can have sub-options that have sub-options, Taxonomy is undoubtedly the way to go.
  • User (for Bios, Profiles, etc) - This one can be a bit tricky, and the key thing to remember is Access Control - to have an entity of this kind exist, you are in some way allowing for potential access to your system. This is fine for the scenario of a blog author writing a blog post, and allows for easy and automatic attribution with full Bio info. But what if you have a guest author, or frequently have content that needs to be attributed to authors that will never need a user account? It's often best in those scenarios to go with a Node instead. Managing access control for users is certainly feasible, but why potentially open a door if you don't need to?
  • ECK / Field Collection - These Contrib solutions are great for what you might call sub-content. If a piece of content is never intended to be seen as a full page display on its own, I think this route is best. It provides a clear distinction for content editors, and allows you to keep your normal "Create Content" menu trimmed down to the types of content your editors will be posting the most, and offers you more granularity in deciding where this content is entered by the editor, such as within another node's entry form.
  • Organic Groups - OG has been around a long time, and provides a great way to group content together, with its primary use case being to provide a way for multiple users to edit the same pieces of content. In Drupal 7, much of OG is powered by Entity Reference, while adding on an additional layer of granular access control. If you do not need that extra access control, I would look heavily at whether you can accomplish the content grouping you need with Entity Reference, Entities, and Views alone. OG can be configured to eliminate any access control requirements, but if you can do without, it can mean less configuration, complexity, and maintenance overall.
comments powered by Disqus