Working with Drupal tokens to build dynamic, personalised content

Drupal's Token system sits behind much of the personalised content you see on modern websites, quietly swapping placeholders for real values at render time. For site builders working anywhere from a small Melbourne consultancy to a national retailer with branches in Perth and Brisbane, tokens provide a way to make static pages feel relevant to every visitor without writing custom code for each use case. The same mechanism that injects a username into a welcome block can also power email subject lines, meta descriptions, and dynamic page titles across thousands of nodes.

What makes tokens worth the effort is their reusability. Rather than hard-coding strings or relying on brittle string replacement, you reference a placeholder such as [node:title] or [current-user:display-name], and Drupal fills in the right value based on context. This approach mirrors how content teams in Sydney, Adelaide, and regional centres already think about reusable building blocks, and it slots neatly into existing editorial workflows without requiring developers to step in for every change.

The Token module itself is part of Drupal core in recent versions, while contributed packages like Token Filter and Metatag extend its reach into areas such as WYSIWYG bodies and search engine snippets. Once you grasp the pattern, you can apply it across nodes, blocks, views, templates, and configuration objects, which is exactly where configuration management meets day-to-day content editing.

What tokens are and why they matter

A token is a small piece of placeholder text wrapped in square brackets that Drupal replaces with a real value when content is displayed to a user. The structure usually follows a pattern of [type:property] or [type:property:subproperty], for example [node:author:name] or [site:slogan]. The pattern is consistent, predictable, and easy to read, which is why it has become the de facto way to inject dynamic data into fields, templates, and outgoing communications.

Behind the scenes, Drupal looks up the available tokens through hook_tokens() in modules that define them, and the Token module provides a browsing UI at /admin/help/token. For Australian teams managing sites that need to display AEST/AEDT times, GST-inclusive prices, or local store details, this approach means content can adapt without template duplication. The mechanism works for a single landing page in Hobart just as well as it does for a multi-site rollout serving customers in Cairns, Darwin, and Canberra.

Tokens differ from simple string substitution in one critical way: they are context-aware. The same [node:title] placeholder resolves to the title of whatever node is being viewed, while [current-user:mail] resolves to the logged-in user's email address on a per-request basis. Context-awareness is what allows editorial teams to author content once and have it behave correctly everywhere it appears.

The core token module and available placeholders

Drupal core ships with a substantial token set covering nodes, users, taxonomy terms, comments, and site-wide configuration. Common placeholders include [site:name], [site:slogan], [site:mail], [node:title], [node:url], [node:author:name], [current-user:display-name], [current-user:account-name], and [term:name]. For sites with commerce functionality, [commerce-order:order-number] and [commerce-order:total] become available once Commerce modules are enabled. Each module can extend the available placeholders by implementing hook_tokens() and declaring them through hook_token_info().

To see exactly what is available on your site, browse to the token help screen at /admin/help/token. The page lists every token grouped by module, with examples and short descriptions. For a Sydney-based media company using Drupal for editorial workflows, this page is often the first stop when configuring automated social media posts or newsletter templates. Reviewing it once saves hours of guesswork later.

A useful pattern is to combine tokens with modifiers. The chained syntax [node:created:short] outputs a short date format rather than the full timestamp, while [node:author:edit-url] produces a direct edit link for the author. Some contributed modules add additional modifiers, such as [commerce-price:amount:formatted], which is handy for Australian ecommerce sites needing GST-inclusive display. These modifiers keep templates clean by moving formatting logic into the token layer.

Creating custom tokens for site-specific data

Most projects eventually need tokens that do not exist in core or contributed modules. Defining your own is straightforward: implement hook_token_info() in a custom module to declare the new tokens, and hook_tokens() to provide the values they should resolve to. The Token module handles caching and replacement automatically once both hooks are wired in. The Drupal configuration API walks through similar patterns for site-wide settings if you need a foundation in configuration management first.

A common Australian use case is a chain of retail stores that wants each location page to display opening hours, the local branch manager's name, and a contact email. You could expose tokens like [store:hours] or [store:manager] by reading from a custom entity or from configuration objects. The logic lives in your custom module, while editors continue to use simple placeholders in their text fields. This separation keeps content authoring friendly even for non-technical staff in remote offices from Broome to Ballarat.

Custom tokens can also read from the State API or the Key module for sensitive values. For example, a token that returns a customer's loyalty number could pull from a session-stored value, or a token that returns an ABN lookup result could call an external API and cache the result. When working with personally identifiable information, remember to comply with the Privacy Act 1988 and the Notifiable Data Breaches scheme in Australia, which influences what you should and should not place in tokens that may be cached or logged.

Using tokens in views, fields, and templates

Once tokens are available, the next question is where they can be used. Views, the field display system, and Twig templates all support token replacement, often with slightly different syntax. In Views, the "Rewrite results" field allows you to inject replacement strings like {{ title }} or other context-aware placeholders into rewritten output. Twig templates use the render system directly, and many modules expose their values through preprocess hooks so tokens work in a {{ node.field }} context.

For meta tags, the Metatag module integrates tightly with the Token module, allowing token values inside page titles, descriptions, and Open Graph fields. This is particularly valuable for an Australian publisher targeting local search across Melbourne and Brisbane suburbs, where dynamic title tags can incorporate location data without requiring separate templates. A node template can use Twig syntax such as {{ node.label }} directly, while a block or WYSIWYG body continues to rely on the square-bracket syntax.

Another productive use is in custom block configurations. When you edit a block and place placeholder text such as Welcome back, [current-user:display-name] in the body, Drupal automatically replaces it with the current user's name when the block is rendered. The same approach works in Views header text, footer text, and exposed filters where labels can be customised per user. Editors gain a flexible tool, and developers gain fewer requests for one-off template adjustments.

Tokens and configuration management across environments

Tokens interact with Drupal's configuration system in interesting ways. Configuration entities and simple configuration are exportable through the Configuration Manager, and the configuration API handles defaults, overrides, and synchronisation between local development, staging, and production. Because tokens resolve at render time, they are an elegant solution for values that change between environments.

A token like [site:mail] can resolve to a different address on production than on a local development build, as long as the configuration override is loaded correctly. This is especially useful for Australian government clients running separate environments for production, UAT, and disaster recovery, each needing distinct sender addresses for compliance reasons. Tokens keep your templates portable while still respecting environment-specific overrides.

When exporting configuration, the YAML Token module lets you embed tokens directly in configuration files. This is helpful for multi-site rollouts where customers across the country, from Parramatta to Penrith, share a single codebase but need their own branding strings, addresses, and trading names. Pairing configuration management with tokens lets you maintain a clean separation between shared code and per-site customisation, which is particularly useful for organisations deploying across .au domains with different regional requirements.

Practical examples for editors and site builders

A practical starting point is a personal welcome message. Edit a block, set visibility by role, and place text like G'day, [current-user:display-name]. You will see the actual name when the block renders for a logged-in user. Australian editors often use this in member portals where staff or subscribers see personalised greetings. It takes a single block edit, with no template overrides required.

Another useful pattern is a node teaser that pulls in the author's bio. By combining [node:author:name] with a custom token for the author bio field, you can produce a byline that updates automatically as content rotates through authors. News sites in Sydney and Melbourne rely on this for fast-moving editorial calendars where authors change daily. The token does the work, and editors focus on content.

For ecommerce, tokens enable transactional emails and order summaries that include order details, customer names, and totals without template duplication. A token like [commerce-order:order-number] combined with [commerce-order:total:formatted] filters down to a single line of business context per customer email. Pattern this for invoices, renewal notices, and similar transactional pieces, and tokens become the backbone of Drupal content personalisation across the board.