On /user/%uid/addresses page, I change the address, save it, and then it appears unchanged. In the uc_addresses table, there is new address, but it doesn't get loaded from there. In dbResultToAddress function of UcAddressesAddressBook class, the condition before loading from database reads if (!isset($this->addresses[$obj->aid])) which is never true. Address is instantiated before when user_load is called from serialized data of user table.

Comments

megachriz’s picture

megachriz
Primary language Dutch
commented

That's odd. Ubercart Addresses 6.x-2.x doesn't save data to the user table. Do you have any modules installed that depend or integrate with Ubercart Addresses?

Does this occur also with a fresh installation of Ubercart and Ubercart Addresses?

gease’s picture

gease
he/him
Primary language Russian
Location Praha
commented

Thank you for quick reaction.
I believe this happens when user_save is called upon user registration. It serializes user object and stores it in data field of user table. And if ubercart_addresses fields are compulsory upon registration, they make part of the user object that is serialized and saved.
So I think the right way of updating user's address is via saving the entire user object and employing hook_user to save data into uc_addresses table.

megachriz’s picture

megachriz
Primary language Dutch
commented

I can reproduce this behaviour. I was not aware of the fact that the address entered upon registering will become part of the user object and thus ends up in the user table. The address does end up in the uc_addresses table too, but the system is designed so that an address is only loaded once from the database. Because the user object is loaded first, the address he/she entered upon registration gets loaded from the user data and so the address book thinks "I already got this address, no need to load it again."

The address gets already saved via a hook_user() implementation (when $op == 'insert'). So the solution we should seek is to prevent saving the address in the user table in the first place. If you can find this solution, you're welcome to post a patch. Else, I hope to look into it next week.

Thanks for catching!

freixas’s picture

freixas commented

There seems to be something definitely screwy here. It does not make much sense to serialize objects into a database. Usually, object properties become database table fields.

Here's the description of the data field: A serialized array of name value pairs that are related to the user. Any form values posted during user edit are stored and are loaded into the $user object during user_load(). Use of this field is discouraged and it will likely disappear in a future version of Drupal.

The address is probably winding up in there because there is an address form on the registration page. I'm not sure how these values are used or who uses them. If they are not used by anyone, then it might be necessary to use one of the hooks dealing with saving the user data and unset the unused fields.

I suspect that in uc_addresses_pane_address(), the "process" case is the only one that uses the data. After the fields are processed, the data can be unset, although you'll have to find the data in the $user object and unset it from that. Unsetting the $form_values array obviously won't do anything useful.

megachriz’s picture

megachriz
Primary language Dutch
commented

@freixas
Hi Tony, this bug is about the 6.x-2.x version. The address may also wind up serialized in 6.x-1.x (I haven't tested it), but there it doesn't cause any real problems.

I'm busy with some other aspects of the module right now, particular with #396342: addresses in admin orders interface and documentation of the API, so I will look into this issue more closely when I'm done with that.

gease’s picture

gease
he/him
Primary language Russian
Location Praha
commented

Ok, here's the solution: you need to unset address property in the user array when hook_user('insert', ....) is called:

        $address->setAsDefault('billing');
        $address->save();
        unset ($edit['uc_addresses_address']);
      }
      return;

(file uc_addresses.module, line ~219).
I don't have all this stuff under version control, so formally rolling a patch is too much of effort for me, sorry.

megachriz’s picture

megachriz
Primary language Dutch
commented

@gease
I thought about this today (I've just read your post), and I was thinking too unset $edit['uc_addresses_address'] would be enough, because I realized that the address got in the user data with a valid address ID, and so the address winded up there after it was saved. I think your solution will be enough. I don't have the test environment right here now, so I will test it this weekend. No problem with not posting a patch in this case, I know what to change. Thanks for your efforts!

megachriz’s picture

megachriz
Primary language Dutch
commented
Assigned: Unassigned » megachriz
megachriz’s picture

megachriz
Primary language Dutch
commented
Status: Active » Fixed

When uc_addresses_user() is called with $op = 'insert', variables $edit['address'] and $edit['uc_addresses_address'] will be unset, so they will not be saved as user data in the user table. This should fix the problem. This fix is added to the 6.x-2.x-dev release of October 16, 2011.

If you think this does not fix the problem, feel free to re-open this issue.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.