I rearranged the order of the product attributes, and the attribute view filter on order product view no longer work.
Technically, this is what's happening:
This (in the view):
s:14:"Day of arrival";a:1:{i:0;s:6:"Sunday";}
Is being compared to this (in the database):
s:14:"Day of arrival";a:1:{i:6;s:6:"Sunday";}
The only difference is the i:0 and i:6. I think that's order, but I really don't know. Correct me if I'm wrong (I'd like to know).
This is the code where it all happens:
$var = array($key => array(0 => $optval));
$servar = serialize($var);
$l = strpos($servar,'{')+1;
$r = strpos($servar,'}')-$l;
$value = substr($servar,$l,$r);*/
$this->query->add_where($this->options['group'], "$upper(%s) $not LIKE $upper('%%%s%%')", $field, $value);
Personally, I think that's way too exact of a match criteria. I suspect 6 is the order, but I have no idea, really. What makes sense to me is to match the Attribute name and its Option name to what's in the DB.
So... I changed the above code to this:
$value = $key.'[^}]*'.$optval;
$this->query->add_where($this->options['group'], "$upper(%s) $not RLIKE $upper('%s')", $field, $value);
It works and with about 15 attribute filters seems to work fine. We'll see how mysql regex performance will hold up once there are hundreds of orders.
Any thoughts?
The attribute filtering now actually works, whereas before, it didn't for whatever the reason.
Cheers,
Andrey.
Comments
Comment #1
mr.andrey commentedActually, here's an even better way, so it matches the exact attribute and selection. "Car" won't get confused with "Car color".
In uc_attribute_views_handler_filter_attr.inc, replace:
with:
Cheers,
Andrey.