Token replacement does not work. Not sure if it only impacts certain combination of modules, occurs when using addressfield, entity_token, and token (locale not installed). The cause appears to be a mismatch in the language code which is set to "en" from $options but the address field is using LANGUAGE_NONE ("und"), as noted in issue #3013566-34: New version doesn't print tokens anymore.
Get the language code from the entity instead of options as done in patch for multi-value issue #2679579: Token values unavailable for multi-value address fields
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | addressfield-wrong-language-code-3082673-6.patch | 897 bytes | ciss |
| #5 | language-code-incorrect-3082673-5.patch | 674 bytes | lwalley |
Comments
Comment #2
lwalley commentedComment #3
lwalley commentedComment #4
lwalley commentedOn second review using language code from entity in the absence of the multi-value patch in #2679579: Token values unavailable for multi-value address fields is probably effectively the same as just setting language code to LANGUAGE_NONE so probably isn't the right choice here. It doesn't solve the root issue which is that $options is "en" but address field array index is "und". Further investigation is needed.
Comment #5
lwalley commentedNew patch, also doesn't solve the root cause but at least only changes the language if it isn't supported by address field.
Comment #6
ciss commentedI'd like to offer an alternative solution that explicitely checks if the field in question is translatable. I've left patch #5 visible so that both solutions can be compared.
Comment #7
ciss commentedNote that these patches still don't handle entity translation. In another project that uses entity translation we ended up patching out addressfield.tokens.inc completely (possible because we already use the entity module and don't rely on underscore field tokens).
Comment #8
tintoPatch #5 solves the issue for me