user_token_info currently has:
function user_token_info() {
$types['user'] = array(
'name' => t('Users'),
'description' => t('Tokens related to individual user accounts.'),
'needs-data' => 'user',
);
$types['current-user'] = array(
'name' => t('Current user'),
'description' => t('Tokens related to the currently logged in user.'),
'type' => 'user',
);
...
return array(
'types' => array('user' => $types),
'tokens' => array('user' => $user),
);
}
Resulting in the 'types' of token_info() with:
Array
(
[comment] => Array
(
[name] => Comments
[description] => Tokens for comments posted on the site.
[needs-data] => comment
)
[node] => Array
(
[name] => Nodes
[description] => Tokens related to individual content items, or "nodes".
[needs-data] => node
)
[site] => Array
(
[name] => Site information
[description] => Tokens for site-wide settings and other global information.
)
[date] => Array
(
[name] => Dates
[description] => Tokens related to times and dates.
)
[file] => Array
(
[name] => Files
[description] => Tokens related to uploaded files.
[needs-data] => file
)
[term] => Array
(
[name] => Taxonomy terms
[description] => Tokens related to taxonomy terms.
[needs-data] => term
)
[vocabulary] => Array
(
[name] => Vocabularies
[description] => Tokens related to taxonomy vocabularies.
[needs-data] => vocabulary
)
[user] => Array
(
[user] => Array
(
[name] => Users
[description] => Tokens related to individual user accounts.
[needs-data] => user
)
[current-user] => Array
(
[name] => Current user
[description] => Tokens related to the currently logged in user.
[type] => user
)
)
)
Which is just odd, and doesn't follow the documentation for hook_token_info, which mentions nothing about nesting:
An associative array of available tokens and token types, each containing the raw name of the token or type, its user-friendly name, and a verbose description.
So any time a module (like token in D7) wants to print out a listing of token types, we have to account for this weird nesting. This should just be flattened out.
Comments
Comment #1
dave reidSimple patch for review. Note this doesn't affect the *actual* token replacement functionality, but only affects modules that want the info about the tokens.
Comment #2
arhak commentedcurrent-user is a type.. of type user
does it make sense having current-user as a type?
can it be chained to anything?
it is not contextual, rather global (like current date, there is no current-date type)
Comment #3
eaton commentedIn D7, 'user' is a particular type of token. If the module doing token replacement passes in an explicit user account object, by default, it will be used when an admin uses tokens like [user:name].
In D6, this type of 'user token' did double-duty. If a module passed in a user account, token would it for 'user tokens'. If not, it would use the currently logged in user. This made certain situations tricky -- like using tokens to create an email subject line that includes the name of the currently logged in user AND the name of the message's recipient.
Basically, modules can use 'user' type tokens when they pass in an explicit account, but if they have multiple users that are involved in a text replacement operation, they can create named aliases for the 'user' token domain. For example, 'recipient' and 'sender' would be semantically meaningful 'token types' that are just aliases for the 'user' token domain.
That's how 'current-user' works. It allows the normal 'user' token domain to operate consistently, replacing tokens only when an explicit account is passed in, while 'current-user' is an alias for those tokens that ALWAYS uses the currently logged in account.
The 'token info' data does seem to be borked for those types of chains, so the patch is a good one, but the separation of 'user' from 'current-user' is a legitimately useful construct, IMO.
Comment #4
dave reidThanks eaton for the good explanation. Basically, the list just should be one-dimensional. :)
Comment #5
webchickWhile technically an API change, it looks like this is merely correcting an oversight we didn't catch during development.
Committed to HEAD, thanks.
Comment #6
dave reidThanks webchick. Now that this is in I've got a fun token browser to start showing off in token.module. :)
Comment #7
arhak commented@#3 thanks for the explanation, but its functionality was clear
being a separated "type" of token was not, but won't be addressed here
Comment #8
eaton commentedJust a clarification: it's NOT an API change, it's just a change to metadata. Core doesn't even use that metadata anywhere right now, it's just for contrib modules that need to to advanced token manipulation and display.
It's equivalent to a menu hook having the wrong permission callback, or a FAPI element having a non-fatal (but functionality-impairing) typo in one of its properties.