Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I noticed several older issues with similar titles, but this one is separate and does need to be solved by Address Field, AFAICS.
Since the release of 7.x-beta5, this code:
$profile_id = ID_LAST_SAVED_PRE_BETA5;
$profile = commerce_customer_profile_load($profile_id);
$profile->status = 0;
commerce_customer_profile_save($profile);
Will not actually change the status of $profile, but will create a copy with status=0.
One effect is that commerce_addressbook_customer_profile_form_submit(), if (!empty($profile->previous_id)) {, does not disable the existing profile but creates two new profiles, of which one enabled and one disabled.
Reason
commerce_order_commerce_customer_profile_presave() thinks the address field in the loaded profile is different from the one it's going to save, because
$original_itemdoes not contain the 'name_line' item- and
$itemdoes. (It's just been filled by addressfield_field_presave().)
Possible fix
...in the patch: populate name_line on load. Note I'm not too exerienced with the Field (Attach) API and it's hard for me to see what the exact intended meaning of all those hooks are, and if this is the best solution. I figured hook_field_load() is meant for completion of fields because text_field_load() does basically the same.
| Comment | File | Size | Author |
|---|---|---|---|
| commerce_addressbook-fix-profile-dupes.patch | 901 bytes | roderik |
Comments
Comment #1
torgosPizzaHaving this same issue when migrating from Ubercart to Commerce (Kickstart). Each order ends up saving a brand new billing profile and that ends up making things look horribly broken. Will test this patch with Migrations to see if that works.
Comment #2
jsacksick CreditAttribution: jsacksick at Centarro commentedThere are several ways of fixing this I guess, we could also write an update hook that will just update the "name_line" column directly in the DB, or actually update the comparison performed in Commerce to ignore the "name_line" (this option is probably dirtier though).
However, I think the patch looks good but I'm wondering if it's still a necessity to commit it after all these years.
The reason for that is that the patch is targeting address fields that were saved prior to the the Addressfield beta5 release which is now 5 years old...
On the other hand, if you're updating the Addressfield module now and have thousands of customer profiles, each time a profile is saved, it could potentially be duplicated because of the "name_line" comparison.
So in short, I think the patch can be committed as is, but will probably now have a limited impact (It's not useful on new sites, or installs post beta5).
Comment #3
jsacksick CreditAttribution: jsacksick at Centarro commentedI was able to confirm the patch is working by emptying manually the name_line column in the field_data table.
As explained by roderik, prior to the patch, simply loading and saving the profile (with no name_line) triggers a profile duplication, the problem is indeed gone with the patch.
Let's get this in.
Comment #6
bojanz CreditAttribution: bojanz at Centarro commentedThank you both!
Comment #7
roderikThank you - this reinforced my faith in filing documented reports with patches :)