I am using Rules to notify editors when users post new/updated content. When the email goes out and I include some node fields in the message, any fields that are blank in the node do not display properly -- they show the actual replacement pattern, not blank text.
For example, here's an excerpt from a Rules-sent email:
Category: [node:field-rostercategory]
Name of Business: Test Business
Name: Johnny Q
Title: Owner
Phone: 123-456-0828
Website: [node:field-website]
Revision Log: [node:log]
I have yet to see any documentation saying this is by design (nor does it seem functionally beneficial) so I'm listing this as a bug.
I'm using Rules 2.1 on Drupal 7.14 (tho I had same issue with 7.12). Thanks to everyone involved in making this amaaazing module-- tho if someone could look into this small bug, that would be awesome.
Comment | File | Size | Author |
---|---|---|---|
#19 | rules-token-evaluator-handles-empty-values-1559844-2c.patch | 457 bytes | fluffy |
#3 | rules-token-evaluator-handles-empty-values-1559844-2b.patch | 481 bytes | DRippstein |
#1 | rules-token-evaluator-handles-empty-values-1559844-2.patch | 469 bytes | DRippstein |
Comments
Comment #1
DRippstein CreditAttribution: DRippstein commentedDetermined cause and possible fix for the problem. Renamed issue to be more specific.
Rules' token evaluator is made to closely mimic the 'token_replace' function of the official token module. Except for three lines... these (if a "clean" option is passed) replace blank tokens with a '' (empty string).
This patch will add a line with similar functionality, though it doesn't check for options. It will prevent Rules emails from sending raw token patterns. But I don't know enough to say why this check is an "optional" thing at all. Is there some Token functionality that requires blanks to remain raw token patterns? Or specifically, is there something in Rules that does? If so, how could we pass an option? If we don't need it though, this little patch should do the job.
Comment #3
DRippstein CreditAttribution: DRippstein commentedThis is what happens when I hand-code a patch...
Comment #4
DRippstein CreditAttribution: DRippstein commentedYes, test-bot... and fix category too. Don't even know.
Comment #6
emptyvoid CreditAttribution: emptyvoid commentedWell I just wanted to confirm I am experiencing the same issue.
I have an entity where I have optional fields, if the author doesn't enter a value the token is displayed within the email. This is just messy and not desired.
Comment #7
emptyvoid CreditAttribution: emptyvoid commentedThe template-based email actually involves three different entities.
1) User
2) Order
3) Line Item
I'm sending an email to a customer after purchase of the specific product (I'm using Drupal Commerce).
Comment #8
doana CreditAttribution: doana commentedThis issue was affecting me as well. @DRippstein's patch in #3 (applied manually) worked wonders for me.
Thanks!
Comment #9
Morten Najbjerg CreditAttribution: Morten Najbjerg commentedYep - #3 patch does the trick for me too.
Comment #10
emptyvoid CreditAttribution: emptyvoid commentedConfirmed, applying the one line addition fixed the empty token being displayed in all emails and messages.
Comment #11
Sinan Erdem CreditAttribution: Sinan Erdem commentedPatch on #3 also works for me. Can it be commited?
Comment #12
emptyvoid CreditAttribution: emptyvoid commentedPlaying devil's advocate, I could see having the tokens printed out within the email as useful for debugging a token and the evaluation of the token in a given display. That being said, I think it would be great if this behavior could be controlled, say on a configuration screen for tokens. "Enable display of empty token placeholders" defaulted to "off".
Then we'd just have to add this field value to the default settings for the token module. Add a check before the code that removes all empty tokens during evaluation.
Still, I second that this should be committed to the branch.
Comment #13
fagoI've added a comment and committed #3. Feel free to work on a follow-up for making it configurable. Maybe as part of a general rules debug mode setting?
Comment #14
brephraim CreditAttribution: brephraim commentedStill getting this after the patch in #3:
[message:message-commerce-order:commerce-customer-shipping:commerce_customer_address]
Comment #15
GiorgosKI just tested the latest dev which includes the patch
and it does not output the tokens when fields are empty
please brephraim try the dev instead of the patch and report back
(maybe your problem is commerce related ? try upgrading to latest commerce)
Comment #16
joshmillerI confirmed with Commerce that problem exists without the patch and the problem is fixed with the patch. Both for Send system mail and Display a message. I think it's more likely that an error is happening based on the event and available variables.
So, bephraim, I recommend you open a Q&A on drupalcommerce.org for support and provide more details.
Comment #18
jonne.freebase CreditAttribution: jonne.freebase commentedI upgraded the rules module to the latest -dev (7.x.2.2+5-dev) and I still see raw tokens in the e-mails sent out by dc commerce. Anyone else still have this issue? Is there something else i should do after upgrading the module?
Comment #19
fluffy CreditAttribution: fluffy commentedThe patch in #3 can't be applied because the file identifiers are wrong, here is the fixed patch, it works nicely.
Comment #21
MatthijsG CreditAttribution: MatthijsG commentedThe last patch didn't work for me :-( Empty tokens are still displayed in the mail.Edit : i forgot the save button ;-) The patch is working fine.
Comment #22
GiorgosKI see #19 included in the latest dev
anybody else confirms ?
EDIT wrong thread text included
Comment #23
FreeFox CreditAttribution: FreeFox commented#19: rules-token-evaluator-handles-empty-values-1559844-2c.patch queued for re-testing.
Comment #25
josephanoop CreditAttribution: josephanoop commentedI installed rules 7.x-2.2 version and applied this patch. I configured rules to send mail with 'entity forms' submissions. But for empty values i am getting the token names. eg: Contact Number : [entityform:field-contact-number].
Any solution to fix this?
Comment #26
GiorgosK@josephanoop
try latest dev and report back
Comment #27
josephanoop CreditAttribution: josephanoop commentedThe latest dev version solved the issue, thanks!
Comment #28
pipepiper CreditAttribution: pipepiper commented#3: rules-token-evaluator-handles-empty-values-1559844-2b.patch queued for re-testing.
Comment #29
zionduc CreditAttribution: zionduc commentedI tried the latest stable (7.x-2.3) and dev (7.x-2.x-dev) versions but I do not see change in this - so I still see tokens in the email.
I use commerce_email to sending emails.
Comment #30
MickL CreditAttribution: MickL commentedsame for me, using commerce_email. empty fields still showing the token.
Comment #31
Summit CreditAttribution: Summit commentedHi,
May be this helps using commerce_email: http://drupal.org/node/1440236#comment-6057672
Greetings, Martijn
Comment #32
MickL CreditAttribution: MickL commentedno i dont get helped there. by the way the patch from #19 is already applied to latest dev with no effect:
system.eval.inc, line 183:
Comment #33
ciss CreditAttribution: ciss commentedI'm sorry, but this is wrong. The reason you're seeing no effect is likely because you're sending mails e.g. via variable_email. I've added the line to _variable_email_evaluate_token() and it does in fact replace empty tokens.
In my opinion the deeper issue here is that I've already come across two modules (variable_email and rules_mail_edit) that copied portions of RulesTokenEvaluator::evaluate() into their own code.
RulesTokenEvaluator::evaluate() could easily be declared static, allowing other modules to call it for token replacement.
Comment #34
xatoo CreditAttribution: xatoo commented@ciss, for your info: The 1.x-dev version of variable_email already uses the RulesTokenEvaluator class for token evaluation. See #1682730: Use standard rules token evaluation.
@MickL, are you using variable_email and does updating it to 1.x-dev fix your problem? Or, if not, what other modules do you have that are involved in sending email?
Comment #35
ciss CreditAttribution: ciss commented@xatoo Yes, i noticed it after posting the above response. I replaced variable_email alpha with the dev version, with the result that tokens no longer got replaced. Digging further I noticed that $element->settings['variable:process'] was undefined (I tested with an already existing rule, using rules-7.x-2.3+3-dev).
Where can I find documentation on how RulesTokenEvaluator is supposed to be implemented?
Comment #36
Summit CreditAttribution: Summit commentedHi, still having commerce-customer-billing tokens not replaced. Using variable_email 1. Alpha. Does this post on #34 has to do with it?
Greetings, Martijn
Comment #37
akalata CreditAttribution: akalata commentedUpgrading to variable_email-7.x-1.x-dev as recommended by #34 breaks ALL tokens used with commerce_email -- kinda the opposite of what we need to accomplish! I know it's not really relevant here, but wanted to point any other variable/commerce users over to #1759140: Token API change in dev needs documentation and maybe an own branch.
Comment #38
Summit CreditAttribution: Summit commentedHi,
Yes latest variable_email breaks all tokens! Still no solution!
Also no solution for empty tokens... anyone please?
EDIT: Sory didn't want to hijack this rules issue..only responding to latest remark.
greetings, Martijn
Comment #38.0
Summit CreditAttribution: Summit commentedGrammar change.
Comment #39
kevster CreditAttribution: kevster commentedMany thx @ciss - post #33 - I added
$replacements += array_fill_keys($tokens, '');
to variable_email.rules.inc after line 136 and that fixed my issue with tokens printing out if they are blank.
using variable_email alpha1 (not latest dev)
Comment #40
NancyDruThe patch in #19 seems to be in 7.x-2.10, yet I am still seeing tokens in my email when there is no value for a field.
I am not using variable_email, but we are using a similar concept.
And, to be precise, it is not happening when the field is blank; it is when the field is NULL, and therefore not written to the DB.
Comment #41
NancyDruComment #42
TR CreditAttribution: TR commented@NancyDru: The previous 39 comments all indicate that this was fixed long ago by the patch made to Rules or the patch made to variable_mail or some other way.
Sorry to shut you down after you've been waiting a year for an answer, but it's not helpful to reopen the issue at this point because your situation is certainly something different, yet the only details we have are from the old fixed issue.
If you're still having this problem, feel free to open a NEW issue with details about how to reproduce the error you're seeing. It would help if you would stick to core Rules and reduce the problem to its simplest terms rather than involving lots of other complicated non-Rules modules like others have done.