Posted by lordgilman on October 7, 2007 at 8:24pm
| Project: | Token |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
Could there be a token implemented that would output the body of the node? I'm looking to use it in the "send to an arbitrary mail address" action when a node is created.
Comments
#1
#2
This could be a performance problem with complex nodes. Marking postponed until we figure out token generation performance.
#3
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.
#4
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.
#5
greggles: could this get moved back to the workflow_ng module then? I was sorta asking for a patch for that module anyway.
#6
That's not my module - I can't say. I suggest you submit an issue in its queue.
#7
As a workaround, you can create a field in CCK, called Body and use the token of that field.
#8
just for reference, the workflow-ng issue: http://drupal.org/node/188682
#9
I've "hacked" the
token_node.incfile and added the following to thenode_token_valuesfunction:<?php$values['teaser'] = check_plain(preg_replace(array('/\<\/p\>/','/\n/'),' ',$node->teaser));
$values['body'] = check_plain(preg_replace(array('/\<\/p\>/','/\n/'),' ',$node->body));
$values['body-200'] = substr(check_plain(preg_replace(array('/\<\/p\>/','/\n/'),' ',$node->body)),0,200);
$values['body-400'] = substr(check_plain(preg_replace(array('/\<\/p\>/','/\n/'),' ',$node->body)),0,400);
?>
and, later in the file, under
node_token_list:<?php$tokens['node']['teaser'] = t('Node teaser');
$tokens['node']['body'] = t('Node body');
$tokens['node']['body-200'] = t('First 200 characters of a body');
$tokens['node']['body-400'] = t('First 400 characters of a body');
?>
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.
#10
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 :)
#11
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?
#12
Yes.
I don't believe so.
#13
subscribing. I'd like to use notifications module to email $node->body.
Thanks!
#14
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!
#15
@tizzo: Can you please post this as a patch, possibly for D6?
#16
nevermind #15.
#7 is the best short-term solution, and as greggles noted in #2, this would require other performance related improvements to token.
#17
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...
#18
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é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"
#19
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?
#20
The reason we aren't doing this is performance.
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.
#21
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
#22
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.
#23
Here is something interesting:
adding
<?php$values['content'] = node_view($node, FALSE, TRUE);
?>
<?phpnode_token_values()
?>
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.
#24
But using %body in a "normal" mail doesn't? I really need to send the node's body AND some fields I only get through tokens.
#25
Subscribing.
I'd love this feature as well. I think that if there were some sort of a warning message in the Token Replacement list. Maybe even put it in it's own category with a warning at the top too. I just think that if anyone's going to use it then it will be a unique situation. If they know that it is a resource hog then they will think twice. It could also be an extra token module that would have to be enabled..... either way the option needs to be there for people like us.
EDIT: just realized that at least one other person mentioned the same thing at the bottom of this post. Sorry. :)
#26
I've gone and just created a new module called token_body that will accomplish this for me. Attached is the 6.x version for anyone that wants to use it. Again, be warned that this is not ideal for many situations due to the server overload. Please use with caution.
#27
Amariotti,
Thanks for this module in #36. It seems to be the only hope for sending out an html body using mime mail actions.
I've installed it and I am trying to use it with Rules and Mime mail. It shows up in the token list and I am able to insert it into the body of the message, but its missing in the resulting emails (the other tokens show up). Any suggestions on how to troubleshoot it?
#28
Strange enough that feature does not appear to be a huge issue.
How do Drupalers send newsletters or significant emails to subscribers without the ability to process the nodes' Body?
For the time being, I tweak the module by adding the corresponding lines (#9, #10). I would plan to test this module as well, but there seem to be a very low interest in this...
#29
Related: #743950: Rendering a node in a token
#30
Hello,
I also wrote my own module to provide $node->body and $node->teaser tokens, in four different formats :
- HTML checked (like comment-body is, with check_markup())
- raw
- HTML escaped (with check_plain())
- HTML stripped (with PHP's strip_tags())
Module for 6.x is attached. Will accept suggestions, and maybe create it as a new project here.
Regards,
David
#31
#26 does not work: tokens are created and appear in lists, but return only their name
#32
This is not working for me. I see it on the list, but when I create a page, for example, it does not send the node body. It doesn't sent the token text either ([node:body]), and it seems to occupy space in a line up of different tokens so it seems to be processing something....?
I desperately need this to work. I am on 6.19, using this module you have here, and the most current version of the token module (6.x-1.14).
I have tried it on two different sites (one with 6.17).
#33
this being #14 patch... :)
#34
Subscribing.
#35
I need this too... for messaging (http://drupal.org/project/messaging) templates.
#36
@soulfroys: install notifications (which is by the same author as messaging), and enable notifications_content module. It has body tokens.
(I don't know why he decided to put the token generation in notifications_content instead of messaging... that situation will probably be rectified sometime...)
#37
Oh! My bad... Thanks @roderik!
#38
+1
#40
Subscribing
#41
#30 was working for me. Thank you. Now, I need solve how to add comment body.
#42
My fault for not checking back here. After that post I changed jobs and got really busy so haven't come across it until now. Sounds like #30 is a good alternative. Hopefully this can become it's own project.
#43
Subscribing
#44
subscribing
#45
+1
#46
sub
#47
+1 #30!