?paramand the search issues a warning message:
Warning: preg_match() [function.preg-match]: Compilation failed: nothing to repeat at offset 0 in /home/piwik-demo/www/demo.piwik.org/core/DataTable/Filter/Pattern.php on line 72 Backtrace --> <a href='/0'>#0</a> Piwik\Error::errorHandler(...) called at [:] <a href='/1'>#1</a> preg_match(...) called at [/home/piwik-demo/www/demo.piwik.org/core/DataTable/Filter/Pattern.php:72] <a href='/2'>#2</a> Piwik\DataTable\Filter\Pattern::match(...) called at [/home/piwik-demo/www/demo.piwik.org/core/DataTable/Filter/PatternRecursive.php:80] <a href='/3'>#3</a> Piwik\DataTable\Filter\PatternRecursive->filter(...) called at [/home/piwik-demo/www/demo.piwik.org/core/DataTable.php:425]
Warning: preg_match() [function.preg-match]: Compilation failed: nothing to repeat at offset 0 in /home/piwik-demo/www/demo.piwik.org/core/DataTable/Filter/Pattern.php on line 72
* which caused the same warning.
The side effect is that you could no longer write a regex in the search box like
(nn)+ since the
+ would be escaped to
(nn)\+. I am not sure if this was actually a feature and meant to be like this? If so, we could probably only escape those characters if it is the first character. Since less users are aware of regex I would assume people would rather want
+ to be interpreted as
\+ as it is the case now
I am not sure if this was actually a feature and meant to be like this?
it is a feature to let users write regular expressions in the search bar (and in API request via
filter_pattern), eg. you can search for
(en|de)\.wikipedia (and any other regex including
do you know if it's possible to detect whether a given search string is a regular expression or not?
(if we could detect this, then we could enable regular expression only when input string is indeed regular expression...)
I wonder how Google Analytics handles this case. After doing some quick test it seems their datatable search input box works with both regular expressions and simple search. For example if I search for
+ then it returns all URLs containing + character. But if I input regular expression containing
+ it still work as regular expression.
Maybe the best solution is to:
and then we could return the "union" of both searches?
As mentioned above I would only escape the first character if it is a quantifier in this case. I think it is very tricky to detect it otherwise. Checking for brackets on the left or right or so wouldn't work since even
jpe?g is valid.
I don't think executing a pattern twice is the best idea since a user might get results that he doesn't want. Autodetecting/magic can be very annoying in case the auto detect does not work correctly in a case and you will never know which result you get.
Documentation says nothing about regexp:
filter_pattern; defines the text you want to search for in the filter_column. Only the row with the given column matching the pattern will be returned.
Maybe we should mention it there and then it is ok. For API users which are usually advanced users this behavior is ok. Best case would be maybe to have two different attributes (
filter_text for instance). This would be clear.
For regular users that use the UI I would personally prefer not to apply a regex by default and treat it as text. IDEs and text editors solve this problem by having a checkbox "Regex". But this makes the UI more complicated again. A solution could be to force advanced users to write regex within a leading and ending slash
/$myRegex/ and show this as a tooltip on hover (title)
I'll close it for now as it fixes the reported issue. Maybe we can otherwise open a new ticket if needed?
maybe we could mention regex in the API documentation for
otherwise looks good to me
I did it this morning see previous commit ;)