Allow the proximity filter to use a node argument's location as a center

tagging

Nice! Will there be plans to roll this into Location? Also, how difficult might it be to do the same but with the current user's location - this would be amazing.

Wowwie wowwie wowwie, can it be just this easy??? (I don't have the correct patch syntax, but here it is)

    // Do we have a User as an argument
    if ($this->view->display_handler->get_handler('argument', 'uid')) {
      $form['value']['use_user_arg'] = array(
        '#type' => 'checkbox',
        '#title' => t('Use the User Argument\'s location as the center'),
        '#default_value' => $this->value['use_user_arg'],
      );
    }

and

    if ($this->value['use_user_arg'] && $nodehandler = $this->view->display_handler->get_handler('argument', 'uid')) {
      $uid = $nodehandler->get_value();
      if ($uid && $tempuser = user_load($uid)) {
        $this->value['longitude'] = $tempuser->location['longitude'];
        $this->value['latitude'] = $tempuser->location['latitude'];
      }
    }

This is letting my views search filter key off of the user's "location" zip/postal code as the center of the radius. Beeyootiful! Thanks for "letting" me riff off of your work!!!

Shooot - it is working for my admin user, but not for other users regardless of permissions. I thought there might be an issue with some variable auto-resolving to uid '1' but there doesn't seem to be...

I even dump out the lat/lon codes to a log to make sure they are correct according to the user's location, and they are. But the view still returns an empty set.

Any idea why it would not be working for non-admin users?

I have tested location_views_handler_filter_proximity.inc_.node_arg.patch from #1 and got it working eventually.
Attached is the views export I used to get it to work. When a location enabled node is showing, a block will show nearby locations. Still pretty rough but the SQL works.

Attached is a patch that includes the one in #1 and also does the same kind of thing for user uids.

There are also two views exports attached, one that shows users nearby a user and the other shows nodes nearby a user, both in a block that only appears when the user profile is visible on the page. These are arguably not as useful as nodes near nodes as in #7 but might be useful for sites making use of user profiles.

The patch is on current dev which is where the action is ATM. If the patch in #1 works in rc1 then this one will too I imagine.

There is still a lot to do on proximity filter for location module but these two new features bring some usability into play. The form exposure facility in particular needs work but I for one haven't yet figured out how ;-)

Thanks Hutch!

Glad you like it ;-)
You can show nodes nearby a user but not users nearby a node, if anyone knows how to get that the set would be complete.

I'm currently trying to figure wtf is going on in #606342: Views Argument Handler for Proximity. Two different ways of achieving something similar but it's not at all clear what or where things are/go. Very messy.

Thanks for the patch.

I was updating it to apply over the patch in #718928: add options to set coordinates w/ user location, PHP code for field, filter and making a couple of other additions and it got a bit hard to manage so I added it to the patch in that issue. So 'I'm marking this issue as a duplicate of that one.

So please have a look at testing that patch if you can so we can get it in and get the next release out.

Found out it has already been committed (stable and dev). After upgrading the module, importing the View from #7 and just a little tweaking to adjust to my use case, I got it working in no time. Thanks a bunch.

See a working example.

sub

@ lolandese & dpatte:

Yeah, when an issue has it's status set to "closed (duplicate)" (see post #11) it means that there is another issue that is already addressing this problem/feature.

There will usually be a link to that issue.
You should follow that issue as nothing more will be done with a "closed (duplicate)" issue unless it is decided that the issue is not actually a duplicate and the status is changed again.

See http://drupal.org/node/156119 for more information on issue statuses.

Added the info for the next visitors of this issue.