PrestaShop 1.6 to 1.7: the step that changes the theme
Moving from PrestaShop 1.6 to 1.7 is the first compulsory step to go further: the theme engine changes, part of the back office moves onto Symfony, and the hook for payment methods at checkout isn’t the same one anymore. Here’s what actually breaks and how I handle it.
What actually changes between 1.6 and 1.7
PrestaShop 1.6 runs on a proprietary “legacy” framework, Smarty-only templating, with a default theme called Default. From 1.7, part of the admin and some front controllers move onto Symfony with Twig, Smarty staying in use for the rest: a hybrid architecture. The default theme also changes name, Classic replacing Default, built on Bootstrap 4 where the 1.6 theme was on Bootstrap 3. A 1.6 theme, even a customised one, doesn’t install as-is on 1.7: it has to be rebuilt template by template.
The change that most often breaks shops concerns checkout. On 1.6, payment modules hook into displayPayment. From 1.7, that hook is replaced by paymentOptions. A module that hasn’t been updated simply stops appearing at the payment step, with no visible error: the customer can’t pay.
The database structure also changes, with new tables and renamed columns: a raw SQL dump restored as-is isn’t reliable, it’s the official autoupgrade module that runs the needed schema scripts.
What typically breaks during a 1.6 to 1.7 migration
- The payment module disappears from checkout with no error message: the displayPayment hook is no longer called.
- The theme shows a blank page or broken rendering: the 1.6 .tpl templates no longer match the 1.7 folder structure.
- Some back-office screens move, part of the admin now being handled by Symfony controllers.
- Modules using the old curly-brace array syntax (e.g. $array{0}) throw fatal errors if PHP was also upgraded.
How I run a 1.6 to 1.7 migration
-
Auditing modules and the theme
I list every module and version, checking each declares 1.7 compatibility — same for the theme.
-
Full backup before touching anything
Every file, a full database dump, and the configuration of critical modules (payment, carriers), before running anything.
-
Migration on a copy of the shop
I run autoupgrade on a test environment, never production. It backs up files and database again first, with a restore option if it fails.
-
Rebuilding the theme and swapping the payment hook
I rebuild the theme on top of Classic and check every payment module uses paymentOptions rather than the old displayPayment.
-
Checking, then switching over
Once the test shop is approved, I schedule the switch for a low-traffic window, to limit impact on orders in progress.
What I back up and check afterwards
Before running anything, I back up the entire site tree, a full database dump, and the payment and carrier module configuration, the most hook-sensitive — kept outside autoupgrade/backup, since that folder can be overwritten later.
After the migration, I check that orders, customers and catalogue products match exactly, that main URLs still respond with the right status code, and that redirects work. I also run a full checkout to confirm the payment module appears via paymentOptions.
// PS 1.6
$this->registerHook('displayPayment');
// PS 1.7+
$this->registerHook('paymentOptions');To prepare for or complete this migration
-
Pre-migration checklist
Everything I check before starting a PrestaShop migration, whatever the version.
-
Incompatible modules
How I spot modules that won’t survive the migration and what I replace them with.
-
Keeping your SEO
What to check on URLs and redirects so you don’t lose existing rankings.
-
Migrating without stopping sales
The method for going live without blocking orders in progress.
- PHP 5.2 to 7.1 PrestaShop 1.6
- PHP 7.2 to 7.4 depending on sub-version PrestaShop 1.7
devdocs.prestashop-project.org
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.