Move Global tokens to it's own section

It should be yes, this is currently due to the limitation of the token API. I had no time yet, to create a patch to improve token.

Note that there's one complexity in fixing this issue:

Tokens such as [node:url] won't be recognized anymore. Do you think that providing an upgrade path (in the .install file) is mandatory to fixing this issue? If you think that we can do without an upgrade path then feel free to assign this issue to me, I think I can handle it.

Here's my patch.

Note that there's one complexity in fixing this issue:
Tokens such as [node:url] won't be recognized anymore.

(It's OK, I solved this. [node:url] and such bogus 'global' tokens are still recognized --but they aren't listed anymore. So this 'backward compatibility' problem is now solved.)

I had no time yet, to create a patch to improve token.

The only problem I found with the token.module is that its theme_token_help() always include global tokens in the listing. So I had to provide a replacement theming function --which is a copy of the original but with a small enhancement.

====

There are two things to consider:

1. When only global tokens are used in a string, workflow_ng_token_get_used_arguments() returns an empty list. That's understandable. And I don't see that it causes any troubles. However, it might be possible that in the future some code will skip token substitution altogether if workflow_ng_token_get_used_arguments() returned an empty list --as an optimization measure. In that case it's possible to modify workflow_ng_token_get_used_arguments() to include a dummy arguments, say '_global', in the list if some global token is used.
2. Did you notice that workflow_ng_token_replace() has a little "bug"? It doesn't replace the argument tokens all at once. It uses a loop. So if some token expands to have in its text another token, this another token may get expanded in the following iteration. I didn't want to fix that because I've noticed there's a pending patch to fix some other issue at that area and I didn't want my patch to collide. So I had to follow your lead and just appended my own token_replace($text, 'global') there.

first off thanks for your efforts on this.

@1: indeed, that will be necessary so that tokens get replaced when only globals are used. We need to fix this before we can patch this.

@2: Indeed, that could be fixed. But I don't think it's likely to produce problems.

@patch: It's
}
else
not
+ } else {

Anyway, I think the better fix would be to get it into the token module, so that it's possible to use theme token help without globals. Perhaps you could give that a try?

When only global tokens are used in a string, workflow_ng_token_get_used_arguments() returns an empty list. That's understandable. And I don't see that it causes any troubles. However, it might be possible that in the future some code will skip token substitution altogether if workflow_ng_token_get_used_arguments() returned an empty list --as an optimization measure. In that case it's possible to modify workflow_ng_token_get_used_arguments() to include a dummy arguments, say '_global', in the list if some global token is used.

indeed, that will be necessary so that tokens get replaced when only globals are used. We need to fix this before we can patch this.

OK. But let me clarify matters:

Tokens do get replaced when only globals are used. That's because workflow_ng_token_replace() gets called unconditionally; even if workflow_ng_token_get_used_arguments() returns an empty list.

What I did was raise the possibility that in the future things would change; that some further optimization will be carried out. Or that programmers will do if ($arguments_are_used) { workflow_ng_token_replace() }.

That's why I sugested that workflow_ng_token_get_used_arguments() return a dummy '_global' variable: as a guard against these things.

However, thinking more about this, I'm not at all sure that this guard is actually needed:

1. This "further optimization" seems unneeded because workflow_ng_token_replace() is efficient enough. (My addition of token_replace($text, 'global') makes it less so, but a simple if (strtr($text, '[')) { .. } optimization will solve this.)
2. If programmers stick to the API, all will be alright. We shouldn't be babysitting programmers.

You be the judge here. Do you want me to return a dummy '_global' from workflow_ng_token_get_used_arguments()?

I think the better fix would be to get it into the token module, so that it's possible to use theme token help without globals.

It is true that Token's theme_token_help() currently lacks this ability, but this is only one detail. The rest of the patch is still needed. That's why I don't see a reason to wait for the Token module. When the Token module gets amended we will simply drop my replacecent theme_workflow_ng_token_help(), that's all.

(But, parhaps your idea for fixing this issue was completely different than mine?)

I'm also keen on getting this resolved...

The patch works great for me.

see http://drupal.org/node/289035 for a try to get it solved in token.