< Skip ahead to the bolded sentence. >

I've sent myself on several wild goose chases and came full circle to where the code is good as it is. But in order to save my own pride, I need to create an issue anyway :-p

Thing is this:

I fooled myself into thinking that it is commerce_addressbook which should take care of duplicating profiles after changing them. (Which obviously isn't true; it's usually commerce_order which takes care of this. I didn't spot this and misread my test results.)
So, after creating and ditching a patch that 'solves' a non-existent data corruption issue on the checkout page... and then one that 'fixes' code duplication that was't real duplication... I'm left with this

this patch does the following (which doesn't matter much in practice):

  • puts extra comments near "make sure it gets duplicated" (because IMHO the comment is misleading: 'it' would get duplicated also if this code didn't exist. And casual code readers like me don't know about commerce_order_form_commerce_customer_customer_profile_form_alter().)
  • a change in setting a #submit property which would prevent the submit button from ceasing to work if another hook_form_alter() ever set $form['actions']['submit']['#submit'][] sometime in the future;
  • add TRUE parameter to in_array(). (I suspect the whole in_array() can be deleted, but I'm too chicken for that. So instead I fix a creepy theoretical bug because in_array('addressbook', array(PANE_ID, 'field_commerce_address', 0, 'country')) yields TRUE.)
Support from Acquia helps fund testing for Drupal Acquia logo