Addresses in Drupal 7

Hi Andy,

For you to get CVS access, you'll need to contact brmassa directly. If it's to work on a D7 version, it's certainly just fine.

You may also want to talk with codycraven who was working on version 2.x. You may want to start from that version instead.

Thank you.
Alexis

Hi Andy,

The biggest problem with a D7 port currently is that Views is not ready for D7 yet as there has been many changes in table names, table functionality, etc. One of the biggest requirements Addresses 2.x is Views support.

So if you are looking to do a D7 port which will be available on D7's release then I would recommend going from the current Addresses 1.x.

Cody,

One thing we could think about is to have a library too, instead of just a module.

That means a library that can be used to get the list of countries, list of provinces, the default address format for a country...

Those things are not specific to the Addresses module, in a way, and could be reused by all.

Just an idea at this point, but something to think about. Just that could be used by the Übercart people without having to run the whole module running.

Thank you.
Alexis

Interesting thought Alexis,

I'll see if I can achieve that in a manageable way... I'm developing 2.x to use data providers (currently local or geonames), I'll see if that can be worked in.

Just wondering, why not using taxonomies for Countries/regions ?

Actually, we should look into the Location module and see whether we could "merge" some functionality. They also include all of that information, in some form, including longitude, latitude, altitude and even temperature...

Taxonomies would be neat since that way we could tag pages and click on a term to see a list of users in that country/region/zip code... The main problem is that taxonomies are really not practical to work with. Maybe it's better in D7 than D6 though.

We could have a Country Taxonomy which has a list of all the countries and children terms that represent the regions.

Thank you.
Alexis Wilke

Just a note that the Upgrade Status module indicates no D7 upgrade path for this module ("No available releases found"). But looking above, it appears it's in planning phase.

A separate library... Actually, for all the countries, we want a separate library and probably for all the functions that manage the content. Why is that? Because that way we can avoid having the library under sites/all/modules/addresses/*. This is an optimization because Drupal searches all the folders all the time and a folder with over 250 files should just not be there. Instead, those should go under sites/all/libraries/countries/* and we certainly should have a separate modules to handle those.

Andy, what do you think of this approach? Wouldn't that make it easier for Übercart to benefit from our country lists?

Thank you.
Alexis Wilke

See http://drupal.org/project/addressfield. It would benefit the community and reduce confusion if there was only one address field module that was considered the standard (similar to how date is viewed now).

rick,

Are you a co-maintainer of that new addressfield project?

Is that a CCK only field or would it be an actual Drupal field? This is actually an excellent idea. Like a list, a text area, etc. we can indeed have a Drupal field defined as: '#type' => 'address'.

This does not cancel my idea of having the list of countries in a separate library though.

Thank you.
Alexis

@AlexisWilke - No, I'm not a co-maintainer of the addressfield project. However, I do have much respect for Damien and I support the aim of the module to be "the" solution addresses in D7. He's looking for co-maintainers.

#916336: Addresses verification support

Subscribing

I'm certainly not against making Addressfield the go to solution for D7 and beyond. I think the templating system is in desperate need of direction in Addressfield -- I'm by no way saying Addresses does it right as I think it is just as bad -- but other than that it is heading in the right direction, as long as critical items like Views support are handled early on.

CCK with multi-field widgets are a terrible hack which may be some of what made Addresses in the dire state it is now in 6.x. Drupal 7 provides much better support through fields. Our biggest issue will be figuring out an upgrade path for existing users which I don't think can reliably be done until Addressfield is in a stable state.

Oh and to address any wondering, no there is not currently anything for Drupal 7 Addresses in the works.

Here's an option for dynamic address verification. It's free.
https://webgis.usc.edu/Services/AddressValidation/Default.aspx

All they ask is we provide a link back to them ie. Verification provided by...

That looks interesting, although they don't really say that's only for the US. Is it? If so, it is still somewhat limited. Many of the Addresses users are from other countries.

I see your point. How about applying it as a US AVS then?
Conceivably it would be difficult to find or wait for one system to cover every corner of the earth [From my understanding it's not kosher to use GoogleMaps API for this unless you show a map (Which is another option)] and even if you did find a all-in-one solution; it might do a poor job for one region where a region specific solution might be better suited for that regions needs. In my opinion to effectively implement a global solution the best option would be modularizing AVS support and enabling the ability to specify/addon/plugin the AVS system/method being used; I feel this could prove to be a more accurate as well as flexible. As an added benefit, by modularizing the verification to different regions wouldn't that also speed up adoption and support for those areas that do currently have such an option available? And later as other verification systems become available those could be rolled out as an update from which people could be presented with the verification options for each region (Also enabling multiple options per region as a fallback!)
Reading around I've found that it might be possible to utilize the FedEx API for this purpose. They have an option which enables you to generate shipping labels which returns a message on a bad address. Although it's not specifically designed for our purposes - I'll leave the assessment of how mickey-mouse this is up to all of you.

FedEx probably has a policy that their API be used only if you ship goods with them.

Thank you.
Alexis

How about developping something around this : http://www.geonames.org/about.html

+1

Subscribing

+

I agree with #9 and I wish, address field, location and adresses will merge in the future in a good address field with full views integration. Although I understand that

it would be difficult to find or wait for one system to cover every corner of the earth

in #17

subscribing

I'm needing a simple editable address field but I'm not really satisfied with the current solutions.

I'm thinking about writing one that has the countries module as a dependency so that country specific data can be simply added to the countries bundle as a simple field. To overcome the short-comings of Drupal 7 field schema handling (i.e. completely preventing any schema changes), I'm thinking about an interface / internals similar to the name module, where column changes are done via the interface rather than within the database.

I wasn't going to release it, but if I complete it and there is interest, ping me and I'll share the code. This will only be for Drupal 7.

Of course, using countries as a dependency for the adresses module is a very welcome idea in my opinion, and I would be interrested in testing your solution @Alan D.

I think we could also imagine merging address field + phone + Gmap (or an other map module like geofield, geolocation, etc.) + countries + etc.
in a field collection to take advantage of D7 entities and the best specialised fields available
This way you make the modular address field you need for each website.

http://drupal.org/project/addressfield
http://drupal.org/project/phone
http://drupal.org/project/email
http://drupal.org/project/countries
http://drupal.org/project/gmap
http://drupal.org/project/field_collection

Jerome, If you can take all that and create a cohesive module that is highly configurable, I shall heap much praise upon you.

Here's an interesting related issue http://drupal.org/node/1063920