Which PHP version? If I see this correct the linked Forum post is re Tracking where we do not display it.

Good point, it was in tracker and both users probably found it by looking at piwik.php?... output.

So the scope of this issue maybe is: "How to help users run a stable Piwik when a plugin creates a fatal error in Tracker mode?".

Maybe the "Log viewer" #7239 could help if those fatal errors in tracker are logged in our logger.

Maybe they simply had a look at the logs on the server?

Log viewer might help, still one needs to have a look at it. Imagine the error occurs only on say 5% of the users (say only when IPv6, or only when from specific country, ...). One wouldn't really notice that and therefore probably also not have a look at the Log viewer. Maybe a daily status report (eg via email) could be something that contains eg the number of tracking request, the number of failed requests (with fatals), etc. There might be even better solutions...

We're surely not the first ones that want to report such problems re "background requests" etc. So there might be already good ideas / solutions out there. Haven't looked.

@tsteur I'm one of the two users who reported in the forums. I noticed the error because piwik.php returned an "Internal Server Error" and because I include the tracker via javascript, it showed up in my browsers console. I then locked into Apaches error_log and found the error caused by the plugin. Hope this helps.

I had the same issue: I noticed there was absolutely nothing being tracked in Piwik starting March, 24th (so it seems to be related to the 2.12.0 release).

I didn't notice any "Safe Mode" hint in the interface, but I found this line in my logs:

PHP Fatal error:  Call to undefined method Piwik\IP::isIPv4() in piwik/plugins/IPv6Usage/IPv6Usage.php on line 96

PHP version is 5.6.5. Updating the plugin fixed it, but traffic of four days has not been tracked because of this.

Updating the plugin fixed it, but traffic of four days has not been tracked because of this.

(Btw in case you want to restore your days of traffic, you can import the server logs for those 4 days via: http://piwik.org/log-analytics/)

The log viewer could help if the admins visit Piwik. It could show e.g. with a notification/badge if there has been new log entries since the last time they checked the logs.

We could even have a log watchdog that emails admins in case of errors in the log file, but I'm not sure it would have worked in this situation since the watchdog would run in tracker requests and those where in fatal error.

Another case where a plugin not up-to-date caused Tracking API to fail: http://forum.piwik.org/read.php?2,125663,page=1#msg-125766

Off-topic: We should maybe also be more careful when breaking API's (even if deprecated before) if it is potentially used by Tracker plugins.

An idea: As we build an analytics tool maybe we could even track failed requests and show them in the UI. So people could make use of features like Graphs (history), Insights, CustomAlerts (send an email if more than 10 requests fail) etc

@tsteur : Sold for the "send email if more than 10 requests fail".

If not default(email), should be visible for SuperAdmin in the Web interface at least.

Important: we do not want to only detect when Tracker fails because of outdated plugin, but also we want to detect when any error occurs during tracking. There are many cause of possible failures. For example we're investigating #7945 and the error is due to a broken client side library conflicting with piwik.js causing wrong data to come to the Tracking API. Piwik should in this case also somehow detect and report to Piwik super user that the Tracking API is mis-used and that some data was not tracked.

Awesome feature!

just some thoughts from #8732

Would be good if this feature would make it possible:

1. to find actions e.g. events on your site which were setup faulty (e.g. a needed parameter is missing or...) and fire data to piwik which could not be processed
2. having a "problem list" accessible from piwik backend, each user could bothering his site-admin to solve this... (and of course it's handy for admin too)
3. catching problems in production environments without any problems (e.g. performance)
   because one could think of several problems which would not appear within a short testing period...

we can consider this was done in #13493 so will close this one