Tokens not working in Rules email field

Hmm, in the first case, do you send the email to 2 "to" addresses? In that case it might just work because the order:email token is correct and the other is also empty. Can you somehow verify via a dump or watchdog log that the webform token is in fact working in the first case and not in the second case (i.e. if it has a value).

On top of that, can you check if other webform tokens work at the same stage - it might be that you're not using the correct token syntax (it's a bloody mess in D7, so I really don't know anymore what is the right syntax). Basically, if the tokens work say in the invoice screen (when you add them to the template of course) and not in your custom code, then it must be the custom code that has an issue I would say.

well.. the whole token system is buggy as hell in D7 and I really don't want to get into that mess. I'm pretty sure the tokens are defined correctly by the module and work.. so not sure what's going on. I'll double check that they are though, but other than that it's just the whole release process in D7 that's a complete joke tbh *rant end*

This is a very weird one indeed.. was able to reproduce it (yay). Will try to fix, must be something wrong with the way tokens are defined..

Hi there,

I was wondering if someone from Rules could help out with this issue - the problem that seems to appear here is that when tokens are used in the email field of a "Send mail" rule, some weird stuff happens.

In particular, using "[order:email], uc-webform-80-attendee-email" replaces both the actual Ubercart order email and the Webform field called "attendee-email" from a Webform checkout pane. Interestingly, I don't even get why this is the case, as the latter is not a correctly formatted token, "[order:ucwf_80:uc-webform-80-attendee-email]" is.

Furthermore, if just "[order:ucwf_80:uc-webform-80-attendee-email]" is specified, the system tries to send an email to "[order:ucwf_80:email@host.com]". But if "uc-webform-80-attendee-email" alone is specified - it's not replaced at all...

Also, the webform tokens are not available through the data selector, any reason for that?

Please let me know if I can provide any further details etc.

Thanks!

Sounds like a problem I recently experienced when I upgraded the rules module from 2.2 to 2.3.

In our ubercart setup (3.4), a customer receives an order confirmation email after they place an place an order.

We've also set up a rule that sends an email to the customer when their order is shipped out. The email contains the tracking number and carrier.

After I upgraded the from rules 2.2 to 2.3, the initial order confirmation email was being sent but shipping emails weren't being received by the customer.

Looking in the logs, I could see that the rule was still being executed and there were no errors but the email never reach the customer.

I tried rebuilding the Rules cache and rechecking their integrity but it didn't have any effect.

Out of curiosity, I edited the the shipping email rule to send include my address as well as the customer's, the customer's being defined with the token [uc_order:email]

I then triggered the rule and received the shipping email. Interestingly, any information in the message that would have been provided by a token (order number, tracking number, carrier) was missing.

I reinstalled rules 2.2 and the shipping emails went back to behaving normally.

As Rules 2.3 is a security update, it would be prudent to go back to using it asap however I can't until I revolve the tokens in the email issue.

Any thoughts?

@smiklos: In your shipping rule, you might need to use [order:...] for the token prefix instead of [uc_order:...].

This is due to #1559844: Field token is not replaced when fields are blank which means that any tokens that Rules doesn't understand now get stripped before Ubercart's email action has a chance to replace them.

I can confirm that Rules-2.3 (#1559844: Field token is not replaced when fields are blank specifically) introduced this issue as well.

In 2.2, the string "Email: [custom:email_address]" would be output as "Email: [custom:email_address]".
In 2.3, the string "Email: [custom:email_address]" would be output as "Email: ".

Any modules that needed access to [custom:email_address] at a later point during processing (for example a module that use hook_rules_event_info() to replace tokens that were not available during the first replacement of tokens) no longer have access to it.

I believe this is because of line 185 in /rules/modules/system.eval.inc:

$replacements += array_fill_keys($tokens, '');

A 'filter unknown tokens' checkbox to toggle line 185 in /rules/modules/system.eval.inc would solve this issue, as well as the issue introduced in #1559844: Field token is not replaced when fields are blank

I think this leaves several contributing modules (specifically those that also use tokens) in a broken state.

Commenting out line 185 in /rules/modules/system.eval.inc (against Rules version 7.x-2.3) keeps the tokens from being obliterated.

Change:
$replacements += array_fill_keys($tokens, '');

To
//$replacements += array_fill_keys($tokens, '');

As noted in #9 this change in Rules can and did break contrib modules; Ubercart performed its own token replacement after Rules did its part, but now tokens are stripped this functionality became broken. This was fixed in #1970444: A change in Rules broke various notification emails to allow Rules to replace all tokens, however I can see that some modules may still want to do their own token replacement after Rules has done its work.