Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pageUrl segment does not work with =@ contains operator #2727

Closed
mattab opened this issue Oct 20, 2011 · 8 comments
Closed

pageUrl segment does not work with =@ contains operator #2727

mattab opened this issue Oct 20, 2011 · 8 comments
Labels
Bug For errors / faults / flaws / inconsistencies etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Milestone

Comments

@mattab
Copy link
Member

mattab commented Oct 20, 2011

@mattab
Copy link
Member Author

mattab commented Oct 22, 2011

Reported in http://forum.piwik.org/read.php?2,84935

@anonymous-matomo-user
Copy link

Is there currently another way to achieve the segmentation behavior expected when using the pageUrl segment with the =@ contains operator? Thanks.

@timo-bes
Copy link
Member

(In [5719]) refs #2727 =@ and !@ for pageUrl / pageTitle segments

@timo-bes
Copy link
Member

The segmentation mechanism with callbacks was built for comparing against a single ID, which only works for == and !=. I tried to introduce dynamic SQL sub-expression with as little impact on the existing system as possible.

  • For LIKE matches (=@, !@), the callback of the Actions plugin returns an array with the index SQL. This can be discerned from regular literal values.
  • Segment recognizes the array and changes the match type to IN.
  • SegmentExpression recognizes the match type IN and injects the sub-expression. It marks the value as null because there are no parameters to be bound in the sub-expression. This null value is recognized in other parts of SegmentExpression to build the query without a ?-parameter and a bound value.

Btw, I changed the "action not found"-value from -1 to -100 because we were discussing to use -1 for something else. When we do, we would most likely forget to change the value. ;)

Please review.

@mattab
Copy link
Member Author

mattab commented Feb 2, 2012

(In [5742]) Fixes #2727

  • Kuddos EZDesign for initial commit!!
  • Reviewed code & now more secure: use bind parameters rather than manually escaping SQL
  • Added integration tests for contains/ does not contain for title/URL. Also added test for the special case characters _ and % (ensure they are properly quoted since they are mysql special characters in a LIKE statement).

IMPLEMENTATION NOTES / limitations:

  • when you add &segment=pageTitle!=XXXXX to the request, it will sometimes return a different result data set than when the parameter is not added at all (one might expect the same data set in both cases).
    Adding a segment condition on pageTitle or pageUrl will restrict the visits being looked at, and once you add this condition segment=pageTitle== THEN Piwik will only look at visits that had at least one Page Title and then will apply the condition.
    ie. When using segment=pageTitle!=test Piwik will IGNORE all visits that do not have any "Page title", and will then exclude the remaining "Page title" that do not match the condition.
  • it does not make sense to call Actions.getPageUrls segmented on pageTitle: result will not be what you expect.
    Similarly, calling Actions.getPageTitles with segment=pageUrl=@test will NOT return page titles that belong to a URL matching Test. Instead it will return all page titles, that have been visited by a visitor that visited a page URL containing Test.

@timo-bes
Copy link
Member

timo-bes commented Feb 2, 2012

Nice update, makes it much cleaner!

What makes you think the second limitaion exists? Page title und page URL are both action-based reports/segments, so the output should be as expected. It tried it on my local box and it works.

@mattab
Copy link
Member Author

mattab commented Feb 2, 2012

Thanks for feedback, reopening to investigate further my claim

@mattab
Copy link
Member Author

mattab commented Feb 8, 2012

You're right, it WORKS! :)

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For errors / faults / flaws / inconsistencies etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Projects
None yet
Development

No branches or pull requests

3 participants