stuar.tc

booting decoupled front end…

← all posts
2026.07.23 · 2 min

Field Tokens 2.0.0

DrupalPlanet Drupal

I lose count of how many times I've reached for Field Tokens on a project, then hit the same wall: a multi-value image field, and no clean way to say "give me all of them, formatted" in a single token. You could grab one delta at a time, or write custom PHP to loop over the field yourself, but there was no in-between.

If you haven't used it: Field Tokens adds two token types Drupal core doesn't ship with, formatted field tokens (render a field value through a chosen formatter) and field property tokens (reach into a field's raw properties, like an image's alt text or a link's URL). It's one of those modules that quietly becomes load-bearing on a token-heavy site the moment you need either.

2.0.0 finally gives that in-between a real syntax. The delta segment of a formatted field token now accepts a single index (0), a comma list (0,2,4), a range (0-2), a mix of the two (0-2,4), a wildcard for every value (*), or nothing at all, which also means every value, with a configurable delimiter for however you want the output joined. So a multi-value image field, rendered through the thumbnail image style, all values at once, is just:

Wildcard delta, image style
[node:field_image-formatted:*:image:image_style-thumbnail]

That's the whole token. No loop, no custom formatter, no falling back to a Twig template just to get every value out. The wildcard and range syntax came out of issue #3267442.

The other half of 2.0.0 is dot notation, for two separate things. First, reaching into a nested formatter setting: most image style and responsive image formatters bury their real configuration a level or two deep, and before 2.0.0 you simply couldn't address that from a token. Now you can chain keys with a dot:

Nested formatter setting
[node:field_image-formatted:0:image:image_loading.loading-lazy]

Second, the same dot notation works on field property tokens, so a nested key inside a property value is addressable the same way, rather than only ever returning the whole structure and leaving you to parse it yourself downstream.

Custom Formatters integration is back too. The original data provider broke during the Drupal 8 port, which meant if you were using the Custom Formatters module to build your own formatter plugins, Field Tokens simply couldn't see them, and [formatted_field-*] tokens went quiet. 2.0.0 re-implements that data provider from scratch, so if you've been maintaining a workaround, you can retire it.

And for anyone weighing Drupal 11 readiness before committing to a module: Field Tokens 2.0.0 declares ^10.1 || ^11, so it's covered.

If any of this solves a problem you've been working around:

composer require 'drupal/field_tokens:^2.0'

Source on GitHub, the full project page on Drupal.org, and if it's saved you some time, sponsorship is always appreciated.

This one's part of a bigger push I'm on at the moment: going back through my modules one at a time and getting them properly stabilised, real code coverage, CI that actually means something, releases that don't sit in RC for years. Field Tokens is the first of several I've got lined up, so expect more of this over the coming months.

Discussion

via GitHub Discussions