[meta] Address Field 2.x needs pluggable administrative areas and an actual API

This is something we discussed during the Commerce 2.x sprint, and is definitely part of our roadmap for Addressfield 2.x.

The objective of Addressfield 1.x was to come up with a simple address solution management that covers the 80% use case. It obviously failed, so we are going to tackle the complexity in Addressfield 2.x instead of avoiding it.

The idea is to support two concepts:

Address format

Addressfield will support multiple address formats, and will ship by default with three address formats (new address formats can be added):

• City-level (ie. city / possibly administrative division / country)
• Building-level (ie. premise / thoroughfare / dependent_locality + City-level)
• Full (ie. name / organization + Building-level)

Each address format will be stored as a configurable entity in CMI. We will have a token system (yet to be designed, possibly the one adopted by Google) and support for different edit / render formats and country-specific override of each address format.

Postal divisions

This is actually different then the common principal subdivisions defined by ISO-3166-2 (for example, the US has postal divisions "AA", "AE" and "AP" for state-side and oversee Armed forces).

The postal divisions are going to be managed in separate configurable entities in CMI, so that they can be used by multiple address formats.

1.x is feature frozen at this point. We are not going to make any drastic change to this branch.

improved formatting.

Added Hungarian

type

The module could use / import CLDR Unicode country data, the industry standard used by the big boys (and Drupal #1938892: Switch from ISO-3166-1 country data to CLDR unicode data) for country / region data including translations! So, all data is already available in all languages :) Perhaps the module could have some supporting db tables or xml files.

Addressfield could also integrate with http://drupal.org/project/countries that is looking into this #1830198: Better support for various providers of Country data.

I'm doing address module migration and I have created custom module which changes Address form (country-specific) (I just copied that plugin and customized it.

In that plugin I use states from address module. And it has all countries, though abbreviations are not always right, sometimes it uses 2 and sometimes 3 letters. I didnt check, maybe states are in better shape in newest dev version, as we have custom list. But it is quite good solution.

I'm attaching my custom module. After enabling u can see 1 more checkbox while configuring field. And then states will come from all countries or almost all

Just looping this in: #1010314-37: Separate Components of Address field

That contains a first pass patch at making individual address components available or not available. It's a different approach to what Damien's described, and given the opportunity for a 2.x rewrite, I doubt we'll carry it on. But there's still plenty of history to link in there.

Glad to see this improvement.

However, currently we are going to improve the china addressfield. So I wonder to know any news on the 2.x branch? especially the ctools plugin system. Thank you.

The link of china address field:
http://drupal.org/project/China_address_field

Drupal core now uses Unicode CLDR data for country list #1938892: Switch from ISO-3166-1 country data to CLDR unicode data. I believe there is no point in replicating all country info in this module, but reuse Unicode CLDR, and let users submit address data straight to unicode. Let's not duplicate efforts! Think big, and outside of the box...

@giorgio79 - that's a separate issue; this module will always follow the ISO standard as much as possible. Administrative areas are subdivisions of countries and not covered by the core patch (which is for D8 anyways).

Yep, thx Ryan. While the core patch doesn't, cldr does cover administrative areas, subdivisions etc including internationalization. For example: http://www.unicode.org/review/pri180/
Looks like the Google data is ISO compatible as well :)

Hi, I noticed the head issue was closed, but this UI is to great to forget I think.
It would be great to have installed within Addressfield https://drupal.org/node/1010314#comment-5615366
Greetings, Martijn

added brazo;

Changed South Africa's issue to the active one.

Just as a heads up, I've been building a module that layers on top of Address Field in a largely client-side way that happens to reduce some friction in this area.

• The Drupal module
• The jQuery plugin
• The default JSON config

We now know how 2.x is going to look and work:
https://drupalcommerce.org/blog/16864/commerce-2x-stories-addressing
It uses the dataset Google built for Android, including their list of subdivisions (the CLDR data is insufficient).
The 8.x-2.x version of addressfield will depend on the library we created to do the actual work.
A 7.x-2.x version can follow the same architecture, with the imposed PHP 5.4 requirement of course.

The library / implementation plan resolves all of the points raised by the OP, so I'm marking this issue as fixed.

In the meantime, in 7.x-1.x I plan to move the administrative areas out of address.inc, and try to replace them with the ones supplied by Google.
That's as much as we can improve in 1.x without breaking backwards compatibility.

That is fantastic! Much appreciated Bojanz :)

As promised, administrative areas are in their own include file: http://cgit.drupalcode.org/addressfield/commit/?id=2ae5e55

I also managed to introduce the concept of an address format without causing BC breaks:
http://cgit.drupalcode.org/addressfield/commit/?id=712da4d and explained in #2390035: Introduce the concept of an address format, import (some of) Google's dataset.

I'm also planning to add alter hooks. All of that is already a huge improvement over beta5.