PrestaShop 1.7 to 8: PHP 8 and a TypeScript back office
The most common upgrade today: PHP 8 compatibility, admin JavaScript migrated to TypeScript, and modules that need checking one by one before anything is touched.
What actually changes between 1.7 and 8
Technically, the 1.7-to-8 jump is less radical than 1.6-to-1.7: the hybrid Smarty/Symfony architecture and Classic theme stay in place. What really changes is PHP compatibility: PrestaShop 8 needs PHP 7.2.5 minimum, supports 8.0 and 8.1 from launch, then 8.2 from version 8.2 (September 2024). No 1.7.x version runs under PHP 8, Smarty crashes immediately: migrating to 8 almost always means raising PHP alongside PrestaShop, multiplying failure points.
On the back office side: admin JavaScript migrates to TypeScript from 8.0, and custom overrides or scripts built for 1.7 no longer plug in the same way. Many core methods now also declare a return type, a consequence of PHP 8.1: an override that doesn’t match that signature triggers a fatal error, not a warning.
The database structure also changes at every major version: new tables, renamed columns. Restoring a raw SQL dump as-is on a fresh 8 isn’t reliable; autoupgrade runs the matching update scripts.
Modules and functions that cause trouble
- The back office throws a fatal error at first access after PHP 8.1, from a missing return type on an overridden method.
- A module installed under 1.7 is missing or greyed out after the update, since config.xml doesn’t declare compatibility with 8.
- A custom module still uses curly-brace syntax for arrays or strings ($array{0}), removed in PHP 8: the page crashes with a syntax error.
- A custom back-office script or override stops working because of the JavaScript-to-TypeScript move in the admin.
- A module’s $ps_versions_compliancy property, frozen on the old version, blocks activation even though the code would work unchanged.
How I run this migration
-
PHP and module audit
I check the current and target PHP version, and list modules with compatibility declared in config.xml and $ps_versions_compliancy.
-
Independent full backup
Database dump and full file copy before anything, plus the internal backup autoupgrade creates itself.
-
Migration on a copy of the shop
Autoupgrade first runs on a test environment: file and database backup, then the schema update scripts.
-
The point of no return: the database update
Once the database scripts start running, going back isn’t a matter of undoing files: only restoring the dump taken beforehand allows a clean rollback, triggered only once files and modules are confirmed ready.
-
Fixing modules and overrides
I update or replace modules blocked by outdated compatibility or the curly-brace syntax removed in PHP 8, and adapt back-office overrides affected by TypeScript.
-
Going live
Once the test version is approved, I schedule the switch for a low-traffic window, PHP included, to limit impact on orders.
How I check nothing was lost afterwards
After going live, I compare orders, customers and products between old and new databases. I test the full checkout flow on every payment method, the key front pages (home, category, product) and back-office access. I also check the PHP error log during the first hours: that’s usually where overrides missing a return type show up.
Related pages
-
Checklist before a migration
What to check and back up before any migration.
-
Incompatible modules after a migration
Why a working module crashes or disappears after an update, and how to check compatibility.
-
Moving PrestaShop to PHP 8
What a hosting PHP version change involves, regardless of PrestaShop version.
-
PrestaShop migration from 8 to 9
The next step once the shop is stable on 8.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.