Missing addresses in address book and checkout

It looks like there is something wrong with the Ubercart Addresses address formats. An address format is used to create an address "label" and in your screenshots these labels look empty (thanks for posting the screenshots to clarify the problem!). Go to /admin/store/settings/countries/uc_addresses_formats and check if the address formats for Ubercart Addresses are set right. An address format should look something like this:

[uc_addresses:company]
[uc_addresses:first_name] [uc_addresses:last_name]
[uc_addresses:street1]
[uc_addresses:street2]
[uc_addresses:city], [uc_addresses:zone:zone_code] [uc_addresses:postal_code]
[uc_addresses:country:country_name_if]

It can look different, depending on the country.

Did this issue happen on a fresh install of Drupal + Ubercart + Ubercart Addresses? Or did this happen on an upgrade from Ubercart Addresses 6.x-1.x or 6.x-2.x?

It sounds like something goes wrong when saving address formats on admin/store/settings/countries/formats. Although Ubercart reports it saved the country settings, it probably didn't. Can you post a screenshot of this page? (I'm not sure if I can locate the problem with it, but I could look if it looks right.)
Did you try to edit the address format of one of the countries on admin/store/settings/countries/uc_addresses_formats? You can click on the country name to edit the address format.

It took me some time to figure out, but I think I got a clue what's the cause of the issue. Since you disabled the country field, the setting for the Ubercart default country is not saved (I didn't knew about this behavior in Ubercart). Also, if the country field is disabled, Ubercart Addresses tries to pick the Ubercart default country to format the address with. Since there is no default country, Ubercart Addresses can't find the address format to use and choose to display nothing. Yes, that is a bug.

In the first place, Ubercart Addresses shouldn't give up if it can't find an address format: it should at least use a default address format.
Second, I think it should look at the available countries when there is no Ubercart default country. Now it just picks U.S., even when that country is not available. I should examine what Ubercart does in this case.

A quick fix for you would be the following:

1. Temporary enable the country field on admin/store/settings/countries/fields.
2. Go to admin/store/settings/store and set the store's country.
3. Disable the country field on admin/store/settings/countries/fields.

Meanwhile, I'll look for the real fix, though you won't need to wait for it as the steps above would solve the problem for you too.

This patch fixes two things:

• It ensures that never an "empty" address format is used. In case an address format is not found, it uses a "hard-coded" default address format.
• When the country field is disabled and there is no default country set, Ubercart Addresses will first try to use the address format for the United States. If that country is not available, it will use the address format from the first country available in alphabetical order.

The patch also includes a test to ensure the bug is fixed.

The test is failing because of a caching issue in the tests. uc_store_default_country() caches the default country in code using the static keyword instead of the more encouraged drupal_static() function. Because of this, this function can not be evolved in API tests like this. The test should be done via an other approach.

The test in the attached patch disabled the country field and tests the output of formatted addresses using curl instead of the API. Additionally, some changes were needed in the base test class "UcAddressesTestCase", because the function for generating address edit values did not check for enabled fields.

Hopefully, this patch will pass all tests.

The test that fails on drupal.org is passing locally. It looks I need to look for a nail in haystack.

Okay, next try. This patch uses randomName() instead of randomString() to set the Canada address format (in the test).

Committed #11.

Moving to 6.x-2.x.

Patch for the 6.x-2.x version.

Committed #13.

Setting issue status back to the version it was originally reported for and mark it as fixed.