This could be a performance problem with complex nodes. Marking postponed until we figure out token generation performance.

Maybe you could use/take a look at the code from the Notify module?
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/notify/noti...
I think the bit under "Helper function to send the notification email." (search for it) is the code that gets the node's body but I could be wrong.

I was looking into using this node as a solution for what I want Drupal to do with newsletters but token + workflow_ng is a much more elegant way of doing things.

Well, you can make a "node body" token in a module that you use and just make sure that it doesn't get executed all the time by putting it into a specific namespace. Take a look at the way that paypalnode does it: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/paypalnode/...

That only gets executed when token_replace is called with "PayPal Node" as the $type which effectively limits the frequency of that code actually firing to the times it is needed. You can do the same thing to avoid this performance problem.

greggles: could this get moved back to the workflow_ng module then? I was sorta asking for a patch for that module anyway.

That's not my module - I can't say. I suggest you submit an issue in its queue.

As a workaround, you can create a field in CCK, called Body and use the token of that field.

just for reference, the workflow-ng issue: http://drupal.org/node/188682

I've "hacked" the token_node.inc file and added the following to the node_token_values function:

and, later in the file, under node_token_list:

I am using the teaser and body-400 tokens and do not observe any performance problems. I need these tokens to allow my users to submit the stories they read to digg-like services.

Here is a patch for version 5.x-1.9.5 with archetwist's solution (added body-100 and body-50 tokens).

Amnon
_{-
Professional: Drupal Israel | Drupal Development & Consulting | Eco-Healing | Effective Hosting Strategies | בניית אתרים
Personal: Hitech Dolphin: Regain Simple Joy :)}

Attachment	Size
token.module-token_node.inc_.patch	2.03 KB

I have the same use case described above (workflow_ng send email to users of a certain role) and also need this capability. Is enough known about the performance of token module to reevaluate this?

Are all values populated each time token is invoked? Is what leads to the potential performance problems?

Are all values populated each time token is invoked? Is what leads to the potential performance problems?

Yes.

Is enough known about the performance of token module to reevaluate this?

I don't believe so.

subscribing. I'd like to use notifications module to email $node->body.

Thanks!

I was looking to do something similar to what grendzy mentioned using workflow_ng to send the body. After looking at the code of token I can see why performance could be a serious issue. That said, the site that I was building has a reasonably small audience and a very small set of people that act as logged in users (most pages are served from the cache) so I decided it wasn't much of a problem.

What I did was take the patch above and drop it into a little body_token module on my site. Token is pluggable so this is easy to add as long as you're aware of the performance risks. I'll attach the D5 version that I made but USE WITH CAUTION!

Attachment	Size
body_token.zip	1.79 KB

@tizzo: Can you please post this as a patch, possibly for D6?

nevermind #15.
#7 is the best short-term solution, and as greggles noted in #2, this would require other performance related improvements to token.

We really need to be able to post Nodes body.
I don't really catch the performance issue, a warning in the documentation would address this concern.

I changed my Token module in D6 as in #7, this is what is needed (just be aware of the plain text transformation effect)

A CCK field is not a solution as it would mean to modify existing node types and messing things between past published nodes and new ones.

This is a old issue...

Some improvement needed for the patch:

If the body contents does not render non-alphanumeric characters.

For example, the following text
"Présentation - Ergonomie"

is received like this:
"<h1>Pr&eacute;sentation - Ergonomie</"

I replaced
substr(check_plain(preg_replace(array('/\<\/p\>/','/\n/'),' ',$node->body)),0,50);
by
substr(preg_replace(array('/\<\/p\>/','/\n/'),' ',$node->body),0,50);

but it does not help much:

"

Présentation - Ergonomie

Pr&e"

I'm using the workaround in #9 and it's working very well. Is there any reason this shouldn't be implemented, at least the shortened versions, or might they also generate perfomance issues?

The reason we aren't doing this is performance.

I don't really catch the performance issue, a warning in the documentation would address this concern.

A warning in the documentation that says "this module, the 3rd most popular one in Drupal, will slow down your site unnecessarily." That just isn't acceptable.

Now, I'm re-opening this because someone could provide a patch for the tokenSTARTERKIT. I'd commit that.

Is performance affected even if the new body tokens are not used?
For example, the "raw user input tokens" have a warning in the code itself, so the user knows when selecting them about possible drawbacks

Yes, it seems hook_token_values() computes values for all possible tokens, without regard to whether they are actually used or not. I don't think that can be changed without changing the API.

Here is something interesting:

adding

to actually made it faster by a tiny, but seemingly repeatable amount.

As a baseline, 10,000 calls to token replace took 7.098 seconds. After adding the above token, it took 6.976 seconds.

This is with a core page node. I haven't benchmarked it with CCK fields yet, but perhaps the performance worries around this issue are overstated.