# Your PHP is on the latest release and Matomo still shows a warning. Here's why > A warning in System Check when your PHP is current is almost always about your database, not PHP. And the PHP Deprecated lines flooding your archiver log aren't errors at all. Here's how to tell what each one is really saying, and what's worth doing about it. Published: 2026-08-19 Categories: Matomo Self-Hosting Canonical: https://martez.io/blog/matomo-php-version-warning-explained --- You're on the newest PHP release, you open System Check, and there's still an amber or red row staring back at you. Or your nightly archiving cron has started filling its log with `PHP Deprecated:` lines on PHP 8.2 or 8.3. Both look like Matomo is unhappy with your PHP, and both get read the same way: fine, what version does it want, then? In almost every case neither warning means Matomo is broken, and neither is actually asking you to change PHP. Here's how to tell what each one is really saying. If your PHP is current but System Check still warns about end of life, the warning is almost always about your database engine, not PHP. Read the text of the flagged row and plan a MySQL or MariaDB upgrade. The `PHP Deprecated:` lines in your archiver log are harmless notices, not errors, so archiving still finishes; upgrading Matomo to the latest 5.x clears them. ## The warning that survives a current PHP The pattern goes like this. The PHP row in System Check is green, required `>= 7.2.5` and installed `8.3.x`, and yet there's still a warning on the page mentioning End of Life. The obvious read is that your PHP passed, so this must be a false positive. It usually isn't. Since Matomo 5.4, System Check can warn when your database engine has reached end of life, and that warning lands next to a passing PHP row. MySQL 8.0 reached EOL in April 2026, so a current Matomo flags it. Your PHP being current and your database being EOL are two separate checks that happened to land on the same page at the same time. The tell is in the version string. If your database reports something like `8.0.45-cll-lve`, the `-cll-lve` suffix means you're running on CloudLinux, which is typical of shared and managed hosting. On that kind of stack the host controls the database version, not you, which is exactly why the warning feels stuck. You can't `apt upgrade` your way out of a database your provider pins. Here's what System Check doesn't make obvious: it grades a lot of components, not just PHP. A green PHP row doesn't mean every row passed. When something warns, read the text of the flagged row rather than guessing from the color of the row above it. It's the same family of "the message names one thing but means another" confusion we see with [Matomo database errors](/blog/fix-matomo-database-errors), where the surface symptom and the real cause sit in different places. ## The deprecation notices in the archiver The second symptom looks even more like a PHP problem because it literally says `PHP`. Run the archiving console command on a newer PHP and you may watch lines like this scroll past: ```text PHP Deprecated: Using ${var} in strings is deprecated, use {$var} instead in ... ``` These aren't errors. Archiving still finishes and your reports still build. A deprecation notice is PHP telling you that some code uses a syntax a *future* PHP will remove someday. It's a heads-up for maintainers, not a failure. On older Matomo builds, a batch of these came from a dependency Matomo bundles called Symfony Console. PHP 8.2 deprecated the `${var}` form of string interpolation in favor of `{$var}`, Symfony Console still used the old form in a couple of files, and so every archiving run echoed the notice. Matomo staff confirmed the cause and shipped the fix in Matomo 5.0, so on a current 5.x these particular lines are already gone. If you're still seeing them, you're on an older build. ## Why the two get mixed up Both warnings carry the word PHP, one because it sits in a PHP-heavy diagnostics page and the other because PHP itself emits it, so both get filed under "Matomo wants a different PHP version." Neither does. Here's the split: | Warning | Where it shows up | What it means | What to do | | --- | --- | --- | --- | | EOL warning beside a green PHP row | System Check page | A component has reached end of life. With a current PHP, that component is almost always the database engine. This is a genuine "no longer getting security patches" signal. | Read the flagged row, then upgrade or escalate MySQL/MariaDB. | | `PHP Deprecated:` lines | Archiver CLI and cron log | Informational notices, not failures. Archiving still finishes. | Upgrade Matomo and plugins, run a supported PHP, then quiet the CLI noise only if any survives. | The `PHP Deprecated:` notices come from one of three places: an outdated bundled dependency on old Matomo (fixed by upgrading), a third-party plugin, or a PHP newer than the version your Matomo build was tested against. ## If it's a database EOL warning First, confirm what the row is actually naming. Go to Administration → Diagnostics → System Check and read the text of the flagged row instead of judging it by the PHP row's color. If it names your MySQL or MariaDB version, here's the path: - Self-managed server: upgrade to a supported release. MySQL 8.4 LTS is the natural target coming off 8.0, and the jump is far gentler than the old 5.7 to 8.0 migration was. On MariaDB, move to a supported LTS such as 10.11, 11.4, or 11.8, after checking your OS packaging and Matomo compatibility. Back up your database before you touch it. - Shared or managed hosting (CloudLinux `-cll-lve`, cPanel, and similar): you can't change the engine yourself. Open a ticket asking your host to move you to a supported MySQL 8.4 LTS or a current MariaDB. The database version is theirs to set. What we'd avoid is reaching for the "ignore this check" option. An EOL database warning is a genuine security signal, the engine has stopped getting patches, and it belongs on your real maintenance list next to the rest of your [Matomo hardening](/blog/harden-secure-matomo-installation) work. Hiding it just means the next person to read System Check rediscovers it from scratch. ## If it's deprecation notices in the archiver The proper fixes, in order: 1. Upgrade Matomo to the latest 5.x. This is what cleared the Symfony Console notices, and it clears most others too, because dependency and deprecation fixes ship with releases. If you're chasing notices on an old build, stop and upgrade first. 2. Run a PHP 8.x version your Matomo release supports. Matomo runs on PHP 8 and recommends a current 8.x, but if you jump onto a PHP branch newer than your build expects, that's a common source of fresh deprecation chatter: the code is fine, it just hasn't been certified against the newer runtime's stricter notices yet. Check your release's requirements before moving to a brand-new PHP. 3. Update your plugins. Third-party plugins are the usual remaining source once Matomo core is current. If you've done all that and only harmless log noise is left, you can quiet it at the PHP CLI level. The thing to know is that cron runs through the CLI `php.ini`, which is often a different file from the one your web server uses, so changing the web config does nothing for your archiver. Find the active CLI file: ```bash php --ini ``` Then, in the file it reports as loaded, mute PHP's engine-level deprecation notices for the CLI: ```ini ; In the CLI php.ini only, not the web one error_reporting = E_ALL & ~E_DEPRECATED ``` One caveat: `~E_DEPRECATED` silences only the engine notices, the kind the `${var}` line above belongs to. It does not touch `E_USER_DEPRECATED`, which plugins and libraries raise deliberately in their own code. If those are part of the noise too and you want them gone, extend the mask to `E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED`. Keep the change to the CLI and cron context. Blanket-suppressing deprecations across your whole stack hides exactly the early warnings that make the next PHP upgrade smooth. If you're setting up archiving from scratch and want the cron side done properly, we walk through it in [setting up Matomo cron archiving](/blog/set-up-matomo-cron-archiving). ## Verify Reload System Check after a database upgrade and the flagged row should clear. For the archiver, re-run it by hand and confirm the deprecation lines are gone: ```bash ./console core:archive --matomo-domain=your-matomo-domain ``` On Matomo 5 the option is `--matomo-domain`. The older `--url=https://your-matomo-domain/` still works and is the one you want when Matomo lives under a sub-path. Use whichever matches your install. A WordPress-plugin install drives archiving differently from a standalone one. If the run itself misbehaves rather than just printing notices, that's a separate problem, and [archiving returning an invalid response](/blog/matomo-cron-archiving-invalid-response) is the place to start. ## What we'd actually do Read the row, not the color. Nine times out of ten, the "PHP is current but still warned" report is a database EOL warning wearing a PHP costume, so treat it as the database task it is. On a server you control, schedule the MySQL 8.4 or MariaDB LTS upgrade. On managed hosting, file the ticket today rather than letting an unpatched engine drift, and don't burn time trying to upgrade something your provider has locked. For the archiver noise, upgrade Matomo and stay on a PHP version it's tested against. That alone clears almost all of it. Only after that, if a few cosmetic notices survive, silence them in the CLI `php.ini`, narrowly and on purpose. Suppression is the last step, never the first. [Martez](/?utm_source=martez&utm_medium=blog&utm_campaign=matomo-php-version-warning-explained) connects Matomo with Meta Ads and Google Ads so ROAS, CLV, and attribution sit next to your web analytics instead of in a separate spreadsheet. It's in private beta. [Join the waitlist](/signup?utm_source=martez&utm_medium=blog&utm_campaign=matomo-php-version-warning-explained) if that's relevant. A warning that names PHP is rarely about PHP. Read the row, and fix the real thing.