Hi,

I have a view with an exposed set of filters in a block. In this instance it is to narrow down results for sets of properties.

For the price field on a property I have used number format - this allows the admin to add a property with a price of say £200,000.

Now the tricky part comes with the exposed filter for this.

Everything works great - but i have two filters that allow sorting according to a price range.....

(£) Min Price
(£) Max Price

This works fine if you place the number in without any space or puncuation marks like commas. BUT lots of people instinctlively write either :

200,000 OR 200 000

In both of these cases the filter then breaks - it essentially reads it as follows when it builds the URL to post back :

200,000 = &price_max=300%2C000
200 000 = &price_max=300+000

Worst case scenario is to make a note saying not to write prices this way - but people still do.

My php is pretty rubbish, I can work my way around the stuff - but dont know where to start to solve this issue.

Can anyone help?

Thanks
Jan

Comments

dawehner’s picture

dawehner
Primary language German
commented

I think a good way would be to add a validation function to views_exposed_form and then change the value of the field, so support the right type of stuff. To give "," or " " with the url you would have to use http://php.net/manual/en/function.urldecode.php

merlinofchaos’s picture

merlinofchaos commented

Might be worth putting this in the CCK queue, because this could actually be a nice feature for the widget that handles numbers to automatically remove obvious separators from the numbers.

The actual syntax to clean a string into just a numeric would be this:

  $string = preg_replace('/[^0-9]/', '', $string);
lodey’s picture

lodey commented

Thanks merlinofchaos - great to know that snippet now. I actually got round it in the end by over riding the form and replacing the inputs with select options. Not ideal - but worked. A nice little filter where you could opt for seperators to be removed would be great - hopefully someone will pick it up.

I have posted this in the cck queue.

czeky’s picture

czeky commented

Hi, I'm interested in this as well, my customers often enter comma instead of dot in decimal exposed fields and it gives different outputs..

Thanx in advance

esmerel’s picture

esmerel commented
Status: Active » Closed (fixed)

Issue was reposted in CCK queue.

rhoyerboat’s picture

rhoyerboat commented

Yeah, nasty hack, but, since I won't be the last person searching and being able to live with it:

On line 521 of views/handlers/views_handler_filter.ing

- $this->value = $value;
+$this->value = str_replace(',','',$value);

No searching for text strings that demand a comma match though. Need to check for numeric field-type somehow, at least, if not the existence of a user defined rule someone would have to define somewhere, someday. /shrug

Edit:
Oddly enough its still matching long non-numberlike comma bearing strings. Now I'm lost.

jsheffers’s picture

jsheffers commented

Is there a link to the issue in the CCK Queue? I'm still having this issue, and was wondering how to get around it.