Non, mais c'est fréquent, et une boutique dans cet état se répare. Le code 500 signale que le serveur a buté sur une erreur en construisant la page ; après une mise à jour, la cause est le plus souvent un module, une surcharge ou la version de PHP. Vos produits, vos clients et vos commandes restent en principe intacts dans la base de données.
Ce qui casse après une mise à jour
- Un module ou le thème incompatible avec la nouvelle version : il appelle une fonction de PrestaShop qui a changé ou disparu. C'est la cause que nous rencontrons le plus.
- Une surcharge (override, un fichier qui remplace une partie du code de PrestaShop) écrite pour l'ancienne version.
- Une version de PHP, le langage du serveur, hors de la plage acceptée : PrestaShop 1.7 s'arrête à PHP 7.4, et une boutique 1.7 passée en PHP 8 tombe souvent en erreur.
- Le cache, ces fichiers préparés à l'avance dans
var/cachepour aller plus vite, resté sur l'ancienne version. - Une mise à jour interrompue (onglet fermé, délai dépassé sur le serveur) : des fichiers neufs, d'autres anciens, et une base de données parfois à moitié convertie.
Ce que vous pouvez vérifier vous-même
Dans l'ordre où nous procédons :
- Dans l'espace client de l'hébergeur, regardez si la version de PHP a changé. Revenir à la précédente, si elle est encore proposée, remet souvent la boutique en ligne.
- Videz le cache : bouton « Vider le cache » en haut à droite de Paramètres avancés > Performances. Sans accès à l'administration, videz par FTP (l'accès aux fichiers du serveur) le contenu de
var/cache/prodetvar/cache/dev, que PrestaShop reconstruit. - Affichez le vrai message d'erreur avec le mode débogage, comme pour une page blanche : sur le même écran, ou par la ligne
_PS_MODE_DEV_deconfig/defines.inc.php. Si le message cite un fichier rangé dansmodules/ouoverride/, vous tenez sans doute le coupable. - Toujours dans Performances, passez « Désactiver toutes les surcharges » sur Oui, rechargez, puis faites de même avec « Désactiver les modules non natifs » (ceux qui ne viennent pas de PrestaShop). Si la boutique revient, vous savez où chercher. Remettez tout sur Non ensuite, mode débogage compris : le second réglage coupe aussi des modules utiles, souvent le paiement.
Revenir en arrière avec la sauvegarde
Si l'erreur reste, revenez à la sauvegarde faite juste avant la mise à jour, en restaurant ensemble ses deux parties : les fichiers (le code de la boutique) et la base de données. Des fichiers anciens sur une base déjà convertie ne fonctionnent pas.
Le module 1-Click Upgrade, qui sert aux mises à jour de PrestaShop, propose un retour à la version précédente s'il a fait sa sauvegarde et si l'administration s'ouvre.
En restaurant la base, vous perdez les commandes et les comptes clients créés depuis la sauvegarde. Avant de restaurer, relevez les commandes dans l'espace de votre banque ou de PayPal et dans les e-mails de notification, et passez si possible la boutique en maintenance (Paramètres de la boutique > Paramètres généraux > Maintenance).
Ce qu'il ne faut pas faire
- Relancer la mise à jour en boucle : chaque tentative repart d'une boutique à moitié mise à jour et complique la restauration.
- Supprimer des fichiers, cache mis à part. Un fichier effacé ne revient qu'avec la sauvegarde, et les journaux d'erreurs du dossier
var/logsdisent ce qui a cassé : gardez-les. - Désinstaller le module suspect : la désinstallation efface souvent ses réglages. Désactivez-le plutôt.
- Restaurer sans noter l'heure de la sauvegarde et celle de la restauration : vous ne saurez plus quelles commandes reprendre.
Quand nous appeler, et quoi envoyer
Appelez-nous si l'administration ne s'ouvre plus, si la mise à jour s'est arrêtée en route, si vous n'avez pas de sauvegarde ou si des commandes sont arrivées depuis celle-ci. Côté délais, 92 % des sujets sont réglés en moins d'une semaine, toutes demandes confondues. Pour gagner du temps, envoyez :
- ce qui a été mis à jour, avec la version avant et après ;
- l'heure de la mise à jour et celle de la première erreur ;
- ce qui s'ouvre encore (boutique, administration) et le message du mode débogage ;
- la date de la dernière sauvegarde.
Ne mettez pas vos mots de passe dans le message : nous les demandons ensuite par un canal chiffré.
Préparer la prochaine mise à jour
Avant chaque mise à jour, nous prenons trois précautions :
- Une copie de test (la préproduction), protégée par mot de passe, où la mise à jour se fait d'abord, commande de test comprise.
- La liste des modules, avec pour chacun la compatibilité annoncée par son éditeur pour la nouvelle version. Un module abandonné se remplace avant.
- Une sauvegarde vérifiée par une restauration : la copie de test se monte à partir d'elle, et si la copie tourne, la sauvegarde est bonne.
Passer de 1.7 à 8, ou de 8 à 9, relève d'une migration de version. Au forfait Socle, nous faisons les mises à jour de sécurité ; le Suivi y ajoute un dépannage prioritaire.