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.
- Efficient (code/load time - current treeTable implementation of the contrib Token 7.x module breaks with lots of tokens)
- Accessible (current TreeTable implementation is not!)
- Efficient to find the token you are looking for ("scannable")
- Search capability - which may or may not be different from autocomplete
- Hierarchical structure of tokens reflected in hierarchical-looking UI (intuitive)
- Screen real estate (keeping mobile in mind too!)
- Maybe different modes depending on the scope of the token list?
- Flat list if there are only a few
- Tree list and/or hierarchical autocomplete and/or search if the list is longer
- Not loading the entire list initially if it's really long (page load time)
- Reusable UI pattern that can be used in Rules, Panels, Blocks, Layouts, Views, Etc. for both tokens and "token-like things".
- Naming conventions / standards for "token-like things"
Scope for this issue
This issue will be limited to building a tree-based token browser.
We'll spin off other issues as necessary to deal with:
- 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.
User interface changes
Core would have a token browser, which would be displayed whenever tokens are usable in the admin UI.
Original report by eaton
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:
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?
|tokens.png||24.99 KB||Ignored: Check issue status.||None||None|