Migration PrestaShop 1.7 vers 8 : thème, modules et PHP à vérifier avant la bascule

Une mise à jour de PrestaShop 1.7 vers 8 se prépare par trois vérifications, dans cet ordre : la version de PHP, chaque module, puis le thème. Le module officiel, l’Update Assistant, garde les données et le thème, mais désinstalle les modules qu’il juge incompatibles ; pour une version majeure, la documentation de l’éditeur recommande pourtant une boutique neuve. Au 14 octobre 2026, la 8 se vise comme une étape : elle plafonne à PHP 8.1, privé de correctifs depuis le 31 décembre 2025.

• PrestaShop 1.7 n’est plus maintenue depuis le 10 juin 2025
• PHP se règle avant la mise à jour, puis une seconde fois après
• Chaque module reçoit un verdict de compatibilité avant la mise à jour vers PrestaShop 8
• Le thème de la 1.7 reste compatible avec la 8 à quelques retouches près
• La mission se joue d’abord sur une copie de la boutique
• Le prix d’une mise à jour de PrestaShop 1.7 vers 8 se lit dans l’inventaire
• Version en base, droits d’écriture et modèles d’e-mails bloquent ou faussent la mise à jour vers PrestaShop 8
• Sources consultées
• Foire aux questions

PrestaShop 1.7 n’est plus maintenue depuis le 10 juin 2025

L’éditeur l’avait annoncé en janvier 2023 : le support étendu de la 1.7.8 s’arrêterait à la sortie de PrestaShop 9.0, publiée le 10 juin 2025. Le serveur d’une boutique 1.7 tourne au mieux sur PHP 7.4, que php.net a cessé de corriger le 28 novembre 2022.

La 8 rétablit les correctifs de l’éditeur, pour un temps compté. La branche 8.2 est en support étendu depuis le 4 juillet 2025 : elle ne reçoit plus que des correctifs critiques et de sécurité, jusqu’à la sortie de PrestaShop 10, sans date. Faites écrire dans la mission la suite prévue, c’est-à-dire ce que demande ensuite le passage de PrestaShop 8 à 9.

PHP se règle avant la mise à jour, puis une seconde fois après

La 1.7.8 fonctionne avec PHP 7.1 à 7.4 et PrestaShop 8 avec PHP 7.2.5 à 8.1, si bien que la bascule se fait sur la seule plage commune, de PHP 7.2.5 à 7.4. PHP monte ensuite à 8.1, la version que recommande la documentation de la 8. La base de données ne change pas d’exigence : MySQL 5.7 au minimum pour la 1.7 comme pour la 8, qui accepte aussi MariaDB 10.2.

Ouvrez Paramètres avancés > Informations : l’écran affiche la version complète de PrestaShop et celle de PHP. Le chiffre après « 1.7 » décide du chemin. Notez-le. Les versions 1.7.0 à 1.7.4 s’arrêtent à PHP 7.1, et la 8 réclame au moins PHP 7.2.5 : aucune version de PHP ne sert aux deux, et une mise à jour à l’intérieur de la 1.7, jusqu’à la 1.7.8, passe en premier.

D’après le README du module, l’Update Assistant ne propose que les versions compatibles avec le PHP du serveur. Une boutique 1.7.4 sur PHP 7.1 ne devrait se voir offrir aucune version 8 : le PHP explique alors l’absence de proposition.

La documentation de la 8 recommande 256 Mo de mémoire par script PHP (le réglage « memory_limit »), et le contrôle de l’outil bloque un réglage trop bas. Le changement de PHP chez l’hébergeur a sa propre mission : monter la version de PHP sans arrêter la boutique.

Chaque module reçoit un verdict de compatibilité avant la mise à jour vers PrestaShop 8

Le contrôle des prérequis compare chaque module installé à la version visée. Son avertissement, dans le code de l’outil, tient en une phrase : les modules incompatibles « will be uninstalled », c’est-à-dire désinstallés pendant la mise à jour. Ceux dont la compatibilité reste incertaine se vérifient à la main, un par un, sur la copie de la boutique et avec la liste de leurs réglages.

Autre réglage par défaut : l’outil désactive les modules ajoutés depuis la création de la boutique. Ils restent éteints jusqu’à leur réactivation dans Modules > Gestionnaire de modules.

Le guide des ruptures de la 8.0, écrit pour les développeurs, nomme ce qui casse un module conçu pour la 1.7 :

• des fonctions retirées, comme « Tools::jsonEncode » (conversion de données au format JSON) ;
• le passage à Symfony 4.4 et Twig 3, deux briques du back-office ;
• une vérification des quantités du panier juste avant la commande, que certains modules de paiement doivent reprendre ;
• la fin des taux de change en direct, qui touche une boutique vendant en plusieurs devises.

Chaque module finit dans l’une de trois cases : version pour la 8 publiée par son auteur, remplacement, ou adaptation du code. Scénario : une boutique de pièces détachées, équipée en 2019 d’un module de retrait en point relais, écrit d’abord à son auteur pour savoir s’il existe une version pour PrestaShop 8, et à quelles conditions pour une licence aussi ancienne.

Décrire mon besoin →

Le thème de la 1.7 reste compatible avec la 8 à quelques retouches près

À la sortie de la 8.0, le 26 octobre 2022, l’éditeur a écrit que la plupart des thèmes de la 1.7 devraient rester compatibles. Restent des retouches.

L’inscription et la connexion passent par deux pages distinctes, et l’adresse de l’inscription change : un lien « Créer un compte » écrit en dur dans le thème risque de ne plus mener à la bonne page.

Dans le gabarit du paiement, « payment.tpl », l’identifiant du formulaire change de nom. Un style ou un script écrit pour l’ancien identifiant perd sa cible : vérifiez l’affichage de chaque moyen de paiement proposé au client sur la copie de la boutique. Un thème enfant est une couche de retouches posée sur un thème d’origine. Il charge les fichiers de son parent quand le réglage « use_parent_assets » vaut « true » ; « false » garde le comportement de la 1.7.

L’outil signale enfin les fichiers du thème et du cœur modifiés ou supprimés. Toute retouche faite dedans « may be overwritten » : elle peut être écrasée. Demandez cette liste avant la bascule, et décidez où chaque retouche se reporte. Les surcharges (overrides), ces fichiers qui remplacent une partie du cœur, restent actives par défaut : chacune se teste.

La mission se joue d’abord sur une copie de la boutique

Le prestataire monte une préproduction, copie de la boutique invisible des clients. Il y règle PHP, lance l’Update Assistant et relève chaque message du contrôle des prérequis. Une erreur bloque. Un avertissement laisse passer, à condition d’être lu et tranché par écrit avant la bascule en production. L’outil exige la boutique en maintenance et le cache désactivé.

Ensuite, la documentation demande de réactiver les modules éteints, de créer un compte client et de passer une commande sur la boutique mise à jour, puis seulement de lever la maintenance. Ajoutez un paiement réel suivi d’un remboursement, et la réception des e-mails de commande.

La sauvegarde complète, images comprises, est l’option par défaut de l’outil. Gardez-la. Faites écrire que le prestataire remet la boutique en état, sans facturation en plus, si une commande échoue après la bascule. Exigez le verdict et la décision pour chaque module, la liste des fichiers modifiés et le compte rendu des tests. La version atteinte doit être la dernière publiée de la branche 8.2.

Le prix d’une mise à jour de PrestaShop 1.7 vers 8 se lit dans l’inventaire

Cinq éléments font bouger le prix. La sous-version de départ : de 1.7.0 à 1.7.4, une mise à jour intermédiaire s’ajoute. Le nombre de modules non natifs : comptez les lignes du Gestionnaire de modules, natifs exclus, et vous tenez le nombre de verdicts à obtenir. Puis l’origine du thème, le nombre de fichiers modifiés et de surcharges, et le changement de PHP. Une licence de module à renouveler se règle à son auteur, non au prestataire.

Décrire mon besoin →

Version en base, droits d’écriture et modèles d’e-mails bloquent ou faussent la mise à jour vers PrestaShop 8

Une version des fichiers différente de celle inscrite en base de données arrête l’outil dès le contrôle : son message désigne la valeur « PS_VERSION_DB » de la table de configuration. Le prestataire remet d’abord les deux d’accord.

Des dossiers fermés en écriture pour l’utilisateur qui exécute PHP bloquent aussi l’outil. Vérifiez ces droits avec l’hébergeur avant le jour fixé.

L’option qui régénère les modèles d’e-mails, activée par défaut, écrase les vôtres s’ils ont été personnalisés, prévient la documentation. Désactivez-la et testez les e-mails après coup.

Dans le message du formulaire de cette page, reportez la version complète de PrestaShop, celle de PHP et le nombre de modules non natifs.

Sources consultées

• PrestaShop, documentation développeur, « System requirements for PrestaShop 1.7 », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 8, « System requirements », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur, « Notable changes in PrestaShop 8.0 », consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, « Keep PrestaShop up-to-date » et pages « Update », « Update from the back office » et « Post-update checklist », consulté le 14 octobre 2026.
• PrestaShop, dépôt du module Update Assistant (« autoupgrade »), fichiers « README.md » et « UpgradeSelfCheck.php », consulté le 14 octobre 2026.
• PrestaShop, « PrestaShop 8.0 Is Available », consulté le 14 octobre 2026.
• PrestaShop, « PrestaShop 1.7.8 is now in the extended support phase », consulté le 14 octobre 2026.
• PrestaShop, « PrestaShop 9 is available », consulté le 14 octobre 2026.
• PrestaShop, « PrestaShop 8.2.x is now in the extended support phase », consulté le 14 octobre 2026.
• php.net, « Unsupported Branches », consulté le 14 octobre 2026.

Foire aux questions

Combien de temps la boutique reste-t-elle fermée pendant la mise à jour ?

L’Update Assistant exige le mode maintenance : la boutique reste fermée du lancement jusqu’aux tests finaux. La durée dépend du volume des fichiers, de la base et de la sauvegarde choisie. Une sauvegarde partielle, sans les images, est plus légère mais impose une autre copie des images. Faites mesurer cette durée sur la préproduction, puis calez la bascule sur votre heure la plus creuse.

Les clients gardent-ils leur compte et leurs commandes ?

Oui. La documentation de l’éditeur indique que le processus de mise à jour préserve les données de la boutique, ses modules compatibles et son thème. Clients, commandes, produits et adresses restent en place. Peuvent changer : l’adresse de certaines pages, comme celle de l’inscription, et le comportement des modules réinstallés.

Peut-on revenir en 1.7 si la mise à jour se passe mal ?

Oui, depuis la sauvegarde prise juste avant la bascule, que le même module sait restaurer. La restauration remet aussi la base dans son état antérieur : une commande passée entre la bascule et le retour arrière disparaît. Fixez le critère de retour arrière à l’avance, et notez les commandes reçues entre-temps.

Faut-il passer par la 8 si l’objectif est la 9 ?

Pas obligatoirement : le choix dépend de vos modules et de votre thème. La 8 sert d’étape parce qu’elle partage une version de PHP avec la 1.7 et une autre avec la 9. L’autre route repart d’une installation neuve. Les deux se comparent sur la migration de PrestaShop 1.7 vers 9.