Tokens not returning data

Hi,
Shouldn't the tokens be with a - instead of a _ so it becomes [message:message-commerce-order:field-order-comments]
Just my thoughts about this..

EDIT @MrPeanut I do not get tokens to show like you. Could you tell what versions of depending modules you have please

Greetings, Martijn

Similar problem based on a custom field attached to the product entity.

[message:message-commerce-line-item:commerce-product:field-stock-location]
[message:message-commerce-line-item:commerce-product:field_stock_location]

Ref #3 my understanding is that hyphens are used in regular tokens and underscores in entity tokens

Either way, neither are are working for me.

Hi,
May be for the custom fields you need to alter a rule and at a Condition Entity is of type ...with it?
Greetings, Martijn

Some success. The following token works, also based on a custom field but this time attached to the customer profile

[message:message-commerce-order:commerce-customer-billing:field-commerce-phone-number]

So, some tokens are working but others are not.

Earlier in my project I had a problem where custom product fields could not be made available to rules. Could this be related?

Ref #5 I am unsure of the connection between rules and commerce_message. Can you explain?

Are you saying that need to scope-in the token via the rule that triggers the message?

Seems like [message:message-commerce-order:...] returns data, but i'd love to see a way to get [message:message-commerce-line-item:...] to return data as well, as that's where all my custom product fields are.

After following some comment trails from a "!order-summary"+"commerce" search, i've found the best work-around to be modifying the !order-summary portion of the email through the "Shopping cart summary (Commerce Order)" view. It seems to support relationships, and so the custom product fields show up in the confirmation email.

i am using Commerce Kickstart, so maybe this was all neatly pre-packed, but hey, i'm happy.

I'm seeing the same issue on my end:

[message:message-commerce-order:commerce-customer-shipping:commerce_customer_address]

doesn't work. Has this been resolved?

All I need to do is display the shipping address. Any ideas here?

O.k. Weird. I've just run a handful of updates and will try it out again.

I am having this issue to. Strange thing: On my local development server it works, live environment it does not.

@kvoltz -- What php version do you use?

OK thanks,

I could also only use the global tokens and not the detailed tokens where you could select for example only the locality.

So these are the only tokens that work for me:

[message:message-commerce-order:commerce-customer-billing:commerce_customer_address]

AND

[message:message-commerce-order:commerce-customer-shipping:commerce_customer_address]

@maxplus Your token worked for me as well. Earlier I had no problems with [message:message-commerce-order:commerce-customer-billing:commerce-customer-address:?] as listed in the replacement patterns on the message type page. Since the addressfield module last update it didn't show on the email anymore. No errors in watchdog but checking logs of my (hosted) server I found a problem: ModSecurity: Warning. Pattern match ".*" at ARGS_POST:op (way beyond my technical knowledge).

Also I had to manually set the default country in the customer profile types.
Hope it helps someone.

Cant get any of the tokens to work. Only the default, prefilled ones. But no other.

Confirming... very few tokens work making this module pretty unusable.

@jeff.harman If any help, I ended up replacing my custom (boolean) field with a taxonomy term. I was then able to use commerce_rules_extra to quiz the term and fire my rule.

For me the solution in the latest stable version was to replace
[message:message-commerce-order:commerce-customer-billing:commerce_customer_address]

with

!{message:message-commerce-order:commerce-customer-billing:commerce_customer_address}

(Use ! / @ / ... like with the t() function, ! if containing HTML, ...)

Until the latest update normal tokens like above (first example) were working...

First off:
Underscores = Default Token
Dashes = Entity Token
(Someone mentioned they thought the reverse of those was true)

Second

Pretty much the ONLY tokens you'll find that work, are [message:message-commerce-order:*] tokens.

This was the same problem I ran into when trying to deal with a generic rule that would fire off an HTML email. No tokens outside of "order" will work. (Dashes work... Underscores do not. Didn't try suggestion from #19)

From my understanding, everything works in a downward flow, therefore "line-items" are before the "order", so you can't see the individual line-items, without looking at the actual order, just like you can't look at payment line-items without looking at the order. Only the line items within the "order" are going to be visible. I'm guessing there's a lot of backend hackery code that would have to happen to make the line-item tokens work the way we expect, but that's over my head. Ideally, the only exposed token would be the order token and line-items would properly work and live within it. "Give us order:line-item tokens that work and we'd all be happy amirite?

At least with the super hacky message / message notify / commerce messages route, a field (Order) is added to the message which you can un-hide from the message email-body view mode on the display tab, then point it to the rendered entity, then point it to the "Tokens" view mode. (After you enable tokens view mode on the order entity display)

From there, you have to edit the "Line Items" view (yes, view... as in Views), clone the "Line Items" view and tweak to your liking. If you're happy with the default line-item view, then you're good to go. Just make sure you turn off "Contextual Links" from the view, otherwise you end up with an "Edit view" link in the email... I personally recommend cloning the view and tweaking it because it will most definitely show up as a view to choose for the order display Line Items.

Like the rest of you, I "wish" the other tokens, just worked... It would make ALL of our lives so much easier. If the tokens actually worked like we all expected, we could have just cloned the checkout complete rule that fires when a customer completes an order, added a few "admin" related tokens, changed the email to our liking and been done with it. Oh, and not need 3 other modules to do what should easily be available through core. But I digress... That's what we get for living in the world of Drupal where everything is needlessly complicated :)