We have the ability to do token replacements in Core. But we don't have a token browser. It's currently provided by the Token contrib module (http://drupal.org/project/token). Without a token browser, there is no way for users setting up tokens to discover what tokens are available to them.
Add something similar to the browser from the contrib Token module to core.
This issue will be limited to building a tree-based token browser.
We'll spin off other issues as necessary to deal with:
- Autocomplete
- Search
- Token naming
- A UI that changes based on the size of the list (flat -> tree etc.)
1. Make a patch that adds the browser similar to the contrib Token module to core. However, it shouldn't actually *be* that browser, since it's not efficient/scalable and is also not accessible.
2. Make sure there are tests for it.
3. Make sure it is accessible.
4. Make sure it is usable.
Core would have a token browser, which would be displayed whenever tokens are usable in the admin UI.
None.
Many different parts of the Drupal admin interface use placeholder tokens inside of a longer stretch of text to represent "some value that will be replaced later." Sending out welcome emails to users is a common case: core allows admins to enter the text of the mail, with placeholder tokens like %user-name and %site-url.
Token module is a popular contrib module that offers similar functionality to modules that need placeholders/wildcards for other purposes. Modules can provide new tokens, like "[og-name]" for "The name of the organic group that a node belongs to" or [site-slogan] for "The site slogan the admin entered on the site settings page. Users can then use those placeholder tokens in any token-enabled field (like pathauto's configuration page). Token module is being proposed for inclusion in Drupal 7 core, because its centralized 'registry' of placeholder tokens is useful all over core and contrib.
The challenge (and it's a tricky one) is how to properly explain to users what tokens are available to be used and what they mean when they are presented with a field that can "accept" tokens. Several solutions to this exist right now, and some brainstorming has been going on for the Pathauto module, but ironing it out for core would be very beneficial.
Right now, in Drupal 6, token module provides a helper function that just spits out a table of all the tokens that are available. This is less than ideal, because with a number of token-providing modules installed, the list can get really really long. Some modules (like pathauto) manually build their own lists of tokens broken up by the 'kind' of token. (Node related tokens, user related tokens, etc.)
Some existing links include:
http://groups.drupal.org/node/19500
http://www.flickr.com/photos/mverbaar/3595675392/in/set-72157619245872526/
What are the essential 'bits of information' that might be conveyed for tokens?
1) The 'token type' -- node, user, etc.
2) The token as it is used by a module -- for example 'title' or 'uid' or 'mail'
3) The user-friendly name of the token -- for example "Node title" or "User ID"
4) An optional extended description of the token -- for example, a fully formatted date demonstrating how the 'date' token will appear
5) The token as it can be entered by a user -- for example [user:name]
6) The token as it can be entered if chained with another token -- for example [node:author:name] instead of [user:name]
In the quick omnigraffle mockup below, I've listed an example of the sort of things that might be commonly entered into token-enabled fields. The fields themselves don't have to do anything special with the tokens -- they just need to have some way of presenting the 'possible' tokens. Some existing ideas include: a collapsible browsable list of tokens, grouped by token type (like 'node' and 'user' and 'site'). Auto-complete in the text fields themselves. A popup. Something made of magic.
Any thoughts? Anyone? Beuller?
Needs work
11.0 🔥
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
As a separate issue, once there's a token browser in core maybe field types could be extended to add an option indicating whether the values can have tokens? Then the system could automatically provide the token browser link and process the value during rendering. That would IMHO save some of the complexity that site builders have with wanting to use tokens in different fields.