It would be nice if other modules could alter the values before geocoder attempts to geocode them.

This patch adds a drupal_alter hook which does just that.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

beeradb’s picture

beeradb’s picture

Status: Active » Needs review
Brandonian’s picture

Status: Needs review » Fixed

Thanks for the patch, @beeradb. Looks good, committed.

http://drupal.org/commitlog/commit/27950/8e531f4dc6a8224a9dac978397fbfba...

Status: Fixed » Closed (fixed)

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

Robert_W’s picture

Issue summary: View changes
FileSize
698 bytes

The patch works, but I had to combine several fields of the entity before geocoding them. The current patch doesn't give you access to the entity object, so I modified the patch to include the entity object so that you can access fields other than the source field.

I created the patch from the 7.x-1.2 version (latest stable at the moment) because that's the version I'm working with.

Robert_W’s picture

Status: Closed (fixed) » Needs review
_wdm_’s picture

It also seems like a good idea to have a hook in the geocoder function.

rudiedirkx’s picture

Status: Needs review » Active

I know nothing about the geocoder() function (or its alter), because I've never used it.

I think the geocoder_geocode_values alter is 'wrong', because if you need the entity, you should make your own virtual encodable field. That's why #2159925: Geocode from virtual fields/entity property instead of just real fields exists.

@_wdm_ You should probably create a new issue for that alter.

  • Brandonian committed 8e531f4 on 7.x-2.x authored by beeradb
    [#1996592] - Alter hook for processing data before geocoding
    
Pol’s picture

Status: Active » Closed (won't fix)
AdamPS’s picture

Status: Closed (won't fix) » Closed (fixed)

It looks to me like the issue was fixed and the wrong status was picked by mistake.