New version doesn't print tokens anymore

I am having the same issue.

It should be safe to revert while we debug.

Can y'all confirm that you are not using the Token module on your sites? Also, can you confirm that reverting to 1.2 fixes the issue? The only relevant change that comes to mind is #2416997: Statically cache the list of address fields during token generation.

This fixes the issue for me and also makes the change in #2416997: Statically cache the list of address fields during token generation a smaller one.

Hm... that's weird, In that case, there's no need for the loop foreach (array($field_name, strtr($field_name, '_', '-')) as $name) {, but did you do some tests with / without the token module?

In the end, we still alter the $data['tokens'][$group][$name] array although we check for the $field_name key...

@vibrasphere: Can you check if the token module is enabled on your install?

So you're having issues with the token name that has dashes? ([commerce-order:commerce-customer-billing:commerce-customer-address:name-line]).

Because I'm trying that and it works for me... But it actually doesn't when the token module is disabled.

I did several tests and here are my findings:

Without the code in addressfield_token_info_alter(), printing the token [commerce-order:commerce-customer-billing:commerce-customer-address:name-line] (with dashes) returns "Array".

With the code, if the "token" module is enabled, both [commerce-order:commerce-customer-billing:commerce-customer-address:name-line] and [commerce-order:commerce-customer-billing:commerce_customer_address:name-line] work.
However, in the current state, printing [commerce-order:commerce-customer-billing:commerce-customer-address:name-line] when the token module isn't enabled doesn't return anything, the reason for that is that we change the token type from "struct" to "address-field".

If we keep the type to "struct", the "entity_token" module is actually in charge fo the token replacement...

So we actually have two options:

1. Skip addressfield_token_info_alter() completely when the token module is disabled.
2. Make sure the token replacement work properly in addressfield_tokens() both when the token module is disabled / enabled.

The attached patch is making sure the token replacement is performed by the Addressfield module, both when the token module is enabled / disabled.

@vibrasphere: Could you apply the attached patch, clear caches and make sure it works for you?

Yeah, the reason for that is that you're using administrative_area and not administrative-area (if you want the state code you can use administrative-area-raw).
Same with the zip, you're using "postal_code" instead of "postal-code".

Basically, when Addressfield doesn't alter the token type to "address-field", when it's "struct", the token is handled by the "entity_token" module.

With the patch, Addressfield is handling the tokens for both "commerce-customer-address" and "commerce_customer_address" but the field name (postal-code, etc.) always has dashes....

We could probably expand the patch to support both "-" and "_" for addressfield field names, but I'm not sure that's the way to go.

@vibrasphere: Could you test now with the attached patch? It should now both support postal-code and postal_code.
I don't really understand all those inconsistencies... but well... Since many people are probably printing both, let's support both.

Yeah, the reason for that is that you're using administrative_area and not administrative-area (if you want the state code you can use administrative-area-raw).
Same with the zip, you're using "postal_code" instead of "postal-code".

thank you for the explanation.

We could probably expand the patch to support both "-" and "_" for addressfield field names, but I'm not sure that's the way to go.

I think this will ensure that existing project won't break.

ps Here I don't use entity_token neither addressfield_tokens

I'm having the same issue with this latest update, however this patch doesn't seem to solve the issue.

I am using Entity Tokens also, and have cleared the cache multiple times.

@tyler-durden: Could you describe exactly what's not working for you? Which tokens are you trying to print etc? That'd allow us to replicate the issue.

I reapplied the patch and it seems to be working now. I must have done something wrong with the initial patch update.

@Tyler are you sure you have only reapply the patch?

The patch was working for me but not anymore.

I try to use the following tokens on Metatag user og description:
a[node:field_addresse:country]
b[node:field-addresse:country]
c[node:field_addresse:country-code]
d[node:field-addresse:country-code]

no results.
same issue with locality.

Patch #18 applied cleanly against 7.x-1.3 and re-enabled the tokens.

Thank you @jsacksick.

Committed #18. Thanks, everyone!

Changing the underscores to hyphens throughout fixed the problem for us - with token module installed. 7.66, all modules current.

I still have another issue with this. The tokens are correctly displayed within devel token in any node, but printed empty in the node's metatags.
It seems to be an language error related. I have the module locale enabled, with only english language.

to fix my issue I replaced in function addressfield_tokens

  if (isset($options['language'])) {
    $language_code = $options['language']->language;
  }

with

  if (isset($options['language']) && $options['language']->language != 'en') {
    $language_code = $options['language']->language;
  }

This is definitely not fixed!
With 7.x-1.2 tokens are working correctly in metatags, in 7.x-1.x-dev and latest stable release 7.x-1.3 they are broken. I'm for example using:

• [node:field-address:thoroughfare]
• [node:field_address:thoroughfare]

in a single value field which outputs the correct value testing with 7.x-1.2 and outputting NOTHING in metatags with latest 1.3 and dev.
There are several follow-up issues, I'll reply there if one of the patches fixed the problem for me. But this should definitely be fixed with a new stable release.

Follow-Ups / related see:

• #2679579: Token values unavailable for multi-value address fields
• #2679014: Token in metatag causing undefined index error
• #2557899: address_field token description seems to be incorrect

Thank you!

Reverting back to 7.x-1.2 now, because I couldn't find a solution... The other issues seem unrelated in my case.

@anybody I can confirm that downgrading from 1.3 to 1.2 fixed the issue regarding tokens being output in metatags. Specifically I'm adding job posting schema to a jobs section on a website and need each part of the address to be output as the components of the address in the schema json. I'm not using any custom code, I'm using the schema metatag module.

During testing on version 1.3 of this module I took a look at the token display of the job content type and noticed it was in the disabled region. I thought that this may have been the cause of the missing tokens (always check the token display!). I enabled it and saw SEVERAL options for outputting as either default, individual components separated by a delimiter, just the country name etc... I selected default. Still nothing. Selected the other options, nothing.

I then downgraded to 1.2 and found that using the hyphenated tokens e.g. [node:field-address:thoroughfare] worked for the components of the address:

"jobLocation": {
                "@type": "Place",
                "address": {
                    "@type": "PostalAddress",
                    "streetAddress": "Portland Street",
                    "addressLocality": "Manchester",
                    "addressRegion": "Greater Manchester",
                    "postalCode": "M1 6DF",
                    "addressCountry": "United Kingdom"
                }
            },

Unfortunately [node:field-address:country-code] does not work (it did for a brief second but not now). So:

1.2 has a single option for the token display and works and 1.3 has several options for the token display and doesn't work with metatag.

workaround for token

file addressfield.token.inc:
1) apply patch #18
2) add this code in line 132 in function addressfield_tokens

[...]
$sanitize = !empty($options['sanitize']);

+ if($type=='address-field') {
+ if(!isset($data['address-field'][$language_code])) {
+ $language_code = LANGUAGE_NONE;
+ }
+ }
$replacements = array();

New issue created for the incorrect language code see #3082673: Language code incorrect in token replacement.

The code in #34 using 7.x-1.3 seems to have fixed my issue with metatags. Added it to line 116, not 132.

Patch #18 fails for me. Also, I haven't had issues with pathauto tokens, only metatag.

Unfortunately the changes in this issue effectively cripple token replacement via the entity module, without offering a proper replacement (pun intended), especially in multi-language environments. Imo it should be reevaluated to what extent addressfield is even responsible for replacing tokens.

A short refresher on how field tokens get replaced:

• Field tokens that use dashes are implemented by the entity module. They use entity_metadata_wrapper() and the corresponding API to retrieve and display values.
• Field tokens that use underscores are implemented by the token module. They are rendered via field_view_field() with the "token" view mode.

I'd argue that addressfield should at the very least leave any dash tokens alone, and only try to handle underscore tokens.