# 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.

- Source canonique : [https://allaux.fr/en/prestashop/migration/1-6-vers-1-7](https://allaux.fr/en/prestashop/migration/1-6-vers-1-7)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Before starting anything, list your payment modules: any still hooked to displayPayment vanishes from the 1.7 checkout, where only paymentOptions is called, and without a single error message. Budget for a theme rebuild too: a 1.6 theme built on Default will not install on 1.7, whose Classic theme uses a different template tree.

## 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

1. **Auditing modules and the theme** — I list every module and version, checking each declares 1.7 compatibility — same for the theme.
2. **Full backup before touching anything** — Every file, a full database dump, and the configuration of critical modules (payment, carriers), before running anything.
3. **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.
4. **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.
5. **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.

## The point of no return to know about

> The autoupgrade module stores its backup in /autoupgrade/backup. Running a new migration on top of a previous attempt without exporting that backup elsewhere overwrites it: from that point, going back becomes much harder.

## 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.

## monmodule.php

```
// 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. ([/prestashop/migration/checklist-avant-migration](/prestashop/migration/checklist-avant-migration))
- **Incompatible modules** — How I spot modules that won’t survive the migration and what I replace them with. ([/prestashop/migration/modules-incompatibles](/prestashop/migration/modules-incompatibles))
- **Keeping your SEO** — What to check on URLs and redirects so you don’t lose existing rankings. ([/prestashop/migration/conserver-son-referencement](/prestashop/migration/conserver-son-referencement))
- **Migrating without stopping sales** — The method for going live without blocking orders in progress. ([/prestashop/migration/migrer-sans-interruption-de-vente](/prestashop/migration/migrer-sans-interruption-de-vente))

| Valeur | Description |
|---|---|
| PHP 5.2 to 7.1 | PrestaShop 1.6 |
| PHP 7.2 to 7.4 depending on sub-version | PrestaShop 1.7 |

Source : devdocs.prestashop-project.org

## FAQ

### Why did the payment module disappear from checkout after the migration?

Almost always the hook. On 1.6, payment modules hook into displayPayment; from 1.7, that hook is replaced by paymentOptions. If not updated, the module simply stops appearing, with no visible error.

### Will my customised 1.6 theme work as-is on 1.7?

No. The default theme changes name and base (Classic replaces Default) and the template structure changes with the hybrid architecture: it needs adapting or rebuilding template by template.

### Is it risky to stay on PrestaShop 1.6?

Official maintenance stopped on 30 June 2019: exposure to unpatched security flaws, without knowing precisely which ones or when they’ll be exploited.

### Which PHP version should I target after migrating to 1.7?

Depends on the sub-version: only 1.7.5 to 1.7.8 support PHP 7.2, and only 1.7.8 supports PHP 7.4. No 1.7.x version runs under PHP 8.