I have a Location CCK field attached to Users. I want to do a User proximity search in a view. But it fails, because the locations attached to my users look like this:
http://f.75th.me/image/161c2t3Z3V1T
Certainly those first three columns should be inverted; the nids and vids should all be zero, and the uids should be 10, 11, and 12. Manually making this change to the database makes the search work beautifully.
Clearly the ideal thing would be to redesign the module so that Location filters are specified by field like everything else, rather than just by node or user the old way. But in the meantime, some logic to fill out these database entries correctly would be welcome. I don't have time to dig into it right now, but maybe next week sometime I'll take a crack at it, if no one else does first.
Comment | File | Size | Author |
---|---|---|---|
#10 | location_cck-remove-vid-1962852-10.patch | 993 bytes | jeroenmarinus |
Comments
Comment #1
KLIGGS CreditAttribution: KLIGGS commentedIt took me some while to track down why no "Bubbles" are shown on the gmap, by analysing the SQL Commands.
Open the file modules/location/contrib/location_cck/location_cck.module
Find the HOOK location_cck_field_update at line 178
Just extend the ARRAY with the code:
'uid' => $entity->uid,
The final function should look like this:
Remember an update overwrites your changes unless this bug is not fixed.
Comment #2
cgreenoh CreditAttribution: cgreenoh commentedThis issue affects my site as well. We're using views to display a report of users who match a given location field (Country, Province) and because uid is now being set to 0, the views query fails to pick up users
We started with location 7.x-3.0alpha1+1 which appears to write two entries per user in the location_instance table:
After upgrading to location 7.x-3.0alpha6 (to resolve the Google location API error), only a single row is entered for the user:
This problem extends to the current location7.x-3.0alpha9 (I have tested). The suggested workaround in this post fixes the issue, but only AFTER a user has updated their profile (obviously). Older entries are not picked up without manually updating the data by duplicating the vid > uid, then views can correctly fetch the data from the location table.
My views query looks like this (I added in the name field for context):
The base issue here is that uid is being written as 0 into location_instance, and views is looking to the uid column in location_instance to fetch the corresponding data from the location table.
Looking for thoughts on this issue.
Comment #3
decibel.places CreditAttribution: decibel.places commentedrolled a patch adding
'uid' => $entity->uid
for insert and update(which creates a problem in location_chooser : Notice: Undefined index: title in location_chooser_form_node_form_alter() (line 163 of /var/www/caal-dev/sites/all/modules/location_chooser/location_chooser.module). I will check that module next)
Comment #4
decibel.places CreditAttribution: decibel.places commentedRegarding
Why not write a SQL query that would update location_instance.uid = profile.uid WHERE location_instance.nid = profile.pid ?
I don't need it because I am building a new site, there isn't old data
W3Schools reference on SQL JOIN
Comment #5
podarokdue to #3 this patch introduce new bug so please create follow up with bug fix or just fix introduced bug inside this one
Thanks!
Comment #6
decibel.places CreditAttribution: decibel.places commentedI also submitted a patch for location_chooser fixing the bug in #3
#2051529: notice when looking for 'title' on profile2 node
it does not affect the patch submitted here, it popped up because of new data made available with the fix in #3 for Location
the patch in #3 has been tested, it should be good to go - or are you saying that the dev version has a new bug with this patch?
Comment #6.0
decibel.places CreditAttribution: decibel.places commentedbad writing
Comment #7
jeroenmarinusI did some research and came up with this patch. The problem with the patch in #3 is that it doesn't tackle the real problem. The problem is that $id and $vid get populated with the uid of the entity because of the entity_extract_ids() method.
I'm not sure if this is a solution that covers all bases, but it works in all tests I did, and I can't see anything else that would need to be covered.
Please review this and provide feedback.
Comment #8
jeroenmarinusComment #10
jeroenmarinusDisregard the patch in #7. I did not apply it to the dev version and did not follow the guidelines for patching.
With correcting this, I saw that most of the work I put in my patch was already done in the dev branch. However, the patch I include now should fix the last issue. the vid was still filled in, which is wrong when dealing with users and can lead to user addresses being retrieved if nodes have the same vid as a uid.
Comment #11
podarok