PrestaShop 1.7 to 9: Symfony 6.4 and overrides to rewrite
Jumping straight from 1.7 to 9 means crossing Symfony 6.4, a PHP 8.1 minimum and a fully Twig back office all at once: a heavier leap than it looks.
What changes between 1.7 and 9
Between PrestaShop 1.7 and 9, the gap is a generation change, not just a version number. 1.7 runs a hybrid architecture: part of the back office and some front controllers on Symfony, the rest on plain Smarty with legacy admin controllers. PrestaShop 9 removes those: the back office now runs entirely on Symfony and Twig, and Symfony itself jumps to 6.4 LTS, against a much older 1.7/8 base. On PHP, 1.7 tops out at 7.4, while 9 needs 8.1 minimum and supports 8.2 to 8.4: no overlap between the two ranges.
PrestaShop 9 also adds a new Admin API, built on API Platform with OAuth authentication. On themes, 9 introduces Hummingbird, but Classic stays default at release: no mandatory rebuild, unlike 1.6-to-1.7.
The database structure changes at every major version; here, two steps (1.7 to 8, then 8 to 9) need covering by autoupgrade’s update scripts, whether run as one operation or two.
What breaks on a gap this size
- A module relying on a legacy Smarty admin controller finds that controller gone in 9: it doesn’t crash, it disappears.
- A core method override for 1.7 ignores the return types required since PHP 8.1: fatal error, not a warning.
- A module using curly-brace syntax for an array or string ($array{0}) stops running under PHP 8.1 or later.
- An integration built against the old web service API isn’t designed for the Admin API’s OAuth and needs revisiting.
- A module whose config.xml only declares compatibility up to 8 is rejected at install time on a 9.
How I approach this jump
-
Audit and route decision
I list modules, controller and back-office overrides, and integrations using the web service API, then decide how to split the work. autoupgrade steps through each version in turn and skips none: the update scripts for every intermediate version run either way, so the only question is whether I let them run in a single pass or stop at 8 to check the shop, especially with legacy modules still in use.
-
Independent full backup
A full SQL dump and complete file copy before anything else, plus autoupgrade’s own internal backup, kept off the server being changed.
-
Migration on a copy of the shop
The whole procedure is rehearsed on a test environment with target PHP in place, so return-type errors and missing controllers show up before they touch the live site.
-
The point of no return: running the database scripts
Once the schema scripts start running, only restoring the dump taken beforehand allows a clean rollback, triggered once modules and overrides are fully validated on test.
-
Rewriting legacy controllers and modules
Admin controllers still on Smarty and the modules depending on them are rewritten for the 9’s Symfony/Twig architecture, not just updated.
-
Going live
Once the test version is approved and target PHP confirmed, I schedule the switch for a low-traffic window.
How I check afterwards
I compare order, customer and product volumes between old and new databases after each step. I test checkout on every payment method, that rewritten controllers work for each back-office profile, and that no API integration is stuck on the old authentication. I watch the PHP error log during the first days, particularly return-type errors surfacing only when a rarely used feature gets exercised.
Related pages
-
PrestaShop migration from 1.7 to 8
The first step before 9, for module ecosystems not ready for a direct jump.
-
PrestaShop migration from 8 to 9
The second step, once PHP 8 compatibility is in place.
-
Incompatible modules after a migration
Why a module that used to work crashes or disappears after an update.
-
Checklist before a migration
What to check and back up before a migration.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.