I needed the ability to use the city/country tokens from an address field so I added in tokens support through the use of hook_token_info() and hook_tokens().

It's not been tested extensively (I'm only using the city and country tokens, and I'm not familiar with the others, I just added what I saw listed in addressfield_data_property_info), but I thought it may help get the ball rolling.


inolen’s picture

new5.52 KB

Doh, patch didn't attach.

darioshanghai’s picture

Thanks! sub.

Damien Tournoud’s picture

This looks like a good idea, but those tokens probably need to be sanitized when necessary.

Damien Tournoud’s picture

Status:Needs review» Needs work
kruser’s picture


kehan’s picture


jenlampton’s picture

Also, they should probably be a child of the field they belong to, not a whole separate type. I'll see if I can clean up the patch a little.

jenlampton’s picture

Title:Tokens support (patch attached)» Country token support (patch attached)
new4.16 KB

Okay - this is simplified down to only include tokens for country-code and country-name, but they are actually children of the addressfield fields now, on whatever entities they may appear on.

I don't believe these values need to be sanitized since they are not user input, but correct me if I'm wrong.

If these tokens are suitable we can add additional ones for the other address field values. I only needed country for my use case, but I think this might be a good starting point.

jenlampton’s picture

Status:Needs work» Needs review

changing status

Damien Tournoud’s picture

Status:Needs review» Needs work

Thanks for the patch.

Those token do need to be sanitized: when output in an HTML context, "&" needs to be converted to "&".

jenlampton’s picture

Status:Needs work» Needs review
new4.17 KB

this time with the help of my little friend, t().

Golem07’s picture


just wanted to create an issue when I have discovered this one: Imho it would be very helpful if other fields could be used as tokens as well. Especially the name and organization fields would be very useful in combination with e.g. realname module, realname registration module, for file paths or automatic nodetitles.

Would it be very hard to extend this patch to the mentioned fields?

WorldFallz’s picture

Title:Country token support (patch attached)» Country/state/city/postal code token support (patch attached)
new5.03 KB

I needed city and state so I updated the patch and threw in postal code for good measure. Seems to be working fine for me so far.

mcarbone’s picture

new5.42 KB

Made a few changes:

1) No need to sanitize country codes since those are predetermined.

2) Used check_plain to sanitize rather than t(), following the example of node.tokens.inc

HendrikM’s picture

I would like to generate URL aliases in the form "nodexyz-city", where city is stored inside the address field. In URL aliases -> Patterns, I only find [node:field_address] (field name of addresfield element) in the list of replacement patterns. Any idea how I could automatically add the city to the URL alias? Something like [node:field_address:city]?

WorldFallz’s picture

did you apply the patch? if so, it's [node:field_address:city-name]

achikas’s picture

i applied the patch against the latest dev version, but can't choose a token like [node:field_location:city-name] as url-alias. :-(
any ideas?
would be great to see the patch into the next recommended release.

camidoo’s picture

new4.53 KB

Added in street address for good measure

enekochan’s picture


I haven't been able to apply this patch correctly. I'm new to Drupal so I suppose I'm doing something wrong. I've downloaded the 7.x-1.x-dev version of addressfield and applied "addressfield-tokens.patch" patch (executing `patch < addressfield-tokens.patch` inside my sites/all/modules/addressfield folder) but I get this error:

patching file addressfield.info
Hunk #1 FAILED at 4.
1 out of 1 hunk FAILED -- saving rejects to file addressfield.info.rej
patching file addressfield.tokens.inc

Also tried other patch files listed here but they didn't work or I got similar errors while running patch.

What patch (or patches and in what order in the case I have to apply several of them) do I have to apply and to what version of addressfield (7.x-1.0-beta2 or 7.x-1.x-dev)?

Thank you very much.

enekochan’s picture

Finally got it working. Just used the patch "-18" and then added by hand the code in "-14" that wasn't in "-18".

l00ph0le’s picture

New to drupal as well...struggling with patching this..Can you provide further info as to how you accomplished this?

enekochan’s picture

new5.98 KB

I've created a .patch for the latest 7.x-1.x-dev (http://ftp.drupal.org/files/projects/addressfield-7.x-1.x-dev.tar.gz). I'm new to Drupal development so I think its not the same as other because I don't use git (I've seen something about git in the other patch files). You have to download the .tar.gz, unzip it, copy the .patch file to the just created directory and execute on the console in that directory:

patch < addressfield_tokens-1188778-19.patch

Then copy the module to your Drupal instalation and I would suggest to restart your server and clear all caches just in case.

emptyvoid’s picture

Are there any plans for this patch to be rolled into the dev/trunk or into a branch release?

amarcus’s picture

new9.91 KB

I have created an independent addressfield_tokens module to created tokens with optional custom names, and attach them to all entities with addressfields. It also provides some extra field formatters, such as city/state, and a webform integration.

I have just created a project for it on drupal.org: addressfield_tokens. Until the code has a chance to propogate, here is a zipped version.

Oceanman’s picture

Is this sort of change in the scope of what this module should do? I want to know if this module will ever get these tokens built into the module. #22 has a module solution to add to this now but if the maintainer is going to roll the patches into this module, then I would rather have one less module and just use this one. It has been a few months since the dev has been updated so it is hard to determine if these patches are being considered or not.

Any comments from Damien as the future of these patches for this module?

osopolar’s picture

Take care while using #24, its not GPL, the file description says:

* Copyright 2011 New Signature
* http://www.newsignature.com
* @author Andrew Marcus
* @since Oct 4, 2011


I overlooked the module addressfield_tokens where a LICENSE.txt with GPL license was added. Anyway it's a bit confusing.

WorldFallz’s picture

Not really-- copyright is not a license. There's nothing incongruous with a GPL module having a copyright notice-- it's done all the time.

firfin’s picture

Status:Needs review» Closed (duplicate)

This seems to me to be a duplicate of #1269806: Address Field Not Available in Email Using Rules , based on :

- "This module only does one thing, but does it correctly: store international postal addresses." (i.e. no token support)
- addressfield_token offers tokens for addressfield

WorldFallz’s picture

Status:Closed (duplicate)» Needs review

it's not really a dupe-- the address field module does already provides tokens, just not a complete selection. imo they should live in one place or another but not both. If the maintainers of this module don't want to add complete tokens, then we should probably create a patch to remove them altogether in favor of the other module (imo they belong here though).

firfin’s picture

Ah ok, I stand corrected. I hadn't realized addressfield provided ANY tokens. I thought addressfield_tokens module provided the complete selection, it proved ample for me at least. Ideally they would only exist in one place (this module) I agree. But then this module was designed to ~'do one thing and do it well'.

kaizerking’s picture

I wanted to use the address field "organisation_name " to populate node title (auto node title module)
How do i get it:
I have the address field name as organisation_address
Token :[node:field-organisation-address:?]
the description says: Field "field_organisation_address". The following properties may be appended to the token: country (Country), name_line (Sub premise), first_name (First name), last_name (Last name), organisation_name (Company), administrative_area (Administrative area (i.e. State / Province)), sub_administrative_area (Sub administrative area), locality (Locality (i.e. City)), dependent_locality (Dependent locality), postal_code (Postal code), thoroughfare (Thoroughfare (i.e. Street address)), premise (Premise (i.e. Apartment / Suite number))
I wanted to set the title = organisation_name
I mean how to append
Edit :
it is
Token :[node:field-organisation-address:organisation_name]
this worked for me

charlie charles’s picture

I tried this for county field but it didn't work
is this right?


firfin’s picture

@marga: Try Addressfield Tokens , that worked for me. I have strong feeling this will never get added to addressfield.
Furthermore you seems to have an 's' too many in your fieldname ;-)


rszrama’s picture

Title:Country/state/city/postal code token support (patch attached)» Add token support for the various elements of an address field
Status:Needs review» Needs work

Just a quick note to say, yes, this module should offer Token support. Of the patches in the issue, it seems #22 is furthest along, so I'll start my review there. However, I should warn that the token names will be using the column names of the field - in other words, it won't be field_address:state_province-name - it would be something more like field_address:administrative-area.

bojanz’s picture

Status:Needs work» Needs review
new5.56 KB

This is an interesting subject.

There are two modules that provide field tokens:
1) Token - provides the "underscore" tokens like [commerce-customer-profile:commerce_customer_address].
This is where our integration is lacking, you can't access a subproperty.
2) Entity API - provides the "dash" tokens like [commerce-customer-profile:commerce-customer-address]. Since these are powered by Entity Metadata, they support all properties of the field.
So, this actually works:

= commerce_customer_profile_load(690);
$text = 'I live in [commerce-customer-profile:commerce-customer-address:country]';
$text = token_replace($text, array('commerce-customer-profile'=> $customer_profile), array('clear' => TRUE));
// Outputs "I live in France"

I'd personally love it if Token would just stop trying to provide field tokens, since it's so bad at it (compared to Entity API), but since that won't happen, I guess we need to add integration of our own.

Rerolled the patch (didn't apply anymore), did basic cleanups and token renamings.
Unsure if this is the right way to do the field level integration. Date module might be a good example to look up.
In any case, stopped here since the Entity API provided token solved my problem.

Dave Reid’s picture

I'd personally love it if Token would just stop trying to provide field tokens, since it's so bad at it (compared to Entity API)

Sorry but the way the token system was abandoned once put into core, and due to a lack of mature core APIs regarding fields and entities is the real 'bad' here. I'm tired of getting blamed for attempting to solve a problem with crappy core APIs.

rszrama’s picture

Status:Needs review» Needs work

Still work to be done here for some supported address elements that don't have tokens (names, sub-premise, etc.). Additionally, I don't see a need for addressfield_get_address_fields() when field_read_fields(array('type' => 'addressfield')) would do the same thing.

bojanz’s picture

@Dave Reid
Sorry if that came out wrong, nobody is blaming you, I'm just stating the fact that the Entity API implementation has more features (due to having Metadata to rely on), which is a reality despite all the ugliness in that backstory.

boabjohn’s picture

@bojanz and @David Reid you guys are both heroes.

Is it possible to get a word of explanation about what is going to rock my world once the patch at #35 is applied?

The patch applied cleanly to my 7.x-1.0-beta4 version, but in Views I'm not seeing any extra options under "Re-write output" > Replacement Patterns...we still see only this:

[field_locationaddress-country] == Raw country

Should I be able to access the new token/entity api value somehow in the Views rewrite field? If so, what's the correct syntax?

Thanks very much for any clues...

rszrama’s picture

This patch doesn't actually affect Views - there's a separate issue for that (just give the queue a search for Views). Views doesn't use tokens as defined by the core Token system, which is what Dave's implemented. It uses the field name of fields added to the View's field list. Right now, since the address field is just added as a single field, you can't use the individual address parts as replacement patterns, but once that other patch gets in, you should have access to every bit.

boabjohn’s picture

Ahh: thanks very much for the clue. Will chase that other patch now.
Chrz, JB

emilorol’s picture

How about an extra token for administrative_area where you can show the full name.


Right now:

[node:field-address-fields-example:administrative_area] // will print CA for California

Extra option:

[node:field-address-fields-example:administrative_area:name] // to print California

Note: the following examples implied that you pick the country USA and the state ( administrative_area ) california in a content type using the address field module.

rszrama’s picture

Issue summary:View changes
Status:Needs work» Fixed

Ok, I've moved forward with a token implementation that overrides the Token module's implementation, extending it with customized tokens and helpers for working with address field data. This means Address Field tokens will depend on the Token module, but Token is on most Drupal sites already anyways. This means the tokens follow the pattern of entity-type:field_name:component (as opposed to entity-type:field-name:component as defined by the Entity Tokens module).

I ended up using "address-field" as the token type to avoid a conflict with the Addressfield Tokens module, since that's in use by over 3,000 sites. Eventually it will be in their best interest to migrate, but I don't want them to break in the meantime. I didn't copy all of the helper tokens from that module, but carrying over the MailChimp format seemed reasonable (and doesn't really require a dependency on MailChimp).

The token list is as follows:

  • country: Country name
  • country-code: Country code
  • administrative-area: Administrative area (i.e. State/Province)
  • administrative-area-raw: Administrative area (raw value)
  • locality: Locality (i.e. City)
  • postal-code: Postal code
  • thoroughfare: Thoroughfare (i.e. Street address)
  • premise: Premise (i.e. Street address)
  • organisation: Organisation
  • name-line: Full name
  • first-name: First name
  • last-name: Last name
  • format-mailchimp: Address formatted for MailChimp

I'm going to open a follow-up issue for researching multilingual token usage and for figuring out how to support multi-value address fields. As it is right now, this implementation just uses the first delta of the address field value array to generate tokens.

I'm open to other formats as well. Right now if you use the field itself as a token, it'll be replaced by the full rendered field value; probably not ideal, though we don't really have a way in addressfield.module to produce a lighter weight rendering of the address.

Commit: http://drupalcode.org/project/addressfield.git/commitdiff/98345e3

klonos’s picture

Thanx Ryan! ;)

Status:Fixed» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

emag’s picture

I'm trying to get at the components of my address field in panels like #31. The address field is attached to a user. What works is this: %user:field_name_and_address . But it gives me the entire address , all fields running together. E.g. John Smith1 Main StAnytown, CA 99999United States

When I try to get any address component of the user entity address it just comes back blank. e.g. %user:field_name_and_address:first_name

What am I doing wrong? thanks

FMB’s picture

But it gives me the entire address , all fields running together. E.g. John Smith1 Main StAnytown, CA 99999United States

I've got the same issue. Implementing a "full-address" formatter like suggested in #1481138: Add a "Custom address format" display formatter supporting custom token patterns could help to solve it.

Nchase’s picture

with addressfield 7.x-1.1+3-dev (2015-Jun-25) I can't get any addressfield tokens to work with pathauto. The tokens are available in the list of replacement patterns but they are not used to create the pathauto url.