Custom Profile Duplicate Address Fields Elements at Checkout

Thanks for debugging this.
Please provide your changes in a patch format though, to make it easier for maintainers to review and commit.

I tried the fix suggested here. The problem I am seeing with the extra 'ifs' is that my dropdown for Saved Addresses stops working after that.
With outer if commented, no dropdown.
With inner if commented, dropdown with ':' and error undefined index 'name_line'.
With both if commented, dropdown works, but there are ghost form fields, some filled with same values as the Billing fields while others are empty.
I just have a vanilla kickstart installation while I am trying to test drive and ramp up on Commerce.

Attached is a patch to fix the duplicate form elements.

brad.mrumlinski approach did not work for a few reasons. We do not want to only add the element if it isset(), we want to all the elements set for not. This way if Address 2 has text in it on the checkout form, when you select one of the saved addressed that does not have Address 2 set, it should fill in Address 2 with a blank value from the saved address. This applies to all fields in the form, especially if the Country changes. They need to be there so they can blank out already entered elements when a saved address is selected.

The reason that you were getting multiple form elements added, some duplicates, was that the saved form was getting added to the displayed form, not added as separate hidden form elements. This is because on the checkout page, the address form eventually gets called 'customer_profile_billto'. If your saved address was also 'customer_profile_billto' when created, you ended up added multiple elements to the same form. To get around this duplication, I simply called the saved from it pulls from existing profiles, 'customer_profile_saved_' . $type. This will give you 'customer_profile_billto' and 'customer_profile_saved_billto', so there is no duplication.

This works beautifully now. Thanks for the fix and gratitude for the explanation.

I spent some more time on this today and working towards a solution for http://drupal.org/node/1280248. I've got a better understanding of it now. The problem is that the form is multi-level. The commerce_customer_address form bundle has some of the elements broken out further:

commerce_customer_address

->street_block
---->thoroughfare
---->premise
->locality_block
---->locality
---->administrative_area
---->postal_code
->country
->name_block
---->first_name
---->last_name

The way this worked originally, it just added all the elements again at the top level, giving you:

->street_block
---->thoroughfare
---->premise
->locality_block
---->locality
---->administrative_area
---->postal_code
->country
->name_block
---->first_name
---->last_name
->thoroughfare
->premise
->locality
->administrative_area
->postal_code
->first_name
->last_name

All I did in my patch above was put those extra elements elsewhere. I now realize that the one line of code:

$form['customer_profile_' . $type][$field][$langcode][$id][$profile_field]['#default_value'] = $default_value;

Simply sets the default values when you first load the checkout form. My patch above just prevents any default values from being set because they are assigned elsewhere, so it's a hack.

I have a new solution working that effectively assigns the defaults at the proper level and allows the checkout form to load with the defaults. I still have some work to do, so I'll post it once it's done.

Stay tuned...

I'm marking this as a duplicate because a correct fix for it has been implemented in #1280248: Add support to handle custom fields. Please test that issue.