Address fields or field does not show up in Replacement Patterns (Tokens)

I second this request. I spent a while today digging through the Addresses module's code and trying to improve the token integration for more than just the field display. For example, I tried to work with the Addresses tokens in the PathAuto and Auto_NodeTitles modules but the tokens just don't show up. It seems that the addresses_token_list and addresses_token_values hooks either aren't being invoked or aren't returning anything.

I couldn't spend any more time on this and had to find a different solution for what I was doing. However, I am still interested in seeing this improved.

I agree, this should be implemented.

I completely agree to this feature request.

I looked at the code and did not see any reason for it not to work... for addresses!

I will test a few things, but it looks to me that the $object can only be an address at this point. I think we would need to support a $user and a $node to complement the use of tokens on user paths and node paths. (the node would make use of the CCK and I'm not too sure how that works if you have an array of CCK fields...)

Thank you.
Alexis

Hi!
I have a CCK-field field_address, which contains a Normal or Required fields: Country, City, Street, etc...
I want add a token (such as [field_address_city]) in Automatic title generation. How I can do it?

alexd73,

First of all, if one of the address fields is required in a CCK field address, then all the fields are made required. This is a side effect of using CCK.

I think, from what I understand, that other users have problems with CCK tokens. I did not see any problems, but I'd need to test and see what's happening.

Thank you.
Alexis

At you is normal? What token I should write?

I'm working on fixing this for CCK so I'm sure it will fix it for Patterns and other types that rely on token lists with type 'node'

Here's the patch I promised in comment #8

Currently the addresses module contributes token values only with objects of type
'addresses_general', or 'addresses_adr'

But a lot of contributed modules that support tokens features (Such as the Rules module) expect the object to be of type 'node', or 'user' etc. So that's part of the problem.

The fix for CCK was looking at the following snippet from the content.token.inc:

 //...

      foreach ($type['fields'] as $field) {
        $items = $node->{$field['field_name']};
        $function = $field_types[$field['type']]['module'] . '_token_values';
        if (!empty($items) && function_exists($function)) {
          $token_values = $function('field', $items);
          foreach ($token_values as $token => $value) {
            $tokens[$field['field_name'] .'-'. $token] = $value;
          }
        }
      }

The important bit here is $function = $field_types[$field['type']]['module'] . '_token_values';.

This shows that the content module is looking for a function called addresses_cck_token_values() (there is an equivalent function for the list).

Attached is a patch where these missing functions are added to the addresses_cck module.

It fixes the issue as long as you are using the CCK address fields.

Enjoy,

D

UPDATE: The patch Below has a dsm()... I forgot to remove. I've created a new patch which I will upload shorly

This is the fixed patch from #8

dkinzer,

That would make sense! 8-)

I'll wait a bit to have others test your patch in #9 and if it works for them I'll check it in.

Thank you for sharing!
Alexis

Great! ... Note that the patch on #9 has a rough dsm() call that I forgot to remove. I corrected and reattached the patch in #10.

This appears to currently be returning a definition list for each value, to match other returned token values it should probably only return the value itself.

I don't think it should return HTML code as not everyone will be using HTML email.

realityloop,

Are you saying that the patch transforms things in a way that prevents plain text emails?

I thought we could use the tabs and depending on the type adjust the output. I suppose that the Addresses code should test that type and adjust the content accordingly. But I'm not a master at CCK...

Thank you.
Alexis Wilke

It is not the case that these fields are not accessible as plain text.

In fact there was no way of accessing the individual fields without going through the Addresses module's theme function (it has nothing to do with how CCK asks for tokens). However, as shown below all the token fields are indeed returned in plain format as well as hcard format. In fact I used the plain formatted output to generate a non HTML email.

CCK addresses tokens
[node:field_ask_address-is_primary_plain] "False" if the checkbox is not checked, otherwise "True".
[node:field_ask_address-is_primary_hcard] An hcard/vcard html representation of the primary checkbox.

Alexis: no, but when using htmlmail module the fields are returned as dt & dd which is not consistently controllable with the limited CSS that HTML emails allows.

Dkinzer: I'm using the _plain variant for all of my fields but the output in the received email has the dt & dt tags around field title and field value.

The patch works, but some tokens seem odd to me. Like First Name and Last Name show both the label and the value. Will additional tokens be added to we can just use the values?

@butler360, either the Addresses module has to be modified so that it doesn't force us to go through it's theme functions in order to retrieve these fields, or we need to add a 'cck' type theme format to the Address module that returns a true simple, plain field value [which really should happen when one asks for the plain format].

The latter is the easiest solution. So I'll do that and post the new patch when I get a chance.

I agree about the "plain" stuff, and thanks!

OK so there was an extraneous foreach statement that was erasing the plain format output. I've removed it and attached the new patch.

Oops, that patch on #20 is unnecessarily cluttered. :) I'm resubmitting it here

Ugh, that was the wrong patch, sorry. Here it is again.

This works well, can we get a plain version of the Business field as well though?

realityloop, what's the business field? I'm looking in the addresses module and it's not defined. Perhaps it's being defined by another module, like the phone field is?

//...
function _addresses_addressesfieldapi_form($fields = array(), $values = array()) {
  $field_weights = variable_get('addresses_field_weight', array());

  // Let users select if the address is the primary
  if (!empty($fields['is_primary'])) {
//...
    );
  }

  // Adds the Address Name (Home, Office, Rio de Janeiro...)
  if (!empty($fields['aname'])) {
//..
    );
  }

  // Adds the Country
  if (!empty($fields['country'])) {
//...
  }

  // Adds the Province field
  if (!empty($fields['province'])) {
    $form['province'] = /...
    // If country field is displayed then use AJAX
    // See addresses.js
    if ($form['country']) {
      //...
  }

  // Adds the City
  if (!empty($fields['city'])) {
//...
    );
  }

  // Adds the Streets and the Additional fields
  if (!empty($fields['street'])) {//..
    );
    if (!empty($fields['additional'])) {//..
  }

  // Adds the Postal Code
  if (!empty($fields['postal_code'])) {//..
  }
//...
}

//...

Ah! Good catch. The business field is part of the Addresses Extras module.

Ah, my bad.. then I'd say it's safe to mark #22 as RTBC.

AlexisWilke: I had a look at the source for Addresses Extras but couldn't figure out how to add plain versions there, would be nice to see this included in it if possible? I've created an issue for it http://drupal.org/node/972718

Okay, #22 is checked in the 1.x-dev version. Thank you!
Alexis

cool. Thanks.