Hi @waldoj thanks for creating this issue. This should actually already be happening. Do you remember on which version of Matomo you were?

I'm afraid that I'm not sure. Because Matomo (last I checked) can't be scripted to be part of a deploy process, due to the manual config steps, it's not subject to my normal version-control system. I suspect strongly that I last updated it in the summer, probably around July, so perhaps v3.14 or thereabouts.

Should I wind up restoring from a backup, I'll be sure to report back with the exact version.

Be great to report back if you end up restoring. Any chance you know your exact PHP version?

So far https://api.matomo.org/1.0/getLatestVersion/?piwik_version=3.14.1-b2&php_version=5.7.5&release_channel=latest suggests the latest version is a 3.14.1 . Also for release_channel=latest_stable and when no release channel is set etc.

Looking at the code the only way this would happen is if Matomo was not able to detect the PHP version at all for some reason. We're using PHP_VERSION constant which I think cannot be disabled (or maybe it can in PHP not sure)

Sure thing, I'm using v5.6.40-39. I've verified that both phpversion() and PHP_VERSION function properly on my server. (It's a stock Ubuntu 18 installation on an EC2 instance.) Now, it's been at least a decade since I've had cause to use a PHP version string, but I was surprised to find that both of the methods of displaying the version didn't display 5.6.40-39, but instead 5.6.40-39+ubuntu18.04.1+deb.sury.org+1. But maybe y'all expect PHP version numbers to be a hot mess, and parse out the actual identifier?

FWIW, Matomo also reports the unwieldy version name when trying to load any page, I've just noticed:

An error occurred

To run Matomo you need at least PHP version 7.2.5

Unfortunately it seems your webserver is using PHP version 5.6.40-39+ubuntu18.04.1+deb.sury.org+1.

The error isn't wrong, but it hints that perhaps the installer isn't extracting the actual version number from that bizarre string that PHP is generating. (Or there's also the distinct possibility that I'm barking up the wrong tree here.)

Thanks @waldoj just debugged/tested the logic for the update check when the exact PHP version is used that you mentioned and it should have still suggested 3.X. I double checked using the debugger. We're using PHP's internal version_compare method and it seems to be able to handle those sort of strings. So right now I can't really explain how this could possibly happen and we haven't heard of any other case like this so I'm tempted to just leave the issue open for now and we see if it ever happens again. If you otherwise backport, and it suggests to upgrade to Matomo 4 again, then it might be interesting to do a few checks.

If you can't reproduce it, there's nothing to be done. 🤷 If I can reproduce this, I'm happy to return and document further.

This issue has been mentioned on Matomo forums. There might be relevant details there:

https://forum.matomo.org/t/upgraded-to-unavailable-php-how-to-downgrade/22712/10