Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

WhatsApp contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

Boutique PrestaShop en erreur 500 ou page blanche

Une page blanche ou une erreur 500 sur PrestaShop ne dit rien en soi : c’est un symptôme, pas un diagnostic. Il faut lire les vrais messages d’erreur pour savoir si le problème vient d’un module, d’un override, de la base ou du serveur.

Décrire mon problème Discuter sur WhatsApp

Les situations que je traite

  • Écran totalement blanc au chargement du front ou du back-office
  • Erreur 500 apparue juste après une mise à jour de module ou de PrestaShop
  • Erreur 500 uniquement sur certaines pages (fiche produit, panier, commande)
  • Message « The file config/settings.inc.php is missing » après un transfert d’hébergeur
  • Erreur 500 déclenchée après une modification manuelle d’un fichier override
  • Site fonctionnel en local mais en erreur une fois déployé sur le serveur de production

Comment je procède

  1. Activation du mode debug

    Je passe _PS_MODE_DEV_ à true dans config/defines.inc.php pour faire apparaître le message d’erreur réel de PHP ou de Smarty à la place de la page blanche générique.

  2. Lecture des logs

    Je consulte les logs PHP du serveur (souvent dans error_log ou les logs Apache/Nginx) et, sur PrestaShop 1.7/8, le dossier var/logs/ qui contient les erreurs Symfony.

  3. Isolation du fautif

    Je désactive les modules un par un via la table ps_module ou le FTP, et je vérifie le contenu du dossier override/ pour repérer un fichier qui entre en conflit avec le core.

  4. Vérification du serveur

    Je contrôle la version de PHP, les extensions actives, le memory_limit et les droits d’écriture sur var/cache, var/logs et config, des causes fréquentes après un changement d’hébergement.

  5. Correction et vidage du cache

    Une fois la cause identifiée, je corrige le fichier ou reconfigure le serveur, puis je vide var/cache/prod (ou cache/smarty en 1.6) avant de repasser le mode debug sur false.

Les causes les plus fréquentes

Sur PrestaShop, une erreur 500 vient rarement du hasard. Les cas que je rencontre le plus souvent :

  • Un fichier override mal écrit ou dupliqué entre override/ et un module, provoquant une redéclaration de classe.
  • Une incompatibilité de version PHP après une montée de version chez l’hébergeur (un module utilisant une fonction supprimée en PHP 8, par exemple).
  • Des droits d’écriture manquants sur var/cache, var/logs ou config après un transfert de fichiers en FTP.
  • Un fichier .htaccess corrompu ou une règle de réécriture invalide, qui casse le routage avant même que PrestaShop ne s’exécute.
  • Une table manquante ou corrompue en base de données suite à une migration ou un import SQL interrompu.

Sur 1.6, la page blanche cache souvent une erreur Smarty dans le cache de compilation (cache/smarty/compile) qui n’a pas été vidé après une mise à jour de thème.

config/defines.inc.php
define('_PS_MODE_DEV_', true);

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Quelle est l’ampleur du problème ?
Qu’est-ce qui a changé juste avant l’apparition de l’erreur ?

Une mise à jour ou une modification récente oriente presque toujours le diagnostic en premier.

Le mode debug a-t-il été activé pour voir le détail de l’erreur ? (facultatif)

Il s’active dans config/defines.inc.php (_PS_MODE_DEV_) et révèle souvent la cause exacte en une ligne.

Avez-vous accès aux journaux d’erreurs ? (facultatif)
Quel message d’erreur s’affiche exactement ? (facultatif)

Recopiez-le tel quel, même s’il paraît incompréhensible.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Est-ce que je risque de perdre mes commandes ou mes clients ?
Non. L’erreur 500 empêche l’affichage des pages mais la base de données reste intacte : commandes déjà passées, comptes clients et catalogue ne sont pas touchés. C’est la couche d’exécution PHP qui s’arrête, pas le stockage.
Quels accès dois-je vous fournir ?
Un accès FTP ou SSH, un accès à la base de données (phpMyAdmin ou identifiants directs) et, si possible, un accès à l’espace client de l’hébergeur pour vérifier la configuration PHP.
Combien de temps prend le diagnostic ?
Dans la majorité des cas, l’activation du mode debug et la lecture des logs suffisent à identifier la cause dès la première session de travail. C’est le type de blocage qui se règle dans la journée quand l’accès serveur est disponible ; la correction elle-même dépend de ce qui est cassé.
L’erreur peut-elle revenir après correction ?
Si elle vient d’un module tiers instable, oui, à la prochaine mise à jour automatique. Je peux verrouiller les mises à jour de modules sensibles pour éviter que ça se reproduise.
Faut-il repartir d’une sauvegarde complète ?
Rarement. Restaurer une sauvegarde fait perdre les commandes et modifications passées depuis cette date. Je corrige en général directement le fichier ou la configuration en cause.

Pages liées