# PHP errors appeared after a version change

> Changing the PHP version is the fastest way to improve a site’s response times, and also the most brutal. Over successive versions the language removed behaviours tolerated for years: what produced a discreet warning becomes an error that stops the page. The message on screen always contains the answer.

- Source canonique : [https://allaux.fr/en/problemes/erreurs-php-apres-changement-de-version](https://allaux.fr/en/problemes/erreurs-php-apres-changement-de-version)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Note the file and line named in the message first, then switch PHP back to the previous version from the hosting panel selector: the site reopens and you fix things calmly. Check real compatibility: PrestaShop 1.6 goes no further than PHP 7.1 and the 1.7.8 branch stops at PHP 7.4. On WordPress an abandoned plugin is almost always the one at fault.

## Read the message rather than fear it

A PHP error message holds four pieces of information: the nature of the problem, the file, the line, and the chain of calls that led there. The file alone almost always names the culprit. If it sits in a module or theme directory, that component needs updating or replacing — not the CMS core, and not the PHP version.

The families of message are few. A function removed from the language produces a call-to-undefined-function error. A data type that became strict produces an argument error. Reading a value missing from an array, long tolerated, is now reported far more loudly. Those three cases cover the vast majority of breakages I meet.

## Frame it before fixing

1. **Check the version actually in use** — Many hosts allow a different version for the website and for command-line runs. A scheduled task can therefore fail while the site works, or the reverse.
2. **Count the components involved** — If one module appears in the messages, the fix is bounded. If the theme and five modules appear, the question becomes replacing them, not repairing them.
3. **Check the CMS’s stated compatibility** — Each PrestaShop or WordPress version states which PHP versions it supports. Using a version newer than intended produces errors even with no third-party module.
4. **Look at changes made in the core** — A site whose core was edited directly no longer benefits from the compatibility fixes published upstream. That is often where errors concentrate.
5. **Test on a copy** — The PHP version changes in seconds in the hosting panel, but the trial happens on a copy of the site, never in production on a busy day.

## Staying on an obsolete version is not a lasting option

> A PHP version at end of life receives no more security fixes, and hosts eventually withdraw it at short notice. Postponing the upgrade only turns a planned operation into an imposed emergency.

## Fix, replace, or step back

Fix when the faulty code is yours: an override, a bespoke module, an adapted theme. The simplest and most durable case.

Update when the component is maintained: the recent version is almost always compatible, and the problem goes away without writing a line.

Replace when the component is abandoned: maintaining an unsupported module yourself costs more than it looks.

Reverting to the previous version stays possible and immediate, but it is only extra time, not a solution.

## Carry on with the right page

- **Moving to PHP 8 on PrestaShop** — The known breaking points and the PrestaShop procedure. ([/prestashop/migration/passer-a-php-8](/prestashop/migration/passer-a-php-8))
- **PHP and WordPress** — The version upgrade on WordPress, plugins included. ([/wordpress-woocommerce/mise-a-jour/php-wordpress](/wordpress-woocommerce/mise-a-jour/php-wordpress))
- **PHP versions at end of life** — Why staying on an old version becomes a security problem. ([/securite/versions-de-php-en-fin-de-vie](/securite/versions-de-php-en-fin-de-vie))
- **Enabling debug mode** — To surface the full message instead of a blank page. ([/guides/activer-mode-debug-prestashop](/guides/activer-mode-debug-prestashop))

## FAQ

### My host changed the version without telling me. Possible?

They usually give notice by email weeks in advance, to the address on the account. When that address is no longer read, the change looks sudden although it was announced.

### Can I go back to the old version while I fix things?

Yes, with most hosts, in seconds. A good emergency measure, provided you set a date for the real fix.

### Does a newer version really make the site faster?

Recent versions run the same code noticeably faster, and the gap shows on heavy pages. I do not give a percentage: it depends entirely on the site and its database.

### Should I always take the newest version available?

No. The right version is the newest one your CMS and modules declare support for. Going beyond creates exactly the problem you are trying to avoid.

### Errors only appear on some pages. Is that normal?

Yes, and it is rather good news: only code actually executed produces an error. A module loaded on one page only breaks that page.
