Add address line 3

Do you have any links showing which countries use lines 3 and 4?

Google's library (https://github.com/googlei18n/libaddressinput) based on which we created commerceguys/addressing had 3 lines, now they seem to be down to 2.
I removed the third line from our own code simply because I couldn't find any examples of it being used. Furthermore, their dataset has no information on how many lines a country uses (I do know some use only one line, for example).

So, I'm not opposed to adding line 3 at least, if we can find address format information that would tell us when to show it.

I've never seen line 4 mentioned, even standards like https://html.spec.whatwg.org/multipage/forms.html#autofilling-form-contr... only mention 3 lines, but I'm open to having my mind changed.

Retitling to clarify that having 4 lines is off the table, since not even the HTML autocomplete standard goes that far.
The 4. one is usually handled by the dependent_locality ("Col. San Jerónimo Tepetlacalco" in your MX example).

I've looked up Mexico and Thailand:
http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/me...
http://www.upu.int/fileadmin/documentsFiles/activities/addressingUnit/th...
Thailand has an example of 3 address lines in those documents, Mexico doesn't. Those are the kind of official resources that we need to tell us how to treat the data.

be able to hide all of the fields you don't need for a given address format.

Both the library and the module currently allow this, you separately specify address lines 1 and 2 in the format and in the required fields.

As I said, I'm fine with adding an address_line3 to the model and leaving it unused by default, I'm just not rushing to do it because I'd like to see some more documentation on how we should handle it. Google's library never implemented the third line. HTML autocomplete has the third address line, but I didn't find any information on their reasoning. Sites in general don't do 3 lines. (though I guess the dependent_locality acts as a third line in many countries, the UK for example).

EDIT: Also forgot to say thanks for the Thailand example, it's definitely valid.

I would like to bring this issue back up. We are working with addresses on a German D8 site and have mixed feelings. On the hand, the main idea of this module is to provide "shippable" addresses around the world. It does that, AFAICT correctly.

However: there are good reasons to store additional information, that belong to addresses, but are not strictly necessary to ship a package. In Germany for example, that would be the federal-country or separately the street/house number. The latter for example is required by the german postal data service to correctly verify addresses. Of course we can add any additional fields to the base entity that the address field already is attached to, but this removes the address module as a "one-stop-solution" for address stuff. It also removes the dependencies of the fields to each other.

I do not have a clear proposal how to handle that. Obviously some kind of meta-address-data attachable to the field. Maybe offer all the fields the Google address service returns as optionally attachable fields?

The Mexico example in comment #2 is similar to many of our customers' shipping addresses. For institutional customers, even US addresses often have very specific requirements that don't fit the First_Name Last_Name, Street_Address_Lines format. We ship to many universities with addresses like:

Some University - Direct delivery
Attn: First_Name Last_Name
Specific Section and internal routing code
Building Name and Room number
999 Street_Name St.
City, State zip

OR:

Major University
Med Ctr. General Supply
Unloading Point: some_internal_code
Attn: a big long name
1234 My_Road Rd.
City, State zip

And a non-university example:

Some Major Health System
Supply Chain Management
Receiving and Distribution
123 My_Street St.
City, State zip

Generally, many of our addresses contain a PO number or VAT number (EU addresses), specific receiving locations/data, department names, and/or room numbers in addition to the standard street address.

Obviously, I wouldn't expect this Address module to handle this sort of irregularity if Commerce is mostly intended for B2C stores. Somehow, though, I'm going to need to un-require the First Name/Last Name as the first line and add in additional address lines to accommodate our existing customers' addresses. I've got a couple hundred thousand addresses to migrate into Drupal from our current non-Drupal site. (I'm new to Drupal, so I apologize if this is not the proper place to post these comments--I'm still trying to learn how to communicate appropriately within the Drupal community.)

Also wanted to mention that as an ISO9001 company, customer requirements are an important aspect of our quality standards. We cannot dictate shipping address formats but rather must adhere to those of individual customers.

Just a thought: what if the "organization" field element was changed from a textfield to a textarea? The first/given and last/family name elements could be eliminated, and the "organization" could be labeled something like, "Recipient" (or "Ship to" or "Bill to"). The customer could enter a name, company name, building name, room number, etc. in that text area. And then the rest of the address could be entered into the existing two street address lines, city, state, zip (or international equivalent) field elements.

It seems like an impossible problem to try to provide enough line items for every valid address format in the world. I came across this as I was trying to look at my existing customer data and figure out what sort of structure I'd need: http://blog.worldvu.com/2011/09/length-of-international-addresses.html

Organization as text area sounds interesting. Curious to hear what bojanz thinks about that.

Just a follow-up for anybody else who might need additional address lines. I arrived at a solution using a textarea that seems to be working fine. (Not tested on a live site yet.) My approach doesn't require any changes to the Address module code base.

First, I created a new FormElement by extending the Address FormElement. In the valueCallback method, I removed given_name, additional_name, and family_name from the $properties list. In the addressElements method, I eliminated those same name fields from the size_attributes list, overrided the organization label field to 'Recipient', unset all the name fields, and then changed the organization field to a required textarea field.

Next, I created a new FieldWidget plugin by extending the AddressDefaultWidget. In the getInitialValues method, I removed the name fields, In the formElement method, I changed the 'address' element from type 'address' to the type of my new FormElement. I left everything else as is.

Finally, I used the field ui for my Profile type to use the new widget instead of the Address widget for my Address field. (For the display, I use the Default formatter, which works fine even with the Organization/Recipient textarea now having multiple lines. So now I have an address data entry form with a multi-line Recipient followed by 2 Street address lines (and the Country/City/State/Zip fields).

I think that if you wanted to keep the name fields, this approach would still work. You would just relabel the organization to whatever makes sense for you and make it a multi-line input to provide space for additional street address line(s).

I found several address that needs it.

Such as this Mexico Address finded extracted by Airbnb:
Edificio Jade
Eje Central Lázaro Cárdenas 46,
Obrera,
06800
Ciudad de México, CDMX
Mexico

Or this in France. Address that "Uber Eats" use
21 rue Rébanger
Batiment B - "Le calypso"
6eme étage appartement 56

I propose this patch that add "address line 3" and it works fine with this PR for addressing library https://github.com/commerceguys/addressing/pull/121

This is identicall patch in #10 but with one modification for can apply with 8.x-1.4 version.

Attaching patch for current version of module.

Solving field override for address_line3 over patch #12

reroll of patch #13 for version 1.7

Patch applied to the latest dev version.

The tests did not run on the last one.

A portion of the address_line3 logic was just committed to 2.0.x-dev in #3354976: Switch to commerceguys/addressing v2.0.0. We can now use this issue to wrap up the rest.

Tested locally and it seems to be good, let's see what the testbot says.

Typo in the tests.

Okay, let's play with this in -dev.

Thanks, everyone!