profile tokens against default addresses

Look at the documentation for the Token module, then create a patch for uc_addresses. Good luck!

I needed token support for address fields for a client, so I wrote it into uc_addresses. Attached is the patch. It's pretty straight forward, just provides all the columns of uc_addresses that make sense as tokens in both safe and raw format.

Would love to see this go into the next release. Please try it out and let me know if any improvements are needed!

Thanks,
Matt

Hi m4olivei,

Thanks for the patch. I see if I add this to the 6.x-1.x version. I'm very busy with the 6.x-2.x version at the moment, so it could take a while.

Did you know the 6.x-2.x version has already token support? Maybe you want to review token support for the 6.x-2.x version?

I didn't know the 2.x version already had token suport. The site I was working on is using the 1.x version so I wrote the token hooks for that, but then created the patch above against the 2.x version, my bad.

Here is a proper patch implementing token support for the 1.x version. I would just use the 2.x version, but this site is in production, so we'd prefer to stick with the stable version.

No problem sticking with the stable version. I'm looking for volunteers to test the 6.x-2.x version and because you was looking for token support, I was wondering what you think about how well the token support is in the 6.x-2.x version. Would it suite your needs if you would be using the 6.x-2.x version? This way I know if I the token support for the 6.x-2.x should be improved more or not.
(I do not recommend to use the 6.x-2.x version on production sites right now, because it's not feature complete yet and not thoroughly tested.)

I noticed in your implementation for 6.x-2.x, your basing it on $type = 'uc_addresses'. Does that work? I thought the $type parameter was always one of 'global', 'node', or 'user' and here you'd want to provide tokens based on the 'user' $type. See my implementation.

The tokens of $type = 'uc_addresses' are tokens used in address context, thus when you are working with an address object (that is defined by Ubercart Addresses). One place where these are used are in the Ubercart Addresses country formats (6.x-2.x only):
admin/store/settings/countries/edit/uc_addresses_formats
These tokens are not available in user context.

I see you want to use tokens in user context. I can add that, but note that not nessacery every user has a (default) address.

True that not every user has a default address. In my use case, users were forced to fill in their address at registration so it was the case that all users had a default address (for the most part). It's handy to have it in the user context for registration emails. In my case, the site admins wanted to get an email when a user registered complete with their uc_addresses information they filled out on registration. Thus it was really easy to implement hook_token and use those address tokens in emails (using rules module).

I have implemented user tokens for default addresses in the 6.x-2.x version. I still need to review the patch for the 6.x-1.x version, but I will do that later when I'm less busy with the 6.x-2.x version.

I finally had some time to review the patch. I made some modifications to it:
- Fields "aid" and "uid" are only excluded for raw tokens.
- The address tokens in the token list are grouped inside "Ubercart Addresses - Default address" instead of "user" (the token are still in user context).
- All address tokens are prefixed with "uc-addresses-default-" instead of "uc-addresses-" to be consistent with Ubercart Addresses 6.x-2.x, where address tokens prefixed with "uc-addresses-" are tokens in address context. The tokens implemented in 6.x-1.x can only be used in user context.
- Date tokens are created for fields "created" and "modified".

This change has been committed.