Suppose we have numerous entities of types Alpha and Bravo. Alpha entities could easily be taxonomy terms and Bravo – content nodes. Bravo entities can reference multiple Alpha entities each; whereas, Alpha entities (taxonomy terms) are completely agnostic of any other entities.

The exercise is to aggregate all Alpha entities that are referenced together (by the Bravo entities) with a given Alpha entity.

Example: Alpha entity type is a taxonomy vocabulary containing Artists. Bravo is a Project content type. Sometimes Artists collaborate on Projects; therefore, some Projects have multiple Artists. An example of the aggregation in question would be to list all Artists that a given Artist has collaborated with (has been referenced in the same Project with).

I am building the information architecture for my first Drupal project, in which metadata and it's inter connectivity is important. I have achieved this aggregation using Views, but Views seems impractical for my uses. In many cases I want to list just Taxonomy term names like this:

Nirvana has collaborated with: Biggie Smalls, Lil' Wayne, Lil' Jon.

(Of course, I wouldn't want my Taxonomy system to make jokes)

What aggregation solutions are there? Do you have tips? Have you done something like this?

Why I'm looking for an alternative to Views:

The reason I find Views impractical for this use: my impression is that it's geared more towards heavier listing, like catalogs and is hard to squeeze into "lighter" roles (like the one in my example). If I am fooling myself, do correct me.

  • The reason I find Views impractical for this use: my impression is that it's geared more towards heavier listing, like catalogs and is hard to squeeze into "lighter" roles (like the one in my example). If I am fooling myself, do correct me. Commented Jan 27, 2013 at 13:31
  • 2
    My personal experience is that we can use views for almost all kinds of listing with a little bit of tweaking here and there. Commented Jan 27, 2013 at 15:48
  • The alternative to views is to code your own queries. drupal.org/node/242311 If you can't write your own queries then views is your only choice and it is great for something simple and complex. Commented Jan 27, 2013 at 15:53

2 Answers 2


If you're looking for a good core alternative to select entities, using custom queries, make sure you familiarize yourself with Entity Field Query (EFQ)

e.g, fetch 10 published article nodes with field_my_field value 'foo':

$query = new EntityFieldQuery();

$query->entityCondition('entity_type', 'node')
      ->entityCondition('bundle', 'article')
      ->propertyCondition('status', 1)
      ->fieldCondition('field_my_field', 'value', 'foo')
      ->range(0, 10)

$result = $query->execute();

if (isset($result['node'])) {
  // nids are here
  $nids = array_keys($result['node']);
  // nodes can be loaded as such
  $nodes = entity_load('node', $nids);

More EFQ info here

  • Thanks for the tip. Note I am very green at coding Drupal. How do you implement custom functions (like the one you're recommending me to code) into a Drupal site? Commented Jan 29, 2013 at 17:59
  • you do this usually in a new module (you'll create) and implement that as a page callback, see hook_menu() for reference. Commented Mar 18, 2014 at 11:54

Views performance is OK, if you use caching. At least in this example, data won't change alot over the years. And if you preprocess, queries will be much lighter.

Suggested steps:

A. Outer view settings

  1. Using your example, add a Term Reference field to the Projects content type, which will reference the Artists taxonomy (allow for multiple terms).
  2. Make a view on the Artist taxonomy terms, then add an inner view as field (call it collaborators). The connection to the inner view is defined using the views_field_view module.

B. Inner view settings (picture below):

  1. Make the inner view field-based, and set the term ID as it's contextual filter (under advanced settings). It should only show projects which add the term ID to their term reference field.
  2. Change the fields of the inner view so it will only have one field - the term name, and don't provide default wrapper elements - to make it lighter. Also use a plain text formatter for the field so that there won't be any extra output - it will be even lighter.
  3. Field settings of the 'Artists' field on the inner view: Open the collapsed 'multiple field settings' link on the field settings dialog and uncheck the option "Display all values on the same raw". Now each value will be on a separate row.
  4. Add a new filter criteria to filter all terms whose id is equal to the contxtual filter we got as argument.
  5. Go to the 'Query settings' under 'Advanced' and set the 'Distinct' option.
  6. Also activate block caching.

Inner view settings

  • Thank you for your response. I will try this now. By the way, is "Views Caching" as in Views content cache what you meant by preprocessing? Commented Jan 29, 2013 at 16:04
  • I'd like to express my gratitude again for your step by step tutorial. It has been interesting to use the views_field_view module; and you're right about the caching, the outer (parent) view takes 150ms to render. However, I will continue looking for other solutions, this approach (all approaches with Views that I've tried) is cumbersome, and the output is extremely inflexible. Commented Jan 29, 2013 at 17:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.