Node references in Drupal 7

Node references are common on Web sites and are not built into Drupal. You get the choice of several modules to provide references in various ways. Here are the most common choices plus the tradeoffs between flexibility and performance.

When do you use a node reference?

Think about a node of type Book review containing a review of Matthew Reilly's Area 7. You also have a node of type Author containing information about Matthew Reilly. You want to add a reference from the Area 7 page to the Matthew Reilly page. That is a one way reference and all the modules mentioned on this page can create that.

What happens when you delete the page about Matthew Reilly? (You would not delete the page because he is still writing good books.) You want the reference to Matthew Reilly removed from the Area 7 page. Do you want the whole reference removed or do you want the link replaced by plain text? Changing references is a complicated procedure. None of these modules will do exactly what you want every time. The Relation module delegates some of the work out to the Rules module so you can perform a wider range of tasks than what is provided by the Relation module.

When you create a reference from the Area 7 page to the Matthew Reilly page, do you want a reference automatically created from the Matthew Reilly page to the Area 7 page? There are many ways the link might be created. The Relation module might create the link or one of the Relation add-on modules might do what you want. often what you want is not automatic and you have to do something extra.

If you want a simple link from the Matthew Reilly page to the Area 7 page in a paragraph describing the Area 7 book, you could create that by hand after creating the Area 7 page. All the modules mentioned here can create the link because it is a simple node reference.

Lists of references

Perhaps you want a list of books by Matthew Reilly listed at the end of the Matthew Reilly page. You could create a module to do that and have absolute control or you could write a View to list the books. Writing Views is another form of programming and has the same requirements to analyse the impact as you would have when writing a module. In this example, Views would be the easiest way to create the list because there is nothing complicated. If you needed additional information and Views has to generate an SQL join, Views will probably fail. The problem is not the reference between the two nodes, it is the gathering of any data not in the two nodes.

You might want only a minimal list of links at the end of the Matthew Reilly page and that could be created easily as a link field with multiple entries. The endless choices come down to the automation of three tasks. Assume you have nodes AA and BB. You want to easily create the reference from AA to BB when creating AA, you want to automatically update the reference displayed in AA if the referenced text in BB is changed, and you want to automatically change or delete the reference in AA if BB is deleted. You may also want to perform the same tasks from the other end, you may want a reference from AA to BB to create a refrence from BB to AA then update BB when AA changes.

References

References, drupal.org/project/references, provides the same type of references used in the CCK add-on module for Drupal 6. Part of Drupal 7, the core Fields module, is based on part of CCK. Other bits of CCK are scattered around as separate add-on modules plus there are new add-on modules to do what CCK never did plus better versions of what CCK never did in an intelligent fashion. References provides replacements for the Node reference and User reference fields from CCK.

References is a 37 KB download and chews up 155 KB on disk because it provides both types of references and it attempts to handle every possible type of connection to Views and other modules. The code is an ancient design with everything loaded all the time including a lot of what looks like administration interface code that should be loaded only when needed.

There is some development work on References 2.0 in the dev version but not much. On the plus side, the module has twice as many users as all the alternatives put together.

References contains three modules, the base References module, the Node Reference module and the User Reference module. Here are their prerequisites.
References: Field (Drupal core and always on), Field SQL storage (Drupal core and always on), Options (Drupal core and always on).
Node Reference: References plus Field (Drupal core and always on), Field SQL storage (Drupal core and always on), Options (Drupal core and always on).
User Reference: References plus Field (Drupal core and always on), Field SQL storage (Drupal core and always on), Options (Drupal core and always on).

Entity reference

Entity reference, drupal.org/project/entityreference, is supposed to be the replacement for References and is catching up. The Entity reference is dependent on a bunch of other modules but still ends up almost as big as References. Weird.

Entity reference uses at least one add-on module, cTools, that is rarely used on regular sites and is a big overhead for the tiny amount used in Entity reference. cTools is a big splatter of unrelated modules squashed into one package and should be broken up the way CCK was dismembered. Some big complicated sites use cTools because they installed a module that lists cTools as a prerequisite. When you see cTools as a prerequisite, think bloat.

You may have to convert to Entity reference references in Drupal 8. Perhaps by then cTools and Entity reference will be replaced with something better. If you are already using references, there is very little reason to convert from References to Entity reference before Drupal 8 and, with Entity reference having more issues open than References, plenty of reasons to wait.

Relation

The Relation module, drupal.org/project/Relation, adds more overhead than the References module and Relation makes the references bidirectional. When you change one end of a relationship, you can change the other end at the same time. You might need the extra power of the Relation. If you do, factor in extra memory and processing power for the extra database activity.

Relation and Entity reference share several characteristics. Neither has a stable version and both have out of date release candidates. you will have to work from the development versions for an unknown time. I hate working from the development versions because you never know when they are updated or what they will break.

The Relation module requires the Relation Select add-on module, drupal.org/project/relation_select, to be a usable replacement for the Node reference part of References. The Relation Select add-on module is almost as big as References. If you do not require the features of Relation, you can save some serious bloat by using References.

Conclusion

For a simple reference form one node to another, use References. If you need to run rules to update both ends of a reference, use Relation and Relation Select.