From which version did you update and how did you update?

On what operating system is that?

I don't remember the exact version, it was the latest stable release before this one. And I ran the built-in updater in the Piwik UI, all steps until completion and without any errors.

Environment:
CPU 4 cores, 8GB RAM (not swapping)
Ubuntu 15.10 x86_64
PHP 5.6

Btw, database size is 992.4 MB according to Piwik settings.

Edit:
Also worth to note is that the API appears to be functioning just fine.

Follow up: when I disable all caching in config.ini.php everything works great! So the problem must be somewhere in the caching.

[Cache]
backend = "null"

Edit:
Nevermind, back to square one.

That's really weird. Is there any chance that we can get access to your server? If so please send us an email to hello at piwik.org and leave a comment here afterwards as it might go to spam.

Maybe also try to remove files in tmp tmp/*.json, tmp/assets/*, tmp/cache/*, tmp/templates_c/*

Removing the tmp files and then forced rearchive appears to be the solution.

There are no *.json files in tmp/, but after deleting the contents of assets, cache and template_c most reports came back. For a few I had to double refresh the page, but some reports like Visitors/Engangement and Actions/Pages (and more under Actions specifically) kept returning the red error. Then I ran:

./console core:archive --piwik-domain "{private}" --force-all-websites --force-all-periods

Took a long time to complete, but now the issue appears to be resolved. I checked the permissions before deleting the tmp/ files and they all had proper read/write access.

Interesting to note is that the response time to clicks has improved a lot! It's near instant even on large reports.

Re the instant loading times maybe it's also related to http://piwik.org/docs/setup-auto-archiving/ in case this is not activated it will improve loading time a lot.

Maybe Piwik had no permission to reset some caches or something else happened. I still cannot really explain it but happy it works now. Can we close this issue?

I already had auto archiving with cron.

Anyways, thanks a lot for the hints and yes you can close the issue.

@tsteur After 3 days without any trouble the problem returned, similar to before.

PHP message: PHP Fatal error: Cannot redeclare class Piwik\Plugins\UserLanguage\Reports\GetLanguage in /home/stats/public/plugins/UserLanguage/Reports/GetLanguage.php on line 16

Piwik

• All Websites Dashboard (AWD) loads ok, except for the sparklines although some of them (random) sometimes do load.
• Settings works fine.
• Tracking and API work fine. (including the Piwik Mobile 2 app)
• DBStats is a white screen.
• System Check is all good. (green)
• Any website report is a white screen.
• When I enable debug log it only reports loaded plugins.
• Disabling the cache in the config.ini.php returns the red error on AWD and white screen on reports.
• Clearing the cache with ./console cache:clear and then ./console core:archive causes always red error on AWD and still white reports. (not recovering)
• Deleting tmp/ contents with rm -rvf {assets,cache,templates_c}/* and then run ./console core:archive does bring back the AWD with broken sparklines and still white reports.

Server

• The process has read and write access to all contents of the tmp/ directory. Actually to the entire piwik path and of course execution perms for directories.
• There are no cron jobs running that could affect Piwik, besides normal core:archive.
• Piwik has its own installation path outside any site or app, not sharing its database or DB login with anything else.
• Server load is low, plenty of RAM available, not swapping, no weird processes, PHP and MariaDB are running fine, everything looks healthy.
• PHP memory_limit = 256MB should be plenty.

Okay weird, it appears the tmp/ has nothing to do with it. Somehow the permission of the other files change at random. Only when I run this in the Piwik root it fully recovers:

sudo find . -type f -exec chmod 0660 {} \;
sudo find . -type d -exec chmod 0770 {} \;

Edit: (6:18)
Nevermind, it's broken again.. The chmod trick was just lucky.

Is it possible that we get access to that server?

PHP memory_limit = 256MB should be plenty.

It depends, if possible I'd increase it but it depends how much traffic your sites get. It shouldn't cause such an error though.

Somehow the permission of the other files change at random

This sounds a bit weird, it shouldn't change by random. Maybe there are different processes running or something must be causing this.

Have you installed from the zip download from our website or from git? Which version of PHP 5.6 is it?

For the record: I seem to be having very similar problems after the upgrade to the latest version.
Initially (after a apache restart) all widgets work as expected but after a few refreshes they show an 'Internal server error' and the logfiles shows messages about redeclared classes.

Mine is a tiny installation (only 50-100 hits/day since the beginning of this year).

Piwik is running on virtual Turnkey Linux with PHP Version 5.6.24-0+deb8u1
uname -a: Linux piwik 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux

Update: I think I found a solution: xcache seems to be the problem.
https://www.drupal.org/node/2066561 describes a similar problem so in my "\etc\php5\mods-available\xcache.ini" is set xcache.size = 0 and restarted apache.

Since then I have not seen the 'redeclare class' again, Piwik is working fine.

Nevertheless it is something you might want to investigate. XCache is very common.

@fvdm can you confirm you are using xcache as well? We would need to check if there were any changes re xcache.

@tsteur Ah yes of course, I have opcache and xcache running but never realized you can have only one at a time! A cache can't serve another cache. That explains the "Cannot redeclare class" errors.

I disabled opcache now and keep monitoring.

@glipman Do you perhaps also have multiple caches enabled in PHP?

Indeed, in my installation opcache was enabled as well.
Once you know what to look for you can find it all over the Internet when you google for 'opcache xcache redeclare'.
I did not enable it myself, it came this way with my Turnkey LAMP appliance. They seem to have tackled this in newer versions already.

In the end I believe Piwik is doing nothing wrong and no software change is required. Adding an entry to installation FAQ might be an idea though.

I'm still curious what caused the problem in Piwik only since the update. Other apps like Wordpress don't have a problem with the mixed caches.

Edit: re the changing permissions, it was my server-wide security script that was a little too aggressive.

I had a look through the changes but don't know what it causes, maybe an update of a library. We would probably simply recommend to have only one cache active in general and I would say we add a system check for it. I will update the title to add a system check

Addition to the System Check would be great.

Sadly the problem just returned. Nothing has changed on my server except for disabling opcache two days ago based on this conversation. Everything else is looking good and I'm not getting any errors in the UI.

• On the AWD most sparklines return error 500 PHP message: PHP Fatal error: Cannot redeclare class Piwik\Plugins\API\Reports\Get in /home/stats/public/plugins/API/Reports/Get.php on line 15
• and any website report I click from there brings only a white screen and error PHP message: PHP Fatal error: Cannot redeclare class Piwik\Plugins\UserLanguage\Reports\GetLanguage in /home/stats/public/plugins/UserLanguage/Reports/GetLanguage.php on line 16

AWD screenshot

So it's not in the caching. 😞

Hi @fvdm just a basic check: did you try to restart your webserver?

Hi @fvdm just a basic check: did you try to restart your webserver?

Hi @mattab I don't feel like rebooting an entire server because a webapp is acting up.

I'll get to the bottom of this. Right now Piwik is working perfectly normal somehow, while nothing has changed except for new tracking input.

When I have time I shall move Piwik to its own PHP process so I can revert the php.ini to all defaults and disable all extensions. Debug step by step.

Alright I found the problem, there was yet another cacher enabled in one of the included ini's!

What a mess, I'm completely rebuilding the server now to avoid these kind of issues in the future. Five years of patches and tweaks stacked upon eachother. My guess is the Piwik update did change something in a good way, more adhering to modern standards or the like, which caused the ancient code higher up the chain to finally break.

Issue resolved!

Thank you for letting us know. I still think a system check would be good for usability in case something like this happens again. It's an edge case but easy to implement.

@fvdm what was the third cache that you had enabled?

@mattab Sorry, I forgot about this. The other one was APCu.

Although opcache and apcu should have worked great together. It probably was a rogue config somewhere, maybe cache expiry not well aligned.

The new ssd server is running so great using only opcache, I even managed to downgrade the VPS to 4GB ram and 3 cpu cores. 💰

Thanks for contributing to this issue. As it has been a few months since the last activity and we believe this is likely not an issue anymore, we will now close this. If that's not the case, please do feel free to either reopen this issue or open a new one. We will gladly take a look again!