Along with a host of other new features, there was a major structural change between Drupal versions 6 and 7. This concept is known as the entity. Drupal 6 developers were/are intimately familiar with the three major parts of architecture – nodes, taxonomies, and users.

With the advent of the entity, these building blocks need to be reconsidered and examined in a different light. This is not the focus of this post however, so go here to read more about the entity system.

The question really is, should one spend the time to build their own custom entity, or should one extend the built-in entities packaged with Drupal 7?

Because nodes, taxonomies, users, etc. are all now entities, they can be extended using the Field API. Essentially, any field present in the Drupal system can now be added to anything else in the system; for example, a user no longer needs to be extended using a profile module. Rather, fields such as first name, last name, and other personal information can now extend the user entity.

Additionally, default fields can be removed. Many may remember back in the days of Drupal 6 where the “body” field was requisite – it is no more. D7 allows removal of the body field and the addition of any other field present in the structure.

Entities and their associated fields are fully supported in views as well, so pulling in an additional field from an extended taxonomy vocabulary is as simple as relating the term to whatever is being displayed.

There are several challenges when building a custom entity that make the decision even more difficult. First, there are a couple of model entities upon which a custom entity may be based, but they are most definitely for developers only, and not very well documented.

Next comes integration into views and permissions – a custom entity must add an entire permission set as well as provide views integration (which is almost always desirable). These are relatively complex issues with which even an experienced developer will have problems.

Lastly, custom entity support is not completely supported by all contributed modules. A good example of this is pathauto, which provides a little bit of entity integration but does not yet allow for separate bundles nor bulk updating at the time of this post. URL aliases are quite commonly used, so this is a major consideration.

All in all, custom entities provide a powerful tool for code and field reuse, but with the ability to now extend and customize the default entities and the relative complexity involved with coding a custom entity, it is almost always a better choice to go with the default system.

The main exception to this rule occurs when there needs to be a main structural element built which will contain common data with minor deviations. In this case, a default structure that is pre-defined may be of use, but even then, an attempt probably needs to be made to try to utilize the node entity before attempting a custom.

Custom entities should be reserved for those who are expert Drupal programmers. Even experienced programmers will find cause for frustration within the new entity system, until it ‘clicks’. Look forward to hours of research, frustration with lack of documentation and support by contributed modules, and look-and-feel issues if the choice is made to use a custom entity. Otherwise, entertain the idea of bringing in a consulting organization such as Accella, which has experience with large-scale deployments utilizing custom entities.