Vous avez cliqué sur « Mettre à jour » dans le gestionnaire de modules. Le bandeau est vert, la nouvelle version s’affiche. Le lendemain, un client vous écrit : le bouton PayPal a disparu de la page de paiement. Pas d’erreur, pas de page blanche. Une mise à jour de module PrestaShop peut rater de plusieurs façons, et certaines ne laissent aucune trace à l’écran.
Voici ce que fait le bouton, lu dans le code de PrestaShop 1.6 à 9.2, puis la méthode pour mettre à jour sans casse et le moment où il faut s’arrêter.
La version enregistrée en base décide de tout : PrestaShop compare la version des fichiers du module à celle de la table ps_module, et ne joue les scripts de mise à jour que sur cet écart.
En 1.7.8, 8 et 9, un script en échec désactive le module, et un nouveau clic ne le rejouera pas.
Une mise à jour à la fois, sur une copie de la boutique, jamais à la veille d’un pic de ventes.
Un module se désactive sans back-office : par FTP, en ligne de commande ou dans la base.
En panne maintenant ? Désactiver le module sans back-office ou 09 72 03 59 17, 7j/7, de 8 h à 22 h.
Ce que fait le bouton « Mettre à jour »
Pour mettre à jour un module PrestaShop sans risque : sauvegarde des fichiers et de la base, essai sur une copie de test, bouton « Mettre à jour » du gestionnaire de modules, puis vérification de la version enregistrée en base. Cette dernière étape est la seule qui prouve que la mise à jour a eu lieu.
Chaque module déclare sa version dans son fichier principal. La boutique, elle, garde la version installée dans la colonne version de la table ps_module. Quand le fichier annonce une version plus récente que la base, le module « doit être mis à jour ».
La mise à jour elle-même, ce sont les scripts du dossier upgrade/ du module : upgrade-1.2.0.php, upgrade-1.3.0.php, etc. PrestaShop joue, dans l’ordre, ceux compris entre la version en base et celle des fichiers. Chacun ajoute une colonne, une table, un réglage ou un crochet (hook) : copier les fichiers ne fait rien de tout cela. Quand ces scripts se déclenchent dépend de la version.
| Version ou méthode | Quand les scripts se jouent | Ce que ça change pour vous |
|---|---|---|
| 1.6 | À l’ouverture de la page Modules du back-office, sans aucun clic | La version en base suit le dernier script réussi. Après un échec, les scripts restants se rejouent à la prochaine ouverture de la page Modules, mais le module reste désactivé jusqu’à ce que vous le réactiviez. Voir la maintenance d’une boutique PrestaShop 1.6 ou 1.7. |
| 1.7.8, 8 et 9 bouton ou zip importé | Au clic, et seulement au clic | Ouvrir le gestionnaire ne joue rien. Un script en échec désactive le module, et la nouvelle version est enregistrée quand même. |
| 1.7.8 et plus fichiers copiés par FTP | Jamais, tant que personne ne clique | Le gestionnaire affiche un bouton « Mettre à jour ». D’ici là, le code neuf tourne sur l’ancienne base. |
| Ligne de commande 1.7.8 et plus | Quand la commande est lancée | Les mêmes scripts que le bouton. En 8 et 9, rien n’est téléchargé : seul le code déjà présent est migré. |
Nous n’avons pas vérifié le comportement des versions 1.7.0 à 1.7.7 dans le code : traitez-les avec la prudence de la ligne 1.7.8.
Quatre façons dont une mise à jour de module tourne mal
En 1.7.8, 8 et 9, fiez-vous à l’état du module après coup plutôt qu’au message affiché.
Module désactivé après la mise à jour : le script a échoué
Un script de migration répond « échec ». PrestaShop arrête la série et désactive le module. Puis le cœur enregistre quand même la nouvelle version dans ps_module : pour lui, le module est à jour.
- le back-office affiche un message de la forme « L’action … est impossible pour le module … » (en anglais, « Cannot … module ») ;
- le module est désactivé, et la version en base est déjà la nouvelle ;
- les scripts qui restaient ne seront jamais rejoués : un nouveau clic ne trouve plus d’écart, donc plus rien à faire.
Réactiver le module à ce stade fait tourner du code neuf sur une base migrée à moitié. Arrêtez-vous là.
Erreur dans le script : message d’erreur ou page 500
Ici, le script plante. Si l’erreur est une exception, le gestionnaire l’attrape et affiche le même genre de message. Mais le module reste actif et sa version en base ne bouge pas : fichiers neufs, base ancienne, et les scripts déjà passés seront rejoués au prochain essai.
Une erreur PHP fatale (fonction absente, PHP trop ancien pour le module) n’est attrapée par rien : page 500. En 1.6, l’erreur remonte directement dans la page Modules.
Fichiers neufs, base ancienne : la migration jamais jouée
Le dossier du module est remplacé par FTP, et personne ne clique ensuite. Depuis la 1.7.8, rien ne se joue tout seul : le code neuf cherche une colonne ou un réglage absents, et la boutique répond pourtant normalement. Seul indice, un bouton « Mettre à jour » qui attend dans le gestionnaire.
Un bug signalé en 9.2.0 (ticket #43190, ouvert le 9 octobre 2026) produit le même état avec un zip importé, module désactivé en prime, quand un autre module présent dans modules/ plante au chargement.
Le cœur ou le script disent OK sans rien faire
Le plus traître, parce que tout est vert. Deux mécanismes y mènent.
Le script ment. Un script de migration doit renvoyer « vrai » seulement si son travail a réussi. Celui de ps_eventbus pour la version 4.1.0 renvoie « vrai » quel que soit le résultat de sa requête SQL (ticket #501 du dépôt ps_eventbus). Si la requête échoue, le module est quand même enregistré en 4.1.1, la colonne last_seek_key manque, et la synchronisation tombe ensuite en erreur SQL. Le script, tel qu’il est publié (requête abrégée) :
function upgrade_module_4_1_0()
{
$db = Db::getInstance();
$db->execute('ALTER TABLE ... ADD COLUMN `last_seek_key` ...');
return true;
}Le cœur lit l’ancienne version. En 1.7.8 et 8, l’ancien module est parfois déjà chargé en mémoire : c’est le cas d’un module de paiement ou « cloud » présent sur toutes les pages du back-office. PrestaShop lit alors l’ancienne version, conclut qu’il n’y a rien à migrer et répond « succès ». En 9.1 et 9.2, la version est lue dans le fichier PHP.
Pour votre prestataire : où le voir dans le code (8.2.8)
classes/module/Module.php:622
script en échec : disable()
src/Core/Module/ModuleManager.php:379
version forcée à la cible malgré l'échec
(1.7.8 : src/Adapter/Module/ModuleDataUpdater.php:114)
src/PrestaShopBundle/Controller/Admin/Improve/ModuleController.php:242
exception attrapée, module laissé actif
ModuleController.php:287
message « Cannot ... module »
classes/module/Module.php:1477
fichier inclus seulement si la classe n'est pas déjà chargéeLe schéma ci-dessous résume ce qui peut arriver après le clic, et ce qu’il faut faire dans chaque cas.
Les modules qui cassent le plus souvent
Ceux-là méritent une copie de test à chaque mise à jour, même mineure.
- Paiement (PayPal, Stripe, PrestaShop Checkout…) : une migration manquée peut faire disparaître un moyen de paiement sans aucune erreur visible. Si plus rien ne s’affiche au paiement, voir aucun moyen de paiement.
- Page builders et modules de thème : un module désactivé, et l’accueil perd son slider ou ses polices alors que la page répond normalement.
- Modules PrestaShop « cloud » : ps_mbo a bloqué le back-office au passage de PrestaShop 8.2.1 à 9.0.0 (ticket #38983, juin 2025) ; une perte du back-office après sa mise à jour 4.13.3 vers 4.14.0 a été signalée (#39625). ps_accounts traîne une boucle de connexion au back-office (#39678, ouverte), ps_eventbus un échec de 4.0.16 vers 4.1.0 (#486, août 2026).
- Transporteurs (Colissimo, Mondial Relay) : Mondial Relay 4.x exige PHP 8 et provoque une erreur fatale en PHP 7.4. Une migration ratée désactive le transporteur : il disparaît du tunnel.
- Recherche à facettes : le passage de ps_facetedsearch 4 à 5 change l’ordre des listes de produits et laisse des libellés non traduits.
Pourquoi « Tout mettre à jour » est une mauvaise idée
Une boutique compte de 70 à 150 modules actifs environ, et la liste des mises à jour annoncées ne dit rien de leur risque. Quelques mesures faites sur les boutiques que nous suivons :
- le 25 septembre 2026, notre outil signalait 849 mises à jour de modules sur ces boutiques ;
- une partie n’en était pas : pour les modules livrés avec le cœur, le catalogue Addons propose parfois une version plus ancienne que celle déjà installée ;
- environ une sur cinq était une version majeure ; d’autres touchaient des modules de paiement ou de transport, à valider avec le marchand avant de les poser ;
- une vingtaine seulement pouvaient être posées sans précaution ;
- sur 78 jours de l’été 2026, les marchands ont fait plus d’une action par jour sur leurs modules depuis le back-office (installation, mise à jour, réinitialisation) ; environ une sur 25 a causé une panne, dont un tunnel de commande coupé 23 h ;
- une montée de version de PrestaShop met à jour jusqu’à une cinquantaine de modules d’un coup.
« Tout mettre à jour » enchaîne des dizaines de migrations sans test : si la boutique tombe, impossible de savoir laquelle accuser. À l’approche des fêtes, mieux vaut geler les mises à jour avant le Black Friday.
Copie de test, une mise à jour à la fois, version en base vérifiée après chaque passage. Maintenance PrestaShop à 69 € HT/mois, sans engagement, audit complet offert au démarrage.
Mettre à jour un module PrestaShop sans casser la boutique
Sept gestes, dans cet ordre.
- Sauvegardez les fichiers et la base, ensemble : les fichiers seuls ne défont pas une migration.
- Lisez le journal des changements du module : version majeure, version de PHP exigée, version de PrestaShop prise en charge.
- Mettez à jour sur une copie de test, puis passez une commande de bout en bout.
- Un module à la fois, avec un contrôle entre chaque.
- Jamais avant un pic : soldes, campagne d’e-mails, Black Friday.
- Vérifiez la version en base après la mise à jour (requête ci-dessous, préfixe
ps_par défaut). Elle doit être celle du nouveau module. - Videz le cache, OPcache compris : en 8.2 et 9.2, le bouton « Vider le cache » de Paramètres avancés > Performances vide aussi OPcache.
SELECT name, version, active
FROM ps_module
WHERE name = 'nom_du_module';Mettre à jour un module PrestaShop manuellement
Le plus sûr : importer le zip depuis le gestionnaire de modules (« Importer un module ») ; le module étant installé, PrestaShop traite l’import comme une mise à jour. Sinon, copiez le dossier dézippé dans modules/ par FTP, puis cliquez sur « Mettre à jour » dans le gestionnaire, sur la copie de test d’abord.
Ne désinstallez pas le module avant : la désinstallation efface souvent ses réglages. Sauvegardez aussi vos gabarits personnalisés.
Si vous ou votre prestataire avez un accès SSH : la ligne de commande
Depuis le dossier de la boutique :
php bin/console prestashop:module upgrade nom_du_module- vérifiée en 1.7.8, 8.2.8 et 9.x ;
- en 8 et 9, elle ne télécharge rien : elle joue les migrations du code déjà présent sur le disque ;
- en 1.7, une mise à jour Addons ne se télécharge que depuis un back-office connecté ;
- le code retour vaut 0 même en cas d’échec : lisez le message, puis vérifiez la version en base.
Désactiver un module PrestaShop sans back-office quand il a cassé la boutique
Paiement coupé ou page blanche, sans FTP ni sauvegarde : arrêtez-vous ici et appelez le 09 72 03 59 17, 7j/7, de 8 h à 22 h. Sinon, voici comment désactiver un module PrestaShop, de la méthode la plus accessible à la plus risquée.
Renommer le dossier par FTP. Passez modules/nom_du_module en modules/nom_du_module_off : PrestaShop ne trouve plus le module. Pratique courante, non officielle. Ses surcharges (overrides) restent dans override/ : si l’erreur venait de là, la panne continue. Si une page 500 apparaît ensuite, videz le cache par FTP : dossier var/cache/prod (1.7 et plus), fichier cache/class_index.php en 1.6. Pour revenir en arrière, renommez dans l’autre sens. Ne supprimez jamais le dossier par FTP, la documentation de PrestaShop l’interdit.
Accès SSH ou phpMyAdmin
En 1.7.8 et plus, la commande propre, qui retire aussi les surcharges du module :
php bin/console prestashop:module disable nom_du_moduleEn base : PrestaShop exécute un module tant qu’il a des lignes dans ps_module_shop. Passer active = 0 dans ps_module seul ne coupe rien : il faut supprimer ces lignes, une par boutique en multiboutique. Comme le renommage, cette suppression laisse les surcharges dans override/. Sauvegardez la base avant, exportez ces lignes pour pouvoir les remettre, puis videz le cache. Si une mise à jour du cœur est bloquée, ne touchez pas à la base.
DELETE ms FROM ps_module_shop ms
JOIN ps_module m ON m.id_module = ms.id_module
WHERE m.name = 'nom_du_module';Où s’arrêter avant d’aggraver la panne
- Un module de paiement : chaque essai en production peut coûter des commandes.
- Une migration à moitié jouée (module désactivé après la mise à jour, version déjà avancée) : réactiver ou recliquer ne rejoue rien, il faut rejouer les scripts manquants à la main.
- Une version majeure : la structure de la base change souvent, le retour arrière aussi.
- Le retour à l’ancienne version : PrestaShop ne prévoit que des scripts de montée. Remettre d’anciens fichiers ne défait rien en base ; seule une sauvegarde des fichiers et de la base, restaurée ensemble, ramène l’état d’avant.
Module PrestaShop cassé après une mise à jour : par où commencer ?
Trois réponses, puis la cause probable, ce que vous pouvez vérifier sans risque et le moment où il vaut mieux s’arrêter.
Vos réponses restent dans votre navigateur : rien n’est envoyé ni enregistré.
Demandez d’abord à votre prestataire comment il a procédé (bouton, zip, FTP ou mise à jour du cœur) et à quelle heure : la réponse peut changer le diagnostic.
Une erreur PHP a probablement arrêté la migration
Une erreur PHP fatale (fonction absente, PHP trop ancien pour le module) n’est rattrapée par rien : page 500, et la version en base ne bouge pas, même si des scripts sont déjà passés. Fichiers copiés par FTP sans clic : aucune migration n’a été jouée, le code neuf tourne sur l’ancienne base.
Le journal d’erreurs PHP de votre hébergeur : la dernière erreur fatale nomme un fichier. S’il est dans modules/nom_du_module/, vous tenez le module en cause. Notez l’heure et le message, sans rien modifier.
Vous n’avez ni FTP ni sauvegarde récente, le module touche au paiement, ou vous comptiez remettre les fichiers de l’ancienne version : recopier d’anciens fichiers ne défait rien en base. Avec un accès FTP, voyez d’abord comment désactiver le module sans back-office.
Le module ne s’exécute plus : vérifiez d’abord son état
S’il apparaît désactivé, un script de migration a renvoyé un échec : PrestaShop l’a désactivé, puis a quand même enregistré la nouvelle version en base. Resté actif après un message d’erreur, sa migration s’est arrêtée en route. Fichiers copiés par FTP sans clic : le code neuf tourne sur l’ancienne base.
Rechargez le gestionnaire de modules et notez l’état du module : actif ou désactivé, avec ou sans bouton « Mettre à jour ». Côté boutique, avancez une commande test jusqu’au choix du paiement, sans payer.
C’est le module de paiement : ne le réactivez pas et ne relancez pas la mise à jour sur la boutique en ligne. Chaque essai en production peut coûter des commandes. Un nouveau clic ne rejoue rien si le module a été désactivé, et rejoue une seconde fois les scripts déjà passés s’il est resté actif.
Un script de migration a échoué : migration à moitié jouée
Au clic sur « Mettre à jour », y compris après une copie par FTP, un script de migration a renvoyé un échec. PrestaShop a désactivé le module, puis enregistré quand même la nouvelle version en base. Les scripts suivants n’ont pas été joués, et un nouveau clic ne les rejouera pas.
Rechargez le gestionnaire : module désactivé et plus de bouton « Mettre à jour », c’est ce cas. En lecture seule dans phpMyAdmin, la table ps_module (le préfixe peut différer) montre la version enregistrée.
Vous alliez réactiver le module tel quel : son code neuf tournerait sur une base migrée à moitié. Il faut rejouer les scripts manquants à la main, sur une copie de test. Même chose s’il touche au paiement ou au transport.
Le même message pour deux pannes : l’état du module les distingue
Module désactivé, version déjà avancée : un script a renvoyé un échec, et les suivants ne seront jamais rejoués. Module resté actif, version inchangée : une exception (erreur rattrapée par PrestaShop) a interrompu la migration ; fichiers neufs sur base ancienne, et les scripts déjà passés seront rejoués au prochain clic.
Rechargez le gestionnaire de modules, puis notez l’état du module (actif ou désactivé) et si « Mettre à jour » s’affiche encore. Bouton encore là : la version en base est restée sous celle des fichiers.
Vous alliez recliquer sur la boutique en ligne : désactivé, rien ne sera rejoué ; actif, les scripts déjà passés repartiront une seconde fois. Faites l’essai sur une copie de test, ou arrêtez-vous là si le module touche au paiement.
La version en base n’a pas suivi celle des fichiers
Le bouton reste tant que la version en base est inférieure à celle des fichiers. Après un clic, une exception (erreur rattrapée par PrestaShop) a sans doute interrompu la migration : module resté actif, version inchangée, et les scripts déjà passés seront rejoués au prochain clic. Autre cause : des fichiers copiés sans qu’on clique ensuite.
Rechargez la page : juste après le clic, l’écran peut afficher la nouvelle version quoi qu’il arrive en base. Si le bouton est toujours là, comparez, en lecture seule, la version du fichier principal du module et celle de la table ps_module.
Vous alliez recliquer sur la boutique en ligne : rejouez la mise à jour une seule fois, sur une copie de test, après une sauvegarde de la base. Arrêtez-vous aussi si le module touche au paiement.
Fichiers neufs, base ancienne : la migration n’a pas été jouée
Depuis la 1.7.8, copier les fichiers par FTP ne joue aucune migration : le gestionnaire affiche « Mettre à jour » et la base garde l’ancienne version jusqu’au clic. Entre-temps, le code neuf tourne sur l’ancienne base, même quand rien ne se voit.
Dans le gestionnaire de modules, le bouton « Mettre à jour » doit apparaître pour ce module. Testez les fonctions qu’il assure (paiement, livraison, affichage) avec une commande test, sans payer.
Vous alliez cliquer « Mettre à jour » directement sur la boutique en ligne : faites-le d’abord sur une copie de test, après une sauvegarde de la base, puis vérifiez la version enregistrée.
Tout dit OK : rien ne prouve encore que la migration a eu lieu
Certains scripts renvoient « réussi » quoi qu’il arrive : celui de ps_eventbus pour la version 4.1.0, par exemple. En 1.7.8 et 8, si l’ancienne version du module était déjà chargée, le cœur peut conclure qu’il n’y a rien à migrer.
Rechargez le gestionnaire, car la réponse affichée au clic ne reflète pas forcément la base. Comparez, en lecture seule, la version de la table ps_module à celle du fichier, puis passez une commande test sans payer.
Les versions concordent mais une fonction manque, ou vous pensiez rejouer des scripts à la main : ce n’est plus une vérification mais une intervention, à faire sur une copie de test.
La mise à jour de PrestaShop a aussi touché vos modules
L’Update Assistant met à jour au passage les modules natifs et partenaires, paiement et transport compris. Il désactive par défaut les modules non natifs si la version cible est inférieure à 9, sans les réactiver. Si la migration d’un module échoue, il le désactive et garde l’ancienne version en base.
En lecture seule dans phpMyAdmin, des noms commençant par UA_ dans la table ps_module signalent une montée interrompue : PrestaShop ne charge jamais ces modules. Dans le gestionnaire, notez les modules désactivés et ceux qui proposent encore « Mettre à jour ».
Des modules UA_ figurent dans ps_module, la boutique est en panne ou le paiement fait partie des modules désactivés : ne relancez pas la mise à jour. Réactiver un module dont la migration a échoué fait tourner son code neuf sur l’ancienne base.
En 1.6, les migrations se jouent à l’ouverture de la page Modules
En 1.6, les scripts de migration se jouent tout seuls à l’ouverture de la page Modules, sans clic. Si l’un échoue, le module est désactivé et la version en base s’arrête au dernier script réussi. Une erreur dans un script remonte sur la page Modules elle-même.
En lecture seule dans phpMyAdmin, la table ps_module (le préfixe peut différer) donne la version enregistrée et l’état du module. Évitez de rouvrir la page Modules en boucle : chaque ouverture rejoue les scripts restants.
Le module est désactivé : les scripts restants se rejouent à la prochaine ouverture de la page Modules, mais il reste désactivé jusqu’à ce qu’on le réactive. Réactivez-le seulement une fois sa migration vérifiée, jamais si c’est le paiement.
Comportement non vérifié pour ce cas : prudence
Nous n’avons pas vérifié ce cas dans le code (1.7 avant 1.7.8, version inconnue, ou mise à jour du cœur en 1.6). Dans les versions vérifiées, PrestaShop compare la version des fichiers à celle enregistrée en base, et un script de migration en échec désactive le module.
Relevez la version de PrestaShop (Paramètres avancés > Informations), puis l’état du module dans le gestionnaire : actif ou désactivé, avec ou sans bouton « Mettre à jour ». Notez l’heure de la mise à jour et le message affiché.
Vous alliez appliquer une manipulation lue pour une autre version : ni réactivation, ni nouveau clic, ni retour à l’ancienne version sans sauvegarde. Si la boutique est en panne ou le paiement coupé, ne tentez rien de plus.
Vous préférez que vos mises à jour soient testées sur une copie avant la boutique ?
09 72 03 59 17, réponse en moins d'une heure, 7j/7, de 8 h à 22 h. Intervention dès 150 € HT, prix fixe validé avant toute intervention ; ces 150 € sont déduits si vous passez ensuite à la maintenance.
Mise à jour de PrestaShop : ce que l'Update Assistant fait à vos modules
Une montée de version avec l'Update Assistant touche aussi vos modules, autrement que le bouton.
- Modules non natifs désactivés par défaut quand la version cible est inférieure à 9. Ils ne sont pas réactivés ensuite : c'est à vous de le faire.
- Option retirée vers la 9 depuis la version 7.6.0 de l'Update Assistant (25 mars 2026), remplacée par un contrôle de compatibilité des modules. La documentation officielle la décrit encore.
- Quarantaine : pendant la mise à jour de la base, tous les modules sont renommés
UA_nom_du_moduledans la tableps_module, puis libérés. Une montée interrompue laisse des modulesUA_que PrestaShop ne charge jamais. - Modules natifs et partenaires mis à jour au passage, paiement et transport compris, parfois avec un saut de version majeure.
- Migration en échec pendant la montée : le module est désactivé et l'ancienne version reste en base, l'inverse du bouton. La montée continue et se termine en succès.
Comparez ensuite la liste des modules actifs à celle d'avant. Si l'assistant s'arrête en route, voir mise à jour de PrestaShop bloquée.
Questions fréquentes sur la mise à jour des modules PrestaShop
Comment revenir à l'ancienne version d'un module PrestaShop ?
En restaurant ensemble les fichiers du module et la base, depuis la sauvegarde faite avant la mise à jour. Remettre seulement l'ancien zip ne suffit pas : PrestaShop ne connaît que des scripts de montée, et la base garde la structure et la version de la nouvelle. Sans sauvegarde, faites l'essai sur une copie de la boutique d'abord.
ps_mbo ne fonctionne plus après le passage à PrestaShop 9 : que faire ?
ps_mbo est le module qui affiche le catalogue Addons dans le back-office. Le blocage du back-office au passage de 8.2.1 à 9.0.0 a été corrigé en ps_mbo 5.0.2 : installez une version 5 récente (5.3.3 au 16 octobre 2026). Si le back-office ne s'ouvre plus, désactivez ps_mbo par FTP, en ligne de commande ou en base, puis videz le cache en supprimant le dossier var/cache/prod par FTP.
Que veut dire « Impossible de mettre à jour les paramètres » ?
C'est la traduction de « Unable to update settings ». Dans le code de PrestaShop, ce message vient de la page Permissions (Paramètres avancés > Équipe) et du module de menu principal ps_mainmenu, pas du gestionnaire de modules. Cherchez donc du côté des droits du profil ou de la configuration du menu.
Faut-il mettre à jour un module qui fonctionne ?
Pas à l'aveugle. Oui pour un correctif de sécurité (Friends of Presta publie les avis de sécurité des modules) ou pour une compatibilité exigée par votre prochaine version de PHP ou de PrestaShop. Pour le reste, une mise à jour se planifie : journal des changements, copie de test, hors période de ventes.
Pourquoi le bouton Mettre à jour reste affiché après la mise à jour ?
Parce que la version en base n'a pas suivi celle des fichiers : une erreur pendant un script, ou des fichiers copiés sans que la migration soit jouée. La réponse du back-office peut afficher la nouvelle version quoi qu'il arrive en base. Vérifiez la version dans la table ps_module, videz le cache, puis cliquez une seule fois, sur la copie de test.
Confier vos mises à jour de modules
Nous trions les mises à jour de modules PrestaShop annoncées, les passons sur une copie de test, puis vérifions la version en base sur la boutique. Maintenance PrestaShop à 69 € HT/mois, sans engagement ; réponse en moins d'une heure, 7j/7, de 8 h à 22 h. Si la boutique est en panne, dites-le dans le message, ou appelez le 09 72 03 59 17.
