Token support

AFter studying token, it doesn't really handle the concepts of multiple objects, so using tokens is tough. If I have two node contexts, which one should be considered 'node' for token? Also, how to tell token tokens from Panels keywords?

The systems didn't appear to be compatible, and I had a long talk with Jeff Eaton about this topic. He agreed. So token support is very unlikely at this time.

It is possible that a 'token' content type could be used to create a content type with a basic HTML filter and token support. I actually am working on one of these that uses CTool's built in tokens.

Just to prevent any confusion., it won't use token.module -- that'd have to come from someone else.

The custom content type can now do context keyword substitutions. This will probably open a floodgate of requests for new tokens.

I was trying to figure out how to implement your feature request at CCK queue: #525362: Integrate CTools context keywords into node context

The more I think of it, the more I think we are about to duplicate code that's already provided by tokens. So I'm wondreing if it would be ok to use token as a provider for context keyword substitutions.

That way, there could be only one pair of hook_ctools_context_convert_list() and hook_ctools_context_converter_alter() to expose node related tokens to CTools, as opposite to require CCK implement these hooks, and the same for all modules that already integrate node related tokens.

There should be a good reason for not using token tokens here. It is there, widely used, servers the purpose and works. So why not?

Also, token module provides token_get_list() and this suggests something like ctools_converters_list() would be nice to have here, and that could also get information from token_get_list('node').

The issue with token is that it only provides things like 'node'. 'node_title'. I can have multiple nodes and multiple users and the current incarnation of token can, at *best*, guess which one you might mean. Now, eaton has been working hard on a revamp of token that uses a lot of the things he and I talked about when this system went in, and *that* version of Token will be very usable for this.

But the existing token implementation is not flexible enough.

hmm... is there any issue in the token queue about that where we can help?

markus_petrux, #113614: Add centralized token/placeholder substitution to core has the current state of the patch. It's also being kept in sync in the HEAD branch of token module. The 2.x branch for Drupal 6 will be backported when the final fate of token in D7 is ironed out.

Thanks a lot for the link. I'm mostly focussed on D6, and I'm missing most of these nice things that are happening in D7.

It seems it is almost in, and so I believe it would be better to delay CCK Fields integration with CTools converters. Since CCK already provides tokens, maybe CTools could take CCK food from there.

#2 merlin, rules module is dealing with multiple objects and tokens work there very well. you may load and operate on multiple nodes and users and tokens from any of them. Do you think ctools could use similar approach?

I found panels 3 to be rather cool, but inability to use tokens in visibility rules is slowing me down :)

I started a very limited issue for 'global' tokens support over at #627686: Add 'global', node and user token support, but it turns out it works for nodes, and presumably anything else too, with the 1.x branch of token.module. Very early days there but would appreciate reviews.

Just marked #627686: Add 'global', node and user token support as duplicate. This patch adds support for global, node and user tokens, passing the existing context replacement information through to token 6.x-1.x (by which time we only have one object to deal with anyway). Works well for me, could really use some testing.

Bumping this...I REALLY need to review this properly and see if we can't get it in.

subscribing

Ok. I renamed the 'global' context token, since it relies on token and exists only to provide token replacements.

On Jeff Eaton's advice, I changed token_replace to a bit more code that gets the token list and does just the replacement. It should be a touch more efficient.

This will work differently in D7, so we'll need to figure out how to port this to D7.

There was a good reason for calling the contet 'global' - token module itself has a global context for tokens like site name etc. which many contrib and custom modules support, so the commit means those won't work with ctools, whereas they would have with the patch as submitted.

No I should read the commit first, sorry :(

Note to those who were running the patch - make sure any tokens you're using already starting with %global are changed to %token - otherwise as long as you correct the context in exported panels it should work fine. A combination of that and several other things caught me out...

No, there was a bug, just a different one. 0 is a valid array key.

Committed. Thanks!

Hope this is not out of place on this issue...

I was having trouble with not all of the node tokens appearing in contexts. In plugins/contexts/node.inc, the reset() call in function ctools_context_node_convert_list() only returns the first element of the token list.

This patch flattens the results of token_get_list('node') so that all tokens are available.

This patch is for version 6.x-1.3

@astreib: I've opened a new issue #943896: Context converters using token module limited to one set (omits CCK fields, etc) for the problem you describe in #25, along with a simpler patch.

This no longer needs porting, and #26 points to a different issue with a better patch so we'll finish up this issue.