PrestaShop and PHP 8 — Module Compatibility and a Safe Migration [2026]

PrestaShop 8 and 9 support PHP 8.1–8.4, but the platform itself is only half the picture — modules, the theme and overrides decide compatibility. Upgrading PHP in a PrestaShop store without preparation is the most common cause of white screens and 500 errors, and on the other hand a store on PHP 7.4 has been missing security patches since 2022. This guide shows how to run the upgrade safely: from a module audit to a test transaction on staging.

Key takeaway: The order for a store: backup with a restore test → update PrestaShop and modules on the current PHP → staging on the target version → full checkout test → production outside peak hours. A store is a transactional system — a test transaction on staging is not optional, because a checkout failure costs real orders.

Which PHP versions PrestaShop supports

Platform compatibility with PHP versions looks like this.

The conclusion for a store on 1.6 or an early 1.7: a PHP upgrade alone is not enough — first the platform migration, then PHP. For stores on 1.7.8.x and 8.x a PHP upgrade is realistic, but requires a module audit.

What actually decides compatibility — not just the platform

Three layers to check before changing the PHP version.

Modules and plugins. The biggest source of problems. A module written for PHP 7.x uses removed functions, dynamic properties or an old Smarty API — on PHP 8.x it throws errors. Check every module: version, last update date, declared support. Abandoned modules (no updates for years) are the prime candidates for replacement.

Theme and overrides. PrestaShop themes contain PHP code (not just templates) — custom controllers, helpers, class overrides (/override). An old theme with modifications is the second most common source of post-upgrade failures.

Core overrides. The /override directory overrides PrestaShop classes. If the store has changes written years ago, on new PHP (and on a platform update) they may stop working or conflict with new class versions. Reviewing overrides is a mandatory audit item.

Step by step — a safe PHP upgrade in a store

1. Backup with a restore test. Files, database, configuration. Restore the backup on a test environment and confirm the store works — before you change anything.

2. Module and compatibility audit. List all modules with versions and update dates. Run a compatibility scan (PHPCompatibility) on the /modules, /override and theme directories. The list of modules to update or replace is your work plan.

3. Updates on the current PHP. Update PrestaShop to the latest supported branch (1.7.8.x or 8.x), then modules and the theme — all on the current PHP version, where you can diagnose problems. Only then change the PHP version.

4. Staging on the target PHP. A store copy on the target PHP (8.3/8.4) with the same extensions as production. This is where you run the full test.

5. The checkout test — mandatory. Add to cart, discount coupon, shipping selection, payment selection, a test transaction (Przelewy24/PayU in sandbox mode), confirmation email, invoice, order panel in the back office, return. Every step is a place where a module incompatibility can kill sales.

6. Production outside peak hours. Deploy in the evening or at the weekend, with hosting panel access and a rollback plan (switching PHP back). First hours: monitor orders, logs and mail queues.

What usually breaks after a PHP upgrade in PrestaShop

Experience shows the same patterns — check these first.

• White screen / 500 error in the front office — almost always a module or override using removed PHP functions. Diagnosis: debug mode and logs.
• Back office errors after login — administrative modules (statistics, exports, integrations) written for old PHP.
• Payment problems — the most expensive type of failure: a payment module that fails on new PHP or whose callback stops working. A sandbox test before production is mandatory.
• Smarty and template cache errors — an old theme with an outdated Smarty API; after the upgrade clear the cache (/var/cache, Smarty cache) and recompile templates.
• Deprecations in the logs — dynamic properties, null in parameters; code works but the logs swell. That is a fix list for later iterations.
• Slower performance after the switch — missing OPcache on the new version, stale cache, untuned PHP-FPM. After the upgrade check the server configuration, not just the code.

Full repair procedures for the most common failures are in the articles on the PrestaShop white screen, 500 errors and debug mode, and general technical support on the PrestaShop help page.

An old store on 1.6 / 1.7.0–1.7.7 — what then

Stores on PrestaShop 1.6 or an early 1.7 have two paths.

A platform upgrade (1.6 → 8/9) with data migration. A bigger project: database, modules, theme and overrides migration, with URL preservation (301 redirects) and SEO. Realistic time: 2–8 weeks depending on the number of modules and modifications. It is the only route to supported PHP — but it needs a plan and a budget.

Staying on the old stack with a buffer. Possible only short-term: hosting with an isolated old PHP, a WAF in front of the store, security monitoring. The risk grows every month — new vulnerabilities in old PHP and PrestaShop receive no patches. This is a "buying time for the migration" scenario, not a solution.

The details of a platform migration (redirect map, data transfer, tests) are in the article on moving a store to another platform (implementation guides), and the PHP version context — support dates and recommendations — in the article on PHP versions and support dates.

Performance — what a store gains from PHP 8

For a store, the PHP upgrade is not only security but also speed — and speed translates into conversion.

• Faster page generation — PHP 8.x is significantly faster than 7.x; for a catalog with cache and Smarty the real gain is tens of percent in server response time.
• OPcache and JIT — OPcache works better on new PHP; heavy operations (imports, reports, feed generation) gain from JIT.
• A better security profile — a supported version means patches on time; for a store with payments that is a condition of trust and compliance with payment providers' requirements.

After the upgrade, measure before/after (PageSpeed Insights, TTFB, GA4) — concrete numbers are the best argument for further performance work, such as the optimization described in the PrestaShop performance article.

How long it takes and what it costs

For a store on PrestaShop 8.x with current modules, the PHP upgrade is 1–2 days of work: backup, module audit, staging, checkout test, production. Cost: 1,500–4,000 PLN net.

More expensive situations: modules requiring updates or replacement (several days), an old theme with modifications (several days), overrides needing a rewrite (weeks), a store on 1.6/1.7 requiring a platform migration (a separate project). Scope and quote after an audit — on the PrestaShop service page or under code maintenance and modernization if the store has extensive custom code.

Frequently asked questions

Does PrestaShop 8 run on PHP 8.4?

Yes — PrestaShop 8.x and 9.x support PHP 8.1–8.4. The condition concerns modules and the theme: the platform may be compatible while a specific module is not. That is why before changing the PHP version you check every critical module (payments, shipping, integrations) and test the full checkout on staging.

What should I do when the store shows a white screen after the PHP upgrade?

Enable debug mode (_PS_MODE_DEV_ in config/defines.inc.php or via the panel), check the logs in /var/logs and the error message — it points to the file and line. The culprit is usually a module or an override. Temporarily disable the suspected modules (rename directories in /modules), restore the store, then diagnose one by one. The step-by-step procedure is in the PrestaShop white screen article.

Does a PHP upgrade in PrestaShop require a platform update?

Not always — PrestaShop 8.x runs across the whole 8.1–8.4 range, so a store on 8.x can change PHP without a platform update. The reverse: a store on 1.7.8 can move to PHP 8.x only after updating to the latest 1.7.8.x (with caveats) or better — to 8.x. A store on 1.6 requires a platform migration first.

How do I check which modules are incompatible with PHP 8?

• In three ways: review module versions and update dates (years-old ones are candidates), run a PHPCompatibility scan on /modules, /override and the theme, and test on staging with debug mode enabled. The list of modules to update or replace is your work plan before deployment.

Will a PHP upgrade speed up a PrestaShop store?

Usually yes — newer PHP is faster, OPcache works better, and heavy operations gain from JIT. The real gain depends on hosting, configuration and modules. After the upgrade clear all cache layers (PrestaShop, Smarty, OPcache, CDN) and compare TTFB and PageSpeed Insights before/after.

Can I roll back the PHP upgrade if something goes wrong?

Yes — rolling back is switching the PHP version in the hosting panel (a minute) plus possibly reverting file changes. That is why the upgrade is done outside peak hours, with the old PHP version available on the server and a backup with a restore test. A transactional store should always have a rollback plan — regardless of the type of change.

Sources

• PrestaShop — developer documentation
• PrestaShop — system requirements
• PHP.net — supported versions
• endoflife.date — PHP support dates