Ignore tracking requests for disabled plugins #16570
Conversation
tsteur
added
not-in-changelog
tsteur
added
the
Pull Request WIP
|
build js |
|
There are some failing tests see eg https://travis-ci.org/github/matomo-org/matomo/jobs/735568092#L737-L847 I don't understand how they fail. They work locally and the requests failing makes no sense to me currently as not really any logic was changed. Maybe someone else has an idea what is happening there? |
tsteur
removed
Pull Request WIP
|
@tsteur I've looked into the failing tests. The "problem" is, that your new tests are using the |
|
Cheers @sgiehl let me know if this is good to merge |
|
Updated our premium features and documented the tracking parameter on the developer website. Also created issues with other sdks etc |
|
build js |
fix #16569
Once merged, I would also implement this in our premium features.
It shouldn't be needed to mention this in our changelog since AFAIK custom actions/request processors aren't a documented/officially supported feature yet.
Already implemented this basically as a test in core for Contents, and Events plugin. So if someone was to disable the events plugin, but the standard JS tracker is still sending requests for events, then these would be ignored. Not doing it eg for actions plugin as this be usually always enabled anyway etc. Tried to implement it for heartbeat plugin but this doesn't work because it kind of relies on using the default page view action and then aborting the request. So if someone was to disable the heartbeat plugin, but still using the feature in JS this would still register page views.
We could then also create issues for other SDKs/trackers and add this there although it might not be as much of an issue there.
Possible problem: Sometimes one request might be sent for different purposes. Need to make sure in these cases we don't break anything. Eg a form view request might be sent along a page view. In this case we should not append the
ca=1tracking parameter.