token_get_values, token_replace, and token_replace_multiple could all take an $options argument that would get passed through to hook_token_values.

I ran into the need for this when using views_bookmarks, which calls token_get_values, but does not pass in the teaser value. When any of the CCK fields display differently based in a teaser (in my case an imagefield), use of token through views_booksmarks changes the node display.

The attached patch provides an additional argument array named $options that can be used to pass object specific information. I'd prefer to have put the $options array after $object and before $flush, but I didn't want to break any other uses, so the new argument is at the end.

I've marked this as a "feature request", but you might consider it a bug. It certainly causes bugs other places.

CommentFileSizeAuthor
#1 167560.patch3.32 KBdouggreen
token-node-teaser.patch3.35 KBdouggreen
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

douggreen’s picture

douggreen CreditAttribution: douggreen commented
FileSize
167560.patch3.32 KB

Sorry, removing extraneous file references in patch.

douggreen’s picture

douggreen CreditAttribution: douggreen commented

See also #167562, a views_bookmark patch that uses the additional argument.

Bevan’s picture

Bevan CreditAttribution: Bevan commented

subscribing

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles commented
Status: Needs review » Reviewed & tested by the community

well, I definitely see the utility in this and think eaton does to, but I'd like to get his blessing first.

So, it's RTBC AFAIConcerned, but it's at least somewhat up to eaton since I know he has some vision on this.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles commented
Status: Reviewed & tested by the community » Fixed

Thanks doug - really great stuff that will help extend the module quite a bit.

For the 2.x branch of token we'll probably rework this, but for now it's solid.

Applied to both the 5.x and 4.7.x branches.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles commented

One concern that I have about this is that people can arbitrarily declare their own options. And given the distributed nature of tokens two modules may declare different meanings to their options.

I've thought that a way to control this would be to have an array of known keys and only pass through options that are in those known keys. This way the module acts as a gatekeeper and forces the keys to be defined somewhat centrally.

Does that seem reasonable? Overly cautious? Still not effective enough?

Anonymous’s picture

(not verified) CreditAttribution: commented
Status: Fixed » Closed (fixed)