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.
In hook_entity_presave()
a check is done to make sure the address has been updated before geocoding the address.
The check is done by comparing two address with $value !== $addresses[$delta]
.
This can give lead to false positives when:
- One array has empty entries not present in the other
- The order of the entries is different
In neither case is this an actual change in the address.
I am experiencing this in combination with the migrate module. When importing and updating addresses using the migrate module the order is different and not all properties are present vs empty.
Comment | File | Size | Author |
---|---|---|---|
#6 | geolocation_address_link-false_positives-2976496-6.patch | 1.89 KB | imclean |
Comments
Comment #2
arnested CreditAttribution: arnested at Reload commentedComment #3
arnested CreditAttribution: arnested at Reload commentedThis time the patch with proper code style...
Comment #4
imclean CreditAttribution: imclean commentedI'm having a related problem which could be resolved in this issue.
If there is an error with the initial geocoding due to incorrect API key, restrictions or network error, then the address may not change when it's edited. In this case, editing then saving entity won't try to geocode it again.
Changing the address then changing it back works around it, but it would be good to check if there are existing coordinates and always geocode if the location field is empty.
Comment #5
imclean CreditAttribution: imclean commentedThis adds the check for empty geolocation field.
Comment #6
imclean CreditAttribution: imclean commentedFix white space and add to comments.
Comment #7
arnested CreditAttribution: arnested at Reload commented@imclean, what if the address can't be encoded - not because of an error but because there is no coordinate to associate with the address?
Is there anyway we can distinct between "no coordinate" because "there actually is no coordinate" and "no coordinate because we haven't tried getting one / successfully got one yet"?
Comment #8
imclean CreditAttribution: imclean commented@arnested, I'm not sure that's likely to happen in this case. Address field requires a State/region and postcode at least. If Google can't find the specific address it'll respond with a point in the middle of the region. The only times we're not going to get that information is if the API key isn't valid or there's a communication problem.
Comment #9
arnested CreditAttribution: arnested at Reload commented@imclean, cool then I agree with your addition!
Comment #10
KarenS CreditAttribution: KarenS at Lullabot commented"Address field requires a State/region and postcode at least. ", actually it does not. It is possible to configure it without those fields and that is the way I use it. So we should not make that assumption.
Comment #11
arnested CreditAttribution: arnested at Reload commented@KarenS, good to know.
But the patch I made in #3 should still be fine, then?
Comment #12
imclean CreditAttribution: imclean commentedI can't remember now why I made that claim. Essentially my point was that if an address can't be encoded then Google still presents something.
Comment #13
imclean CreditAttribution: imclean commented@arnested, #3 doesn't take into account #4.
Comment #15
KarenS CreditAttribution: KarenS at Lullabot commentedLooks good to me, committed!