Closed (fixed)
Project:
Commerce Addressbook
Version:
7.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
14 Oct 2011 at 17:23 UTC
Updated:
10 Jan 2012 at 08:40 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
wjaspers commentedI believe the source of the problem stems from this function:
Cause of problem is here, in commerce_addressbook_get_saved_addresses:
Profile ID is only available to commerce_customer_profile Entities. Why not sort by something on the address?
Looks like this block could be improved, too:
commerce_addressbook_get_bundles_with_field.
In this block of code:
Comment #2
wjaspers commentedPatch available.
I'm sure this can be improved, too, but simple enough.
Comment #3
Spindles commentedFurther to the problem above I was still getting errors even with the above patch.
To remedy the issue I have modified commerce_addressbook_get_bundles_with_field() to only use bundles where the bundle_name is 'billing'.
Patch provided.
Comment #4
wjaspers commentedDon't restrict the bundle to just "billing" profiles.
The purpose of Addressbook is to allow any addressfield on any source owned by the current user to be made available.
This would be especially troublesome for people wanting to be able to select "Shipping" profile addresses if the bundle type is restricted.
If you were still seeing errors, please report them here.
Comment #5
Spindles commentedWithout the 'billing' restriction this is the error I'm getting:
PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'commerce_option.uid' in 'where clause': SELECT commerce_option.option_id AS entity_id, commerce_option.set_id AS bundle, :entity_type AS entity_type, NULL AS revision_id FROM {commerce_option} commerce_option WHERE (commerce_option.uid = :db_condition_placeholder_0) AND (commerce_option.status = :db_condition_placeholder_1) AND (set_id IN (:db_condition_placeholder_2)) ; Array ( [:db_condition_placeholder_0] => 37 [:db_condition_placeholder_1] => 1 [:db_condition_placeholder_2] => advert_general [:entity_type] => commerce_option ) in EntityFieldQuery->execute() (line 1119 of /var/www/vhosts/marketing.dev.timberwindows.com/drupal/includes/entity.inc). Backtrace:Now I haven't been involved in the development of this site from the start, but from what I can figure out the addressfield is being used with Commerce Product Option to insert an address into an order for advertising space. When the module is grabbing the details of the option it doesn't contain the correct fields.
Maybe modifying the function header to add a parameter for bundle name might work?
Comment #6
wjaspers commentedAre you attaching an AddressField to a product or to a Node (being used as the product display)?
If you have the commerce_option module enabled, I think this is where the PDO error (in your case is stemming from). If you have other errors (or something with a nearby timestamp) from your DB log, it may help, too.
Comment #7
Spindles commentedNothing else in the dblog I'm afraid.
The AddressField is part of a product option set which is then attached to a product rather than a product display node.
Comment #8
wjaspers commented@Spindles, creating a simple if() check against entities/bundles works, but what we may find is that we'd need to create one for every instance where it breaks. ...
Possible solutions:
1. A settings page for "Commerce Addressbook" could allow the site admin to select which Entities / Bundles to pull Addressfield data from.
2. Force commerce_addressbook to only work with customer_profile entities (Known bundles: billing profile, shipping profile, etc...)
3. Add some kind of hook_info_alter() to an API, and expect that modules which want to supply Addressfield data will indicate so...
Comment #9
rodych commentedI attach address field to user profile and have PDO error
Comment #10
Humphreybas commentedI just installed commerce addressbook and got the PDOexception when checking out. Tried to apply the patch but got 'error: No changes' was found (I guess it was already commited to the git?). Anyone knows how to proceed?
Comment #11
wjaspers commented@Humphreybas, The patch in #3 isn't in a git format or p0 format, so it likely will not apply as easily as others.
Perhaps the answer is just to provide an admin settings form that lets the addressbook define its sources...
Comment #12
tscadfx commentedI've corrected some of the code and made a git patch. Hope this helps some of you out. Let me know if you notice any issues with it and I'll work on fixing them. It works in my environment as is with extra fields.
Comment #13
tscadfx commentedUse this patch instead. Sorry
Comment #14
tscadfx commentedI really should have been in bed hours ago. I swear this is the final version of the patch and the one that should be used.
So sorry!!!
Comment #15
Anonymous (not verified) commentedPatch from #14 works for me.
Comment #16
svendecabooterPatch #14 was now committed, minus the last change (add an if clause for billing addresses) for the reasons specified by wjaspers.
Comment #17
svendecabooterAfter some further investigation, the errors make sense.
We are fetching all addresses that belong to a specific user. Though this currently most likely only makes sense for addressfields that were attached to customer_profiles, since those have a user ID. If you were to attach an addressfield to a random entity type that doesn't have a relationship with a user, this results in all kinds of odd behavior and errors.
So I changed the code to focus on customer_profiles right now, and perhaps user entities later on, but leave all other entities alone (unless someone explicitly would add support for it).
That will solve this issue in the upcoming first release of this module.
Comment #18
svendecabooter