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.

CommentFileSizeAuthor
#1 735354-user-tokens-nested-D7.patch530 bytesdave reid

Comments

dave reid’s picture

Status: Active » Needs review
Issue tags: +token
StatusFileSize
new530 bytes

Simple patch for review. Note this doesn't affect the *actual* token replacement functionality, but only affects modules that want the info about the tokens.

arhak’s picture

current-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)

eaton’s picture

Status: Needs review » Reviewed & tested by the community

does it make sense having current-user as a type?
can it be chained to anything?

In 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.

dave reid’s picture

Thanks eaton for the good explanation. Basically, the list just should be one-dimensional. :)

webchick’s picture

Status: Reviewed & tested by the community » Fixed

While technically an API change, it looks like this is merely correcting an oversight we didn't catch during development.

Committed to HEAD, thanks.

dave reid’s picture

Thanks webchick. Now that this is in I've got a fun token browser to start showing off in token.module. :)

arhak’s picture

@#3 thanks for the explanation, but its functionality was clear
being a separated "type" of token was not, but won't be addressed here

eaton’s picture

While technically an API change, it looks like this is merely correcting an oversight we didn't catch during development.

Committed to HEAD, thanks.

Just 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.

Status: Fixed » Closed (fixed)
Issue tags: -token

Automatically closed -- issue fixed for 2 weeks with no activity.