Comma in selector value

[Roope]

Hello all!

I have a little problem with getting find selector to work with site data. My customer needs advanced search form for products where one of desired filter option is getting data from page text field. Problem is that some pages have commas in field value that breaks my selector string.

Striping of comma and rest of the string and then use ^= as operator would be one choise but then there are lots of not exaclty matching results that my customer want's to avoid.

Another solution would be of course to create pages for actual data and then use Page fields to attach it to product pages. This is how it's done with many other fields on product page but we selected text field for this one because there is actually so many variations and many variations belong only to one product.

So is there any handy workaround for this or do we just have to deal with not so precise search results?

[Wanze]

Hi Roope

Always use:

$selectorString = $sanitizer->selectorValue($stringWithCommas);

Pw sanitizes the selector string e.g. quotes it when there are commas present.

[Roope]

Ahh.. I didn't know that value can be quoted like that. Works nicely. Thank you very much Wanze - again!

[Roope]

Is there a reason why plus sing is removed by $sanitizer->selectorValue - I can't see it been used anywhere in the docs?

I'm just thinking cause those sanitized text fields actually had + sings and now values don't match.

[Wanze]

No idea why the '+' sign is removed. It happens here:

// disallow some characters in selector values
// @todo technically we only need to disallow at begin/end of string
$value = str_replace(array('*', '~', '`', '$', '^', '+', '|', '<', '>', '!', '='), ' ', $value);

[Soma]

It's not clear from your description what you're doing here. Couldn't you just use id's or some values that have no "special" chars? As I understand it's not something the user enters to search, but used to filter behind the scenes? So I don't see a need to have values with comma and + chars.

[Roope]

If + sign has no use in PW operators maybe it should be left untouched? There are many cases where input value could have plus sign in it, like phone numbers for example.

In my case advanced search form has select options and checkboxes and values come from PW pages. When user changes options, we create selector string from post data and display result count (and finally output results when form submit is clicked).

With this text field we basicly get every page that has value in it and strore values to temp array and remove duplicates by array_unique(). Then we create options/checkboxes from this unique data. I don't know any better solution for this.

[Soma]

If + sign has no use in PW operators maybe it should be left untouched? There are many cases where input value could have plus sign in it, like phone numbers for example.

In my case advanced search form has select options and checkboxes and values come from PW pages. When user changes options, we create selector string from post data and display result count (and finally output results when form submit is clicked).

With this text field we basicly get every page that has value in it and strore values to temp array and remove duplicates by array_unique(). Then we create options/checkboxes from this unique data. I don't know any better solution for this.

I'm still not seeing through what exactly you're building. What text field / What values... I'm sure you could build this different with using id's, names or some clean values used for options in the form. But maybe I'm wrong because I don't see the whole context.

[Roope]

So basicly we have product pages and this advanced search filters result from them. Product page has many fields in it (like color, material, socket). Most of fileds are Page field type so dealing with this kind of data is no problem. Then there are couple on text fields in product page (like socket) and we need to use data from these text fields also as filter in our advanced search form.

Some example data from product pages 'socket' text field:

• E27
• E27+PowerLED
• GU10
• 2G11

Then we create checkboxes from this data:

<label><input type="checkbox" value="E27" name="socket[]"> E27</label>
<label><input type="checkbox" value="E27 PowerLED" name="socket[]"> E27+PowerLED</label>
<label><input type="checkbox" value="GU10" name="socket[]"> GU10</label>
<label><input type="checkbox" value="2G11" name="socket[]"> 2G11</label>

If user would have then selected all these as filter in advanced search form, our selector string would look like this:

socket=E27|E27 PowerLED|GU10|2G11

And now you can see that our second socket data fails to match since + sign is removed by sanitizer.

[Soma]

Ok now it gets more clear. Couldn't those sockets be page fields?

 

Well anyway, you don't have to use sanitizer selectorValue(). Just wrap them in 'value'.

$pages->find("field*='E27'|'E27 + PowerLED'|'GU10'|'2G11'");

I'm not sure why + is in the sanitizer filter, but if you have to sanitize it coming from forms you could use $sanitizer->text().

Edit: Corrected example

[Roope]

OK, so maybe I just wrap values manually and forget sanitizer here. Sounds like easiest option.

Page field would of course be the best solution for 'socket' but customer wanted text field for some reason so we have to deal with that. There's also lots of overhead when you have to get all data from actual product pages compared to that there would be individual pages for each socket type to be used as Page type 'socket' field.

[horst]

Hi, I have search results that I do not understand.

It could be that a plus-sign is entered into the searchfield, for example: a+m Architekten

When using $sanitizer->selectorValue the plus-sign is stripped, therefor I try using $sanitizer->text, but it doesn't match.

The query looks like:

$suchFelder = 'headline|beschreibung|stichworte|architekt.title|kategorien.title';

$q = $sanitizer->text($input->get->q);
$input->whitelist('q', $q);

$matches = $pages->find("{$suchFelder}%=$q, limit=50");

But it should match with architekt.title.

Other queries, without a plus-sign, do find all pages/records:

• a-z Architekten
• ABB
• BRT
• Atelier Markgraph

Edited February 5, 2014 by horst

[ryan]

Roope, PW's sanitizer functions are intentionally aggressive as they are aimed at dealing with user input situations. But you don't have to use them if they don't fit your need. In fact, if this is not something dealing with user input, then I would just not worry about the sanitizer and just wrap your values in quotes (unless your values also need to match quotes).