I'm using token_replace() within an input filter (#637662: Configurable title text). content_token_values() causes a bad output and has an unnecessarily performance impact since content_view() (_content_field_invoke_default('view', $node, $teaser, $page);) calls the filter hooks of a field which mustn't happen when loading tokens. Could we prevent using content_view() or alter it to avoid the loading of the view output of the field?

Comments

markus_petrux’s picture

Category: bug » support
Status: Active » Fixed

Each text field provides 2 tokens:

- raw: Raw, unfiltered text.
- formatted: Formatted and filtered text.

You should try with the one that better suits your particular use case.

The fact that filters are invoked is basically because the current version of the token module generates all token values, regardless of the tokens a particular replacement operation needs. As a mere token provider, we can do nothing about it.

Roi Danton’s picture

Category: support » bug
Status: Fixed » Active

No, the problem is not related to the usage of tokens. It occurs also when calling tokens_replace() (which invokes the hook content_token_values()) even if the text contains no tokens at all. Other token_values hooks doesn't have this problem. So - despite how tokens generates the token values - the problem occurs when using content_token_values().

For details how this bug was detected and the other token_values hooks used see this comment. Unfortunately I'm off this weekend and am quite a noob regarding token. However this bug isn't related exclusively to token module so this topic should stay active (likely with another method instead of not calling hook_filter at all) and the reason should be tracked down.

markus_petrux’s picture

Status: Active » Postponed (maintainer needs more info)

When tokens_replace() is invoked, it does not tell anything about the needed tokens, so CCK has no other choice to generate all tokens it provides, and that means filters will be invoked for text fields. We can do nothing about it.

So, I'm not sure to understand the problem in CCK. Could you please clarify?

hefox’s picture

Status: Postponed (maintainer needs more info) » Active

I think he's saying that the filtered the formatted version most call hook_filter on cck values that have a formatted value; content_token_values is a gathering function for all token values. So it looks like it needs to invoke hook_filter to provide a token. (All tokens are provided even if they're not used).

node_token_values would probably also cause the issue if it provided a formatted body token, but it doesn't.

markus_petrux’s picture

Status: Active » Fixed

re: "content_token_values is a gathering function for all token values"

Yes, and this is because token module does not tell CCK which tokens it needs. It just expects CCK to generate all tokens, meaning a lot of stuff depending on the number of CCK fields defined in the system. We can do nothing about it until token module is able to tell token generators which ones are really needed. This is in fact a problem, which is BTW solved in D7, not only because filters could be invoked even when they are not really needed, but also for performance, memory and cpu consumption.

markus_petrux’s picture

Category: bug » support

...as a bug report it would be "by design", just leaving a support request and fixed so it can be reviewed in the issues queue for a while.

Roi Danton’s picture

When tokens_replace() is invoked, it does not tell anything about the needed tokens, so CCK has no other choice to generate all tokens it provides, and that means filters will be invoked for text fields. We can do nothing about it.

Thanks for clarifying that so fast. So this isn't actually a bug but by design and we have to live with it when using D6 unless token is patched. You've saved me a lot of time and headache. :) However hook_filter called by CCK behaves differently since token_replace() isn't executed again. EDIT: Ah, token_get_values() has a recursion check exclusively for content_view().

Status: Fixed » Closed (fixed)

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