When creating a directory view for my website, I have several options to filter the directory by - proximity, owner name, business name, business activity. All of these exposed filters are set to optional, but the view will return no results unless a value is filled out for proximity to the zip code.

I have a site in 5.x that works just fine with zip code being an optional exposed filter. Does this not work the same way in 6.x, or have I set it up incorrectly?

Form mode is postal code (assume default country), proximity circular, and the "optional" checkbox checked. I get results only when the zip code is entered, so it seems to me its not actually optional

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Sansui’s picture

Status: Active » Closed (fixed)

Not sure why it started working. Maybe happened after a cache clear, but w/e... now it does work as an option instead of a requisite.

ryan88’s picture

I had the same problem, but you have to delete the default search radius, otherwise it is expecting a zip code and won't work without one. This does suck a bit, because it is another step that users have to do in order to search.

jhedstrom’s picture

Status: Closed (fixed) » Needs work
FileSize
507 bytes

The attached patch fixed this for a specific use case, but I'm sure it breaks others, so I'l leave this at 'needs work'.

Cyberwolf’s picture

Subscribing.

YesCT’s picture

Status: Needs work » Postponed (maintainer needs more info)

Please check to see if this is still a problem in the new release. If it is, reply with a new summary and set the status back to needs review probably.

gstout’s picture

Status: Postponed (maintainer needs more info) » Needs work

This is still an issue. I'm no expert but it seem the issue lies in the logic. If no zip code it set but a distance is, proximity assumes it should display nothing(ie a hundred miles from nothing specific is nothing).

While this might logically make sense it isn't what users expect. If they have not completed a filter they expect to see ALL results. (until I fill in the zip I expect to see all results). This means that a default location view on a page using this filter will show no results, which is unlike all other filters that show all results until a filter is applied.

In addition if a user fill in the just the zip but not the distance they also get nothing. What they should get is just a list that starts with closest and just goes on from there. (Perhaps with a default distance being set in the view filter setup.)

If we could fix these logic issues I think this will be incredibly power. I wish I was a solid enough coder to do it myself but looking at the code quickly made me conclude that I am not. :)

Sansui’s picture

Coming back to this thread much later, to give some agreement to gstout :)

I'm building a set of custom forms now in a module, so that I can modify my exposed filters. When a user specifies a zip code but no value for distance, no results are shown, as well as vice versa.

Is there perhaps a modification that could be made to set either postal code or distance back to empty if both values are not set? This would force expected behavior of showing all results

not_Dries_Buytaert’s picture

Same here: No results, if I leave the value blank/ empty of the exposed (circular) proximity filter.
Running: drupal-6.19, location-6.x-3.1 and gmap-6.x-1.1

I think that this was/ is being discussed here too: http://drupal.org/node/817100

rambo2000’s picture

I was having the same problem with an exposed 'search_distance' field. The patch from #3 works when you change the fieldname to the one you are using.

joelstein’s picture

Status: Needs work » Needs review
FileSize
428 bytes

This patch works for me.

dww’s picture

Version: 6.x-3.1-rc1 » 6.x-3.1
Assigned: Unassigned » dww
Issue tags: +Location proximity view, +location proximity view zip code, +proximity search
FileSize
1.26 KB

I ran into this same problem and #10 works for me, too. If you set the exposed filter to optional, the default fills in 100 miles in the distance field but leaves the zipcode and country blank. So, by default, you get the bogus "// Hmm, distance set but unable to resolve coordinates." case that this patch removes. If there are no coordinates, don't force the query to fail. Only add a constraint if there are coordinates.

I agree with gstout's assessment in #6 that it's weird if you have a zip but no distance you also get no results. However, given how views works, I think it would be a mistake for the proximity *filter* to worry about the sort order. Therefore, we should treat distance == 0 just like the distance being unspecified which should mean we don't touch the query.

I've attached my patch for this which is working fine in my testing. However, since it's my own patch, I'd like to get bdragon to review/comment before I commit.

Thanks!
-Derek

joelstein’s picture

Status: Needs review » Reviewed & tested by the community

#11 works for me.

not_Dries_Buytaert’s picture

The patch in post #11 worked for me. Thx!

If the distance is unknown/ unset AND (!) the exposed filter is set to "User's Latitude / Longitude (blank if unset)", then there is no point in showing (bothering the user with) the 'Distance' input field of the exposed distance filter. This had been reported here, but is very related to this issue (and thus hopefully easy to fix and release simultaneously with this patch): http://drupal.org/node/915738

Cyberwolf’s picture

I think the patch is not correct as it does check if the distance is empty or not, while IMHO it shouldn't care about the distance at all.

In one of our clients' case, they do not want the user to be able to fill in a distance, only a postal code. So with a hook_form_alter() we changed the #type of the search_distance field to 'value', so they have not the possibility to change the distance, and instead always the default distance specified in the Views filter is used.

However with this patch, if no postal code is filled in, no results will be returned because the distance value is there. IMHO there should be no check against the distance, so that if no postal code is filled in all results should be returned. IMHO the distance should be only a modifier if the postal code is filled in.

Cyberwolf’s picture

Status: Reviewed & tested by the community » Needs work
dww’s picture

Status: Needs work » Reviewed & tested by the community

@Cyberwolf: I believe you misread the patch. If either the distance or the zip code is empty, the filter immediately returns, the query is unmodified, and all search results would be returned. With #11, the only way for the filter to modify (restrict) the query is if *both* the distance and the zip code are defined.

not_Dries_Buytaert’s picture

Status: Reviewed & tested by the community » Needs work

In hind sight and in contrast to my post #13, I believe that issue http://drupal.org/node/915738 should be fixed too, when committing this patch.
What it comes down to is that IF the distance field or user location is unknown, THEN the distance field as an exposed filter shouldn't be displayed.
Releasing the patch of post #11 without solving aforementioned (probably quite simply to fix) issue 915738, would not make sense (just be 'bureaucratic').

BTW: English is not my native language. So sorry for my bad choice of words.

dww’s picture

Status: Needs work » Reviewed & tested by the community

@not_Dries_Buytaert: These are separate issues. This patch doesn't assume user locations at all, nor address the UI of how someone picks a location to filter with. This is simply about how the underlying filter should modify the query based on what values the filter is given. Instead of trying to wait for a giant patch that fixes every aspect of proximity search, let's keep the separate issues separate so they can each be solved with the smallest (easiest to review and test) changes possible. This is not bureaucratic, it's (usually) a better way to get things done. Keep the individual tasks as small and focused as possible.

Thanks,
-Derek

not_Dries_Buytaert’s picture

@dww: Ok, I see. I thought they where tightly related, but have to admit that I lack the technical knowledge to pinpoint the root causes of both issues. So, I have undone the status change of the other issue. Sorry, for any inconvenience.

Cyberwolf’s picture

@dww: my apologies, you are right. I guess the patch was not applied properly on our test installation and therefore I got other results with it.

rooby’s picture

Status: Reviewed & tested by the community » Fixed

I agree, if we are missing coordinates OR distance the filter should not touch the view.
And yeah, I have seen a couple of other bugs in this area but they outside of this issue.

Committed to 6 & HEAD.
http://drupal.org/cvs?commit=429452
http://drupal.org/cvs?commit=429458

geerlingguy’s picture

Adding to my tracker.

Status: Fixed » Closed (fixed)

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

milehighlife’s picture

I'd like to use the proximity exposed filter in a different way...

1. I want to give a default value to the distance input (was able to do this with a preprocess function)
2. I want to hide the distance field from display (was able to do this with preprocess function)
3. If a zip code is not entered, I want the view to display all results (set the distance input to 'empty').

I'm stuck on #3. I'm assuming a bit of javascript onSubmit() could help me check the value of the zip input and then reset the distance field but not sure where to start on this. Has anyone else had this issue?