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

Écrire un message 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 Écrire un message

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.

Page blanche PrestaShop : l’endroit où elle apparaît dit d’où elle vient

Avant même de lire les journaux, notez où la page blanche ou l’erreur 500 se produit. Cela réduit le champ de recherche de moitié.

  • Front et back-office blancs en même temps : la panne survient avant que PrestaShop ne distingue les deux. Regardez la configuration : version de PHP changée par l’hébergeur, app/config/parameters.php (1.7, 8, 9) ou config/settings.inc.php (1.6) incomplet, .htaccess invalide, droits d’écriture manquants.
  • Seulement le back-office : souvent un cache resté d’une version précédente dans var/cache/, ou un module qui s’accroche à un hook de l’administration.
  • Seulement le front, ou une seule page : un module greffé sur un hook d’affichage, un fichier du thème, ou une donnée propre à cette page.
  • Uniquement au passage de commande : le module de paiement ou de transport, qui n’est appelé qu’à cette étape.

Si la page reste blanche alors que _PS_MODE_DEV_ est actif, l’erreur se produit avant que PrestaShop ne soit chargé : c’est le journal d’erreurs PHP du serveur qu’il faut lire, pas var/logs.

Les messages d’erreur les plus fréquents, et ce qu’ils désignent

  • Cannot declare class … ou Cannot redeclare class … : un override en double, ou resté en place après la désinstallation d’un module. Supprimer l’index des classes — var/cache/prod/class_index.php en 1.7 et au-delà, cache/class_index.php en 1.6 — oblige PrestaShop à le reconstruire.
  • Allowed memory size of … bytes exhausted : la limite mémoire de PHP est atteinte, typiquement pendant un import, une régénération de miniatures ou une indexation.
  • Call to undefined function each() ou create_function() : un module écrit pour une ancienne version de PHP. Ces fonctions ont disparu en PHP 8 ; voir passer PrestaShop à PHP 8.
  • SQLSTATE[42S02]: Base table or view not found : une table manque, après une migration, un import SQL interrompu ou un module mal désinstallé.
  • Link to database cannot be established : identifiants de base erronés dans le fichier de configuration, ou serveur MySQL indisponible. Voir erreur de connexion à la base de données.
  • Permission denied sur var/cache ou var/logs : droits d’écriture perdus, fréquent après un transfert FTP ou un changement d’hébergeur.

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);

Pages liées

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.
Pourquoi ma boutique PrestaShop affiche-t-elle une page blanche sans aucun message ?
Parce que PrestaShop masque les erreurs en production : tant que _PS_MODE_DEV_ vaut false, le détail n’est pas affiché. Passez-le à true le temps d’un essai. Si la page reste blanche malgré cela, l’erreur se produit avant le chargement de PrestaShop — version de PHP, .htaccess, fichier de configuration — et c’est le journal d’erreurs du serveur qui la contient.

Pages liées