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

Tracking silently fails when inline JS code is minified #14411

Closed
tad-lispy opened this issue May 4, 2019 · 4 comments
Closed

Tracking silently fails when inline JS code is minified #14411

tad-lispy opened this issue May 4, 2019 · 4 comments
Labels
duplicate For issues that already existed in our issue tracker and were reported previously.

Comments

@tad-lispy
Copy link

Hi! Thank you for making this code and your service available to us.

I'm a new user and I'm quite excited about your platform. I'm trying to integrate it into several websites. I'd like to file a bug report and share my initial experience.

Steps I took so far

  1. I've added the website to the dashboard and copied the JS code to the head section of my HTML.

  2. I've run the local web server to test if it works

    I'm using Parcel to compile and preprocess the assets, so the local address was http://localhost:1234/ . The visit was immediately registered in the dashboard 👍

  3. I've pushed the code and my CI deployed it to the production site.

  4. I've tried visiting it from different browsers, devices and networks

    No visits were registered 🤕 There was no indication in the dashboard or the browser console. I saw that the inline script works because the other (remote) script tag was injected into the DOM.

What seems to be the problem

After about an hour of investigation it seems to me that the problem is related to pre-processing of the inline code (the one I copied and pasted). When compiled in development mode it is not minified and everything works as expected. When compiled for production it gets minified and _paq variable gets renamed. Then the other (remote) script doesn't work - but without any exception, it just doesnt do anything. This is really bad first impression.

What should have happened

Obviously the code should just work, but if it doesn't, there should be some indication as to why. Either an exception in the browser console or (better) a warning in the dashboard. It seems technically possible. The web app could fetch and inspect the configured website and give some info about the state (is there a script? does it send events? does it have correct site id?)

It is acceptable that the code you provide should not be minified (alas why not?). The real problem is lack of feedback from the system.

The workaround

For the minification problem the workaround seems to be changing the first line of the script from:

var _paq = window._paq || [];

to:

window._paq = window._paq || [];

But again, bigger problem is lack of any indication that something is wrong.

@tsteur tsteur added the Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. label May 5, 2019
@tsteur
Copy link
Member

tsteur commented May 5, 2019

In general the tracker is already minified and I would recommend you don't minify it again. You could exclude it in a list somewhere depending how you minify.

I suppose we would likely merge it if you created a PR. There's in theory a risk we're breaking something though so maybe we would do this only with Matomo 4. In theory, behaviour may slightly change if someone did something like

function () {
var _paq= [];_paq.push(..);

// then the matomo tracking code
}

You'd think maybe nobody does it, but with hundred thousands of users, and maybe someone wanting to avoid a global variable, this could be the case.

@mattab
Copy link
Member

mattab commented Jan 21, 2020

In theory, behaviour may slightly change if someone did something like

If it breaks BC this might be an issue. Or could there be instead a way to detect this problematic use case and show an error message in the browser console to explain?

@rachelwe
Copy link

I also had this issue with parcel but didn't realize it came from minification so thank you for pointing it out! In this particular case, adding a .terserrc file with the config below worked for me:

{
  "mangle": false
}

this solution was suggested here : parcel-bundler/parcel#2116 (comment) and it doesn't involve changing the matomo code.

@tsteur
Copy link
Member

tsteur commented Feb 2, 2020

window._paq = window._paq || [];

BTW... AFAIK the default tracking code does already use winodw._paq so not sure there's much we can do. This was changed in 4faceb9 as part of Matomo 3.8.

The reason we're not logging any errors or info when no tracker has been created while the script loads is because many users create the trackers manually after the script is loaded, or only when a certain action is executed. So it could also falsely confuse some users.

We also have an issue to add a check for this here: #12801

Will close this issue for now since it seems it might be rather a duplicate and I don't think we will change anything in the tracking code for now.

Cheers for your feedback @tad-lispy This was very appreciated. Please let us know if there's still an issue with window._paq.

@tsteur tsteur closed this as completed Feb 2, 2020
@tsteur tsteur added duplicate For issues that already existed in our issue tracker and were reported previously. and removed Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. labels Feb 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate For issues that already existed in our issue tracker and were reported previously.
Projects
None yet
Development

No branches or pull requests

4 participants