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

Jump to bottom

trackLink does not like relative links ? #10154

Open
er314 opened this issue May 15, 2016 · 5 comments
Open

trackLink does not like relative links ? #10154

er314 opened this issue May 15, 2016 · 5 comments
Labels
c: Platform For Matomo platform changes that aren't impacting any of our APIs but improve the core itself. Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc.
Milestone
Backlog (Help wan...

Comments

@er314
Copy link
Contributor

er314 commented May 15, 2016 •
edited

My observation : trackLink does actually track the link ONLY if it's a full URL (then it's considered as an outgoing link), not when it's a relative link
Trying to understand what's going on, I enabled piwik.php debugging, then :

DEBUG:   'link' => '/styles/us/alt/',
DEBUG:   'idsite' => '1',
[...]
DEBUG:   'url' => 'http://127.0.0.1:81/styles/us/',
[...]
DEBUG: WARNING: URL looks invalid and is discarded
[...]

the debug message above clearly points to the problem...
adding display of the $url causing the error, I get :

[...]
DEBUG: WARNING: URL looks invalid and is discarded : /styles/us/alt/
[...]

ok so it seems to refuse relative links...
this brings me to function isLookLikeUrl
its purpose is to test if its argument starts with protocol://
obviously, this test fails when checking the link

-> is this the intended behaviour ?
this was not the case some time ago, according to :
https://forum.piwik.org/t/piwiktracker-tracklink-bug-in-version-1-6/5676/4
I wish I could use trackLink to track my internal URLs + use its callback feature, and have these URL appear in the Actions / Pages view, like when tracked by the regular trackPageView.

thanks !

my js tracking code :
  var tracking_callback = function() { console.log('hello callback'); };
  var _paq = _paq || [];
  _paq.push(['trackLink', '/styles/us/alt/', 'link', null, tracking_callback]);
 (function() {
    var u='//127.0.0.1:81/analytics/';
    _paq.push(['setTrackerUrl', u+'piwik.php']);
    _paq.push(['setSiteId', 1]);
    _paq.push(['setLinkTrackingTimer', 300]);
    var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
    g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'piwik.js'; s.parentNode.insertBefore(g,s);
 })();
@tsteur
Copy link
Member

tsteur commented May 16, 2016

Looking at the forum post this was in 2011 or so. I'm not sure if it's supposed to track relative links or not. Ping @mattab

Looking at the documentation it says trackLink: function (sourceUrl, linkType, customData, callback) { indicating that it actually wants a URL, not a path. Maybe we could automatically append current domain if only a path is given.

@tsteur tsteur added Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. c: Platform For Matomo platform changes that aren't impacting any of our APIs but improve the core itself. labels May 16, 2016
@mattab mattab added this to the 2.16.2 milestone Jul 14, 2016
@mattab
Copy link
Member

mattab commented Jul 14, 2016

Maybe we could automatically append current domain if only a path is given.

👍

@er314
Copy link
Contributor Author

er314 commented Jul 14, 2016

Hi,
Well, I must say that I opened a few bug reports, + one feature requst / PR (#10172) , + this question, after my first few days of testing piwik.
Now that I understand better how it works, and with some perspective, I can say that :

  • piwik is great :-)
  • regarding this issue, strictly for my usage, it is no more relevant.
    Let me briefly explain why, as a basis for discussing about : is there a real use case for this improvement ? In the long run, I guess it's preferable not to add features and complexity if there's no real use case, correct ? :-)

So, my use case was the following :
On the web app, I have one URL which is dedicated to centralizing the requests incoming from clicks performed on newsletter emails. The processing of such request is :

  1. perform piwik-logging (with JS tracker),
    then, as soon as ok,
  2. perform a redirect to the real local URL requested by the user

So, this use case is a perfect example of the need for piwik callbacks : instead of setting an arbitrary timeout before redirecting, let's ask piwik.js to perform the redirect as soon as possible, as soon as its track request has been completed ; then it will execute the following callback :
$thecallback = "function() { window.location = '" . $thetargeturl . "' }";

This being said, which piwik method to use for this ?
(a) - I may well use trackLink(), which supports callbacks ... but it does only work with file downloads, or with external target URLs, but not with local target URLs
(b) - ok, then I may well use trackPageView() ... but it does not support callbacks
(c) - or, why not I may well use trackEvent() ... but it does not support callbacks, either.
So I was stuck ! :-)
As a result, I opened PR #10172 for adding callbacks support to trackPageView(), and also the current question / feature request about trackLink() vs local target URLs.
-> (b) PR #10172 has been accepted & merged for 2.16.2
-> so now I have a good, supported method for my use case, I'm happy haha.

If we look at options (a), (b) and (c), and assess what's best / more / least desirable, I think that :
(a) trackLink() is actually the worst candidate : the implied modifications seems more complex, or at least somewhat touchy ; moreover, functionnally, for this use case at least, it has no added value compared to (b) or (c).
(b) trackPageView() seems a good candidate, because the implied modifications are very simple (due to good core design !), and because it is the "central" tracking method, so it seems logical that this is where most use cases for callbacks may lead to
(c) trackEvent() would probably also make some sense ; in my use case, the incoming requests from emails may as well be considered as "events"

So, as a conclusion, I think that

  • (a) trackLink() : unless you foresee some valid use cases for the modifications to trackLink() (?), I think it's not worth it
  • (b) trackPageView() : we did it and I think it's worth it :-)
  • (c) trackEvent() : depending on priorities...

What do you think of tout cela ?

cheers

@mattab mattab modified the milestones: Mid term, 2.16.2 Jul 15, 2016
@mattab
Copy link
Member

mattab commented Jul 19, 2016

Hi @er314

Maybe we should also implement the callback to the trackEvent?

re: trackLink -> the overall design decision is to make our APIs as easy to use as possible... this is why I initially suggested to change it. But i agree it's not absolutely necessary at the moment especially if you don't need it, as no one asked for it yet. I'll still leave issue opened in case it would be useful in the future 👍

we look forward to your feedback as you keep using Piwik, and maybe even hopefully more of your Pull requests :-)

@er314 er314 mentioned this issue Jul 21, 2016
Closed
@er314
Copy link
Contributor Author

er314 commented Jul 21, 2016

Ok, for completeness, I've just submitted PR #10337 , which adds callback to trackEvent :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
c: Platform For Matomo platform changes that aren't impacting any of our APIs but improve the core itself. Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc.
Projects
None yet
Milestone
Backlog (Help wanted)
Development

No branches or pull requests
3 participants
@tsteur @mattab @er314