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=1 tracking parameter.
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 I've looked into the failing tests. The "problem" is, that your new tests are using the
Action::factory without loading the
Actions plugin. That fills the static available actions array without those actions, causing the other tests to fail. Always loading the
Actions plugin should fix that. I'll push a fix...
Updated our premium features and documented the tracking parameter on the developer website. Also created issues with other sdks etc