User-entered location into exposed proximity filter doesn't work #1

adamdicarlo opened this Issue Aug 29, 2011 · 15 comments

2 participants


When the user enters a location into the exposed filter (Great circle) form, the proximity filters don't affect view results. That is, nothing is removed from the nodes selected by the view.

The only way I've been able to make the filters do anything is by typing a geocodable address into the "Location" field on the exposed filter's Views configuration form (set the default value). Load up the view from the front end, and certain nodes get filtered out, and the "Proximity: Distance" field actually shows distances. Then change the exposed location filter from the default value to another address, and submit. No nodes are removed, and the Proximity: Distance field is blank for every node in the view.

I've stepped through the Views plugin in Eclipse some, also did some dpm() debugging, but the only thing I feel confident about having determined is that the geolocating is happening correctly (even with the user entered value in the exposed filter).


Hey, what version of views are you using?


Drupal 7.7, Views-7.x-3.0-rc1.


can you export your view in a gist?

@jpstrikesback jpstrikesback reopened this Aug 30, 2011

Wait, are you trying to view results at the view preview? There are some issues blocking that in rc1...I'll try to find them and link to them. Please try with exposed filters on the actual view page without Ajax refresh and let me know how you fare


No, I'm not trying to view results in the Views preview. I'm doing it on the actual page view. The filters are exposed in a block -- is there any issue with that?

I'll get a gist of the view up soon.


Here's the view:
Here are relevant entries from my Drush makefile:

Also: Thanks for taking a look.


Been doing more debugging.

openlayers_proximity_handler_filter::op_process() gets called when I initially bring up the Views page. It works great.

I type something into the exposed Location field (actually I'm pasting in the exact same address as the default value configured within the views interface). I hit submit and the page refreshes with this URL:

Looks fine, but again, the filter is useless when this page loads. (**Edit:** and ```openlayers_proximity_handler_filter::op_process()``` does not get run!)

Here's where it gets interesting: I manually edited that URL and loaded this instead:

**and it works like a charm**. So somehow the non-exposed operators and ranges that are getting put into GET are screwing something up and causing the crucial function not to even get invoked.

So the circle value field (the number of km/mi within which to search) despite having a default value of 20 configured, is being output with no value:
<input type="text" id="edit-circle-value" name="circle[value]" value="" size="3" maxlength="128" class="form-text">

I believe this is the cause of the problem. When the form is submitted with circle[value]="" the filter's part of the Views query isn't included (so literally, the filter has no effect). But when the form is submitted without that parameter (if I manually remove it from the URL query), then the default value of 20 must get used, and the filter works.


I'm also using Addressfield, forgot to include it in the drush makefile excerpt:

; Address Field
projects[addressfield][subdir] = "contrib"
projects[addressfield][version] = "1.0-alpha4"
projects[addressfield][patch][] = ""

It's not the latest version. I think I tried the latest version too, at one point. Given what I've seen while debugging I don't think that matters.


I found the line of code that was unsetting the circle[value] input field, removed it, and the filter's working great for me. I've submitted a pull request, mostly because that's the way to submit patches on Github -- that is, I'm hoping you'll see what's really wrong with the code and come up with a more logical fix (I don't understand Views filters quite well enough to know if my fix is "right").


Well, definitely not the right fix. Because once I take out the default Location value from the exposed filter config, the filter again doesn't affect the results at all.

Will try latest Views dev snapshot now. Do the versions of all the modules in my makefile snippet look OK? (Are you using a different fork/port of any of the modules?)


Whoops. I was too hasty saying I had it working.

It's always using the default location/from value for the proximity filtering. Even if I type a different value into the exposed filter.

I've tried upgrading to Views from git, even recreating the view, to no avail.


ok, while I haven't had too much time to investigate (sorry) I've narrowed it down to exposing the operator for "less than", "greater than", etc...will continue over the weekend. (try exposing the "operator" and you should see what i mean)


OK, test the latest commit, this should be fixed for exposed filters

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment