International support

And then have some country configurations for how to theme the fields?
Sounds good to me, very interesting module.

And then integrate with location and gmap ... ah, I can see possibilities ...

I suppose other widgets could be created for other countries. I did go ahead and start a framework so that support for other countries can easily be added. However, since I live in the U.S. and don't know the requirements for other countries' addresses, I'm hoping that all of you will submit patches. The state field can support provinces, if you like. The DB table, as I recall is a list of states, with an associated country. If we add a country selector, we can populate the state dropdown with states/provinces/whatever.

You'll notice that the .install file includes the state entries to the DB table. I suppose if we add support for other countries that each country should have an include file instead of adding to the .install file. In that case, I'd move the U.S. states into an include as well and maybe define a function to find all of the include files and fire their DB functions.

So, the long and the short of it is that I'm willing to make the changes if others are willing to collaborate.

I don't think the possible address fields for different countries are so different, just the presentation differs. And that should be subject to a theming function ...

Refactoring the US state data into a separate file is a good idea - but I feel it's not really part of a cck-address field. Maybe make a address-basedata module?
I remember having seen somewhere a discussion about shared geo-data, but I can't find it now.

For the beginning, maybe the state-data could be optional, so a user can just enter a string in the field if no table to select from is present?
And the same probably for validation of zip-code.

I guess you already had a look at what the guys from the location module are doing? And the gmap module ...

Sorry if I'm not much help, adding geo-data to our site is on our plan, but no implementation started yet ...

I would like to see support for Canada addresses and am willing to lend a hand. I think separation of data into different includes is a great idea. I also think theaming instructions should be stored in the same include file as well, that way anyone can just create and add an include file for their specific country and it, hopefully, won't require any changes in the module. I'm gonna download the module and take a closer look at it. Thanks for creating it!

@sshvetsov I'll be trying to address any bugs or feature requests every Friday, but I'll continue to check the issue queue daily. If you'd like to let me know what Canadian addresses look like, and possibly work up what you think an include file should consist of, I'll be able to do something about it then.

Applied a little patch to support country-specific theming of addresses.
Since it's really small, also here inline:

--- a/cck_address.module
+++ b/cck_address.module
@@ -301,6 +301,17 @@ function cck_address_field($op, &$node, $field, &$items, $teaser, $page) {
  *   An HTML string containing the formatted item.
  */
 function cck_address_format($field, $item, $formatter, $node) {
+  return theme('cck_address', $field, $item, $formatter, $node);
+}
+
+function theme_cck_address($field, $item, $formatter, $node) {
+
+  // use country-specific theming if available
+  if (isset($item['country'])) {
+    $themefunc = 'cck_address_' . $item['country'];
+    if (theme_get_function($themefunc)) return theme($themefunc, $field, $item, $formatter, $node);
+  }
+
   if (!isset($item['street1']) && !isset($item['city']) && !isset($item['state']) && !isset($item['zip']
     return '';
   }

Btw: is there any reason, the signature for cck_address_format() is not cck_address_format(&$field, &$item, $formatter, &$node)?
At least in php4 you need the '&' if you want to pass something by reference, right?

Comments?

ray007> I'll probably get around to adding this on Friday.

As to the answer to your question, I simply copied line 931 from content.module. As I recall, I wanted to bypass the formatter hook processing, though perhaps I don't have a good reason. My lack of CCK understanding is showing. In fact, I can't now recall why that decision was made. If you know how that is supposed to work and want to make a patch or could just explain how it should be done, that would be great. The CCK documentation isn't the most complete, as I'm sure you know. I know that other modules use hook_field_formatter() and hook_field_formatter_info(), but I couldn't figure out what the point is.

Also, yes, you need the '&' if you want to pass something by reference, but you only pass by reference if you want to change the 'real' variable's value. I don't think I changed anything, so I didn't need references.

I think passing by reference also improves performance when you don't have to copy arrays and objects for every function call. Not sure how much difference it really makes ...

one thing to note that drupal does in some places: if a variable is passed to a function as a reference, you shouldn't (can't) also put the variable in a function header as a reference. in other words if I have a function

function foo($bar=NULL) {stuff here;}

and I call it somewhere like

foo(&$var);

then it's good that I didn't declare my function as

function foo(&$bar=NULL). I don't know what this is all called, or if I even described it correctly, but I hope you get the idea. It's on the php.net site somewhere and I've seen that come up in a couple of discussions here on drupal.org. so maybe that's why line 931 of content.module does it that way, but I don't know.

@rconstantine: I'm starting a separate feature request thread to avoid clattering this one. See http://drupal.org/node/129920

would be happy to help with the United Kingdom info if I knew what you needed

regards

joe

Just thought I'd let you know I started on this. I'm starting with Canada. Changes will be incremental.

Sweet! I'm keeping an eye on this module and very excited about the possibilities it offers.

I was trying to think how to make this module flexible enough to allow any address type from any country. I'm thinking the main module should be just an empty framework or provide some sort of an address API, then different country modules or includes can expand the functionality. These includes could be enabled/selected in administration settings. I know this would make this module much more complex, but then it would be pretty easy to write a sub module for any country.

One dilemma I'm having is whether this module should allow an end user to select the type of address (s)he's entering when creating a new node, or should it be decided and set by admin when (s)he's creating the content type. Later option is easier to implement, but somewhat limiting. Any ideas?

I just finished some major changes. I need to figure out how to update a cck database field and then it will be ready for upload. Since instances of a cck field can be in several places, I'm not sure how to find them all and update them. This is required for anyone who has already started using this module or things will break badly.

What I did is:

1. Separate out the U.S. database entries into an .inc file and call it from .install (since it will be standard).
2. Created a Canadian module that adds the Canadian provinces (states).
3. This can be used as a template by anyone (even non programmers) to add other countries and their states/provinces/whatever.
4. Created a second DB table for countries.
5. Allow the admin to select which countries will appear in the dropdown.
6. Added AJAX (via activeselect module) that dynamically loads states into their dropdown (without prepopulating the #options of the state. -- for some reason, the activeselect creator thinks this has to be done, but it doesn't). This feature should degrade gracefully for non-js people.
7. Added an 'other' field for countries that need more room.
8. Changed behavior of state abbreviation to only affect output display.
9. Added country abbreviation checkbox for output display.
10. Added calls to standard cck views functions (may not work right.)

What needs to be done:

1. Auto update existing instances of the module. This is a show stopper. I can't upload until this works.
2. Modify validation to accept non-english. (I'm still not convinced to simply do regular formatting as I need more control in my particular application. I'm thinking of doing a locale switcheroo as a regex workaround.)
3. Maybe need more done so views will work. There's another issue regarding this around here somewhere.
4. Maybe add direct support for locale/location module. - Would this make t-ified text change depending on ip address location?
5. Maybe add support where selecting a country changes the t-ified strings too.

I think the names of the fields are t-ified so they can be renamed via the regular translation tools/theming. Other than that, I'm not sure how mush more modular it needs to be.

Hi,
First i wanted to thanks you for the job, it's i think a good idea to have an address field for CCK.
I'm actually working with the location module and i just did a switzerland zip codes sql file (http://irata.ch/en/drupal/swiss_zip_codes) and there's also germans and U.S. codes as well.
I guess that for evolutivity it would be much better to use the location module than include files (but it's just an opinion).
If wanted i could work on this (i mean the use of location module) in the next days.

I'll be posting the next version either today or tomorrow. If you would like to submit patches against the new version for your proposed changes, I'm willing to consider them. Once the new version is available, simply start a new issue as a feature request and attach your patch. If your improvements consist of several feature changes, please try to break them up into several patches so they can be considered singly. Ideally, I'd like this module to degrade gracefully if a dependent module isn't there. So if your code can check for the existence of 'locale' and do something else if it isn't there, that would be great. I don't want to make people download a bunch of stuff just for an address.

Cheers.

@rconstantine

Totally agree with you on trying to keep dependencies optional if possible.

If you choose to use 'location' for base-datastorage, it can't be optional.
If you don't there's no use in using location ...

For other optional dependencies (i.e. gmap?) I agree ;-)

I just posted the new version. Drupal's cron will make it available within 12 hours.

In the future, I'd like to add support for additional countries following the pattern I've established for Canadian addresses; i.e. make each an add-on module. I may even develop a validation hook that each module can take advantage of if needed. We'll see.

If I've omitted anything to make the Canadian addresses work, let me know. For those of you interested in making more addresses possible, let's open a new issue for each country, if you please. There we can discuss any requirements that the module doesn't currently handle. I'd like to keep the module as generic as possible. If I need to change field types in order to handle a wider variety of characters, that's fine. In that case, I'll tie the validation routines to the country field.

One thing that wasn't mentioned in the Canadian thread was whether I needed to do anything to change the zip code for use with Canadian addresses. As I didn't change anything, I'm sure you folks will let me know if what now exists won't work.

I'll be exploring some funky localized validation routines in my cck_fullname module which needs updating and may be able to use similar methods here.

Anyway, once you try out the changes, let me know what's broken - or if everything works.

Thanks.