Drupal Entities - Part 1 - Moving beyond nodes

Drupal 7 introduces a lot of big changes at all levels. Amongst these, the use of entities as the primary abstraction for content represents one of the biggest shifts in the underlying architecture. A telling sign of how deeply embedded entities are is that they don't even get a mention in the changelog for Drupal 7 - they are not a user-facing tool or abstraction in any way - purely an architectural tool to deal with content. I originally intended to write one single post as a means to help me clear my understanding of entities and hopefully help others as well. However, one post is just not enough! So in what has now turned into a series of posts I am first going to do some historical digging to see how entities came about, then explain what entities exactly are and finally try to figure out how and where entities can be used in coding to build better modules. So first let us try and figure out how things got to where they are now.

In the beginning there were nodes

Up to Drupal 6 nodes, as the main unit of content, could be considered Drupal's primary abstraction, with every other piece building or relating to nodes. A lot has already been said about what a powerful tool that is. You add some functionality for nodes and suddenly any content on your site (as long as it is a node) gains that ability. From versioning, voting, translation, presentation fanciness as long as you wrote your extension to work with nodes you were sure it would work in all sorts of situations. With Flexinode and later on the Content Construction Kit, nodes gained the ability to have fields added to them. This pretty much took Drupal to a whole new level of flexibility - so much so the ability to add fields to nodes became one of the main goals of Drupal 7.

Let us make everything a node!

At the same time, the Drupal 6 contributed module space provided proof of how people needed to add fields to more things than just nodes. You have modules that turn user profiles to nodes - for the explicit purpose of then being able to add fields to user profiles via CCK. Modules that turn comments into nodes, again just so you can add fields to them. Even modules that link taxonomy to nodes. In fact, the "everything as a node" meme has a long history. A google search reveals that Robert Douglass as early as May 2006 suggested that everything in Drupal could be made a node and outlined the potential benefits of that. This idea pops up in various other occasions and really I guess it can be considered the progenitor of entities.

Let's introduce a new concept

So, one the one hand you have a lot of people arguing about why it is great to have everything as a node so that CCK can be used to add fields to things. One the other hand, you have a huge effort under way to add CCK to the core of Drupal 7. In a great demonstration of how the Drupal contrib space can act as a laboratory of what should happen in new versions of Drupal, and after some pretty amazing work by the Drupal 7 Field in Core developers the two ideas meet. The "everything is a node" meme, takes shape in Drupal 7 as "everything is an entity" and a type of entity is a node. However, also users, taxonomy terms and comments are entities and entities can immediately plug-in to the Field API and have fields added to them. However, the exact architectural solution to this didn't come about in one simple step. First things became fieldable (i.e. more like nodes). Then the need to streamline the functionality required to deal with things such as taxonomy terms, users, comments and nodes led to the introduction of entities as a means to group together all the code that was repeated in different places and standardize terminology. If you go digging in the Drupal issue queue you find a great issue called "Standarized, pluggable entity loading (nodes, users, taxonomy, files, comments)" - there Frando makes the case for streamlining how to deal with "loadable thingies, that can optionally be fieldable". Another interesting discussion is "Use the term entity instead of object, where the exact definition of Entities is discussed and this patch shows that even just a few months ago the code in Drupal was still not consistently using the right terminology (entities where referred to as objects) - but a some great efforts by Chx and yched fixed a lot of that.

Say hi to Entities

So now, just a couple of months away (fingers crossed!) from the release of Drupal 7, Entities are the new nodes. If you want to introduce some new fancy way of dealing with things and take full advantage of the power of Drupal you don't need to write a module that turns X into a node, rather you create your own entity (take a look at the Awesome Relationships module for a great example). This also means that one can now at least imagine a Drupal without nodes because the architectural tools to allow you to that are there. Nodes are just one type of entity. Of course, while you can imagine it actually getting that done at the code level is still not that simple since quite a few things are hardwired. But the first vital step has been taken. With the historical synopsis out of the way in a couple of days we are going to look at what entities are exactly and then explore how you can make use of them in modules. The second post is now online. Third post is online describing how to code enitities in Drupal 7