Author image
Senior Developer

Entity Token

The Entity token module is part of the Entity package of modules, it provides lots of new tokens to use everywhere that tokens are currently available. It does this by being aware of the structure of fields on entities and exposing extra options for fields that reference entities. For example, it allows you to use many more tokens about taxonomy terms added to content.

Pathauto

To see this in action we'll consider a simple example.

Say that we have articles about birds on our site, suppose further that each article is about a specific species of bird. We make the simplification that each species is part of a single family of species. All that boils down to us having a 'Species' vocabulary that looks like this:

Listing of the species vocabulary

We then add a taxonomy term reference field to our article content type, field_species and we set it up to use our vocabulary. We ensure that our content editors only create articles about a specific species and not a family of species.

What we'd like to do is have nice URLs like the following:

articles/crow-family/rook/eating-habits-rooks

For an article about Rooks.

We can use the Pathauto to set up nicer URLs, but Drupal core doesn't provide the tokens that we need. We need to get the root term (top level parent) of the selected species (which is the family) and add that to our path. Enter Entity Token, it knows that the field_species field contains a taxonomy term, and that taxonomy terms have a root term.

You can explore the tokens that Entity token provides:

List of tokens on the article content type

And we can see that we have all the tokens we need. So we can set up Pathauto using the following pattern:

articles/[node:field-species:root]/[node:field-species]/[node:title]

Then if you create an article, you will see that the URL path generated is like the one we wanted above. Cool!

Comments

A side note on the entity tokens... when on an admin page that displays all available tokens (often node edit pages may be an example), because the module provides so many potential tokens (which is brilliant!), it does mean that several thousand links will be in the page. Any javascript running on that page that does things to links, or that might traverse the DOM elements in the tokens table will spend a long time going through all those elements.

The overlay module is particularly susceptible to this, as it checks all links on any page shown within the overlay to see whether they should be opened within the parent window or the overlay itself.

The solution I took was to limit the depth of the token table, so that only three levels are shown. 'Deeper' tokens still exist, but just aren't shown to users, which means the javascript doesn't appear to freeze a page. Here's my code that does this - just put it in a custom module, replacing MYMODULE with your module's name:

/**
* Implementation of hook_theme_registry_alter().
*/
function MYMODULE_theme_registry_alter(&$theme_registry) {
  // Lower the recursion limit on token trees, since it can have 10000+ links
  if (isset($theme_registry['token_tree'])) {
    $theme_registry['token_tree']['variables']['recursion_limit'] = 2;
  }
}

This will limit all token tables. If you only have certain pages affected, you may prefer to form_alter() those specific ones where possible. For example, the metatags module adds the token table to node forms, which you could limit like this instead:

/**
* Implements hook_form_BASE_FORM_ID_alter().
*/
function MYMODULE_form_node_form_alter(&$form, &$form_state, $form_id) {
  if (!empty($form['metatags'])) {
    $form['metatags']['tokens']['#recursion_limit'] = 1;
    $form['metatags']['tokens']['#suffix'] = t('Subtokens of each token may be available, but are not shown here.');
  }
}

You will probably need to flush caches after adding either of these hooks to your module before they are picked up by Drupal.

Comments on this article are now closed, if you want to give us feeback you can use our contact form instead.