erreur php wordpress
Lire une erreur PHP dans WordPress : aller vite, sans se tromper
Quand un site WordPress plante, le vrai gain de temps consiste à lire correctement le message d’erreur et à comprendre ce qu’il désigne : un fichier, une ligne, un type d’erreur (fatal, warning, notice), parfois une fonction ou un plugin. Si vous corrigez au hasard (désactiver un plugin, remettre un thème, vider des caches) vous pouvez tomber juste… mais vous risquez surtout d’aggraver la situation ou de masquer temporairement le problème.
Une erreur PHP exploitable contient généralement : (1) le type d’erreur, (2) le message, (3) le chemin du fichier concerné, (4) le numéro de ligne, (5) et parfois une trace (stack trace). À partir de ces éléments, vous pouvez poser un diagnostic fiable : conflit de plugin, fonction dépréciée, fichier manquant, droits insuffisants, mémoire saturée, problème d’autoload, etc.
Activer un affichage propre des erreurs : debug WordPress sans exposer votre site
Le réflexe numéro un est d’activer le debug côté WordPress pour obtenir des logs, sans afficher les erreurs à vos visiteurs. Dans un environnement de production, afficher les erreurs à l’écran est une mauvaise idée (risque de divulgation d’informations sensibles, détérioration de l’expérience, baisse de confiance).
Dans wp-config.php, on utilise classiquement des constantes comme WP_DEBUG, WP_DEBUG_LOG et WP_DEBUG_DISPLAY. L’objectif : enregistrer les erreurs dans un fichier de log (souvent wp-content/debug.log) et garder l’affichage public désactivé. Cette étape seule transforme un crash opaque en incident lisible : vous avez un journal horodaté, souvent avec répétition des erreurs, ce qui aide à isoler la cause (une page précise, une action admin, un hook déclenché, etc.).
Comprendre les types d’erreurs PHP : fatal, parse, warning, notice
Toutes les erreurs n’ont pas le même impact, et les traiter comme équivalentes fait perdre du temps :
Fatal error : le script s’arrête net. Le site peut afficher un écran blanc (WSOD) ou un message de critical error. Souvent lié à une fonction inexistante, une classe introuvable, un manque de mémoire, un fichier manquant, ou une incompatibilité PHP.
Parse error / syntax error : PHP ne peut pas interpréter le fichier (souvent une accolade manquante, un point-virgule oublié, une virgule traînante). Fréquent après un copier-coller de code dans functions.php ou un fichier de plugin.
Warning : le code continue, mais quelque chose cloche (include impossible, argument invalide, division par zéro, etc.). À surveiller : un warning répété peut ralentir un site ou annoncer un futur fatal.
Notice : problème mineur (variable non définie, index absent). Souvent sans conséquence immédiate, mais un site bien maintenu les réduit, car ils signalent une qualité de code perfectible et peuvent casser des sorties HTML ou des JSON dans certains contextes.
Où trouver les erreurs : admin, logs serveur, debug.log, écran critique
Selon la configuration, une erreur PHP peut apparaître :
Dans l’interface WordPress, avec le message de site rencontre une erreur critique, parfois accompagné d’un email automatique WordPress qui mentionne l’extension fautive.
Dans le fichier wp-content/debug.log si le log est activé.
Découvrez nos offres pour la maintenance de sites WordPress
Dans les logs du serveur (Apache/Nginx/PHP-FPM). Ces logs sont souvent plus complets et révèlent aussi des erreurs non gérées par WordPress.
Dans des outils de monitoring (si vous en avez), utiles pour corréler une erreur à un pic de trafic, une mise à jour, ou une tâche cron.
Interpréter le chemin et la ligne : le gps de votre dépannage
Quand le message indique un fichier du type /wp-content/plugins/mon-plugin/..., la probabilité est forte que le plugin soit la cause (ou qu’il soit la victime d’un autre problème, mais c’est un point de départ). Si le chemin pointe vers /wp-content/themes/mon-theme/..., regardez en priorité le thème ou un child theme. Si vous voyez /wp-includes/ ou /wp-admin/, l’erreur provient souvent d’un appel fait par un plugin/thème, mais elle explose dans le cœur WordPress.
Le numéro de ligne sert à localiser précisément l’instruction. C’est très utile pour repérer une fonction dépréciée, un mauvais type passé à une fonction, ou un accès à un index qui n’existe pas. Attention : la ligne mentionnée n’est pas toujours l’origine logique du bug, mais le point où PHP ne peut plus continuer.
Cas n°1 : écran blanc (WSOD) ou There has been a critical error on this website
Dans ce scénario, une fatal error est très probable. La méthode la plus efficace consiste à :
1) Lire le mail d’erreur critique (WordPress en envoie souvent un à l’admin).
2) Consulter le debug.log ou les logs serveur.
3) Désactiver temporairement l’extension indiquée, ou repasser sur un thème par défaut.
Si vous n’avez plus accès à l’admin, passez par FTP/SFTP et renommez le dossier du plugin fautif (ex. mon-plugin en mon-plugin.off) : WordPress le désactive automatiquement. Même technique pour un thème (en forçant WordPress à retomber sur un thème disponible).
Pour une démarche structurée, vous pouvez suivre une checklist de dépannage pas à pas comme Dépanner WordPress : Procédure en 10 étapes, utile pour ne rien oublier (cache, extensions, thème, configuration, etc.).
Cas n°2 : erreurs après mise à jour (core, plugin, thème)
Une grande partie des erreurs PHP surviennent juste après une mise à jour : une extension devient incompatible avec votre version de PHP, un thème attend une fonction d’un plugin, ou un plugin utilise une API WordPress modifiée. Les symptômes typiques : fatal error sur une classe introuvable, warnings inédits, ou admin inaccessible.
Les bons réflexes : identifier ce qui a changé, revenir temporairement en arrière si nécessaire (rollback contrôlé), puis remettre à niveau l’ensemble (core, plugins, thème) dans une combinaison compatible. Si vous gérez régulièrement ce type d’incident, gardez une procédure dédiée : Problème de Mise à Jour Que Faire.
Cas n°3 : Allowed memory size exhausted (mémoire PHP insuffisante)
Cette erreur est fréquente sur des sites qui grossissent : builder, gros plugins (SEO, e-commerce, sauvegarde), imports, ou back-office chargé. Elle indique que PHP a atteint la limite de mémoire autorisée. La correction peut être :
Augmenter la mémoire (si l’hébergement le permet) et aligner les paramètres (PHP memory limit, WordPress memory limit).
Réduire la consommation : désactiver un plugin trop gourmand, remplacer une extension, optimiser les requêtes, limiter les opérations lourdes en admin.
Vérifier l’hébergement : un mutualisé serré peut provoquer des erreurs dès qu’un processus dépasse les quotas.
Pour éviter de traiter le symptôme sans régler la cause, il est utile d’optimiser l’ensemble (cache, autoload, plugins, médias) surtout si vous êtes en mutualisé : Optimiser sur un Hébergement Mutualisé.
Cas n°4 : erreurs 500 et plantages côté serveur
Une erreur 500 (Internal Server Error) n’est pas une erreur PHP au sens strict, mais elle peut être déclenchée par un crash PHP, une configuration serveur, un fichier .htaccess corrompu, des limites atteintes, ou un plugin qui boucle. Souvent, WordPress n’a pas le temps d’afficher un message détaillé : il faut lire les logs serveur.
Les causes courantes : règles réécriture invalides, droits fichiers incorrects, mémoire/timeout, conflit de cache, ou mise à jour interrompue. En cas de doute, une ressource dédiée peut vous guider sur les pistes spécifiques à ce type de panne : Erreur 500 WordPress : assistance, dépannage et ….
Cas n°5 : Error establishing a database connection et erreurs liées à MySQL
Cette erreur peut se manifester sans message PHP explicite, mais elle déclenche souvent une indisponibilité totale. Elle peut venir : d’identifiants DB erronés dans wp-config.php, d’un serveur MySQL en panne, d’une base corrompue, d’un trop grand nombre de connexions, ou d’un hébergement saturé.
Le bon diagnostic consiste à vérifier d’abord la disponibilité du serveur de base de données et les identifiants, puis la santé de la base (tables, réparation, espace disque), et enfin la charge globale du serveur. Pour une procédure détaillée orientée correction, vous pouvez consulter Comment résoudre l’erreur de connexion à la base de ….
Cas n°6 : Parse error: syntax error après modification de code
Découvrez nos offres pour la maintenance de sites WordPress
Le scénario classique : ajout d’un snippet dans functions.php (ou un plugin de snippets), et le site devient inaccessible immédiatement. La correction est généralement simple :
Revenir au fichier modifié via FTP/SFTP, repérer la ligne, corriger la syntaxe (accolades, parenthèses, guillemets, point-virgule).
Éviter l’édition directe en production : privilégier un environnement de staging, ou au minimum un plugin de snippets qui peut désactiver un code fautif sans casser tout le site.
Utiliser un éditeur avec validation syntaxique et auto-formatage pour limiter les erreurs.
Cas n°7 : fonctions dépréciées et incompatibilités de version PHP
Une mise à jour PHP (ex. passage à 8.x) améliore souvent les performances et la sécurité, mais peut casser un plugin ancien. Les messages typiques : Deprecated, Uncaught TypeError, Call to undefined function, ou des erreurs de typage strict. Dans ce cas :
Mettre à jour le plugin/le thème vers une version compatible.
Remplacer l’extension si elle n’est plus maintenue.
Éviter les thèmes maison non testés : si un code custom est nécessaire, documentez-le et testez-le sur staging.
Isoler la cause : méthode de triage fiable (sans y passer la journée)
Quand vous ne savez pas d’où vient l’erreur, appliquez une méthode de triage :
1) Reproduire : quelle URL, quelle action, quel rôle utilisateur, quel navigateur ? Une erreur au hasard est souvent une erreur non reproduite.
2) Lire la première erreur : dans un log, la première occurrence est souvent la cause, les suivantes sont des cascades.
3) Désactiver par lots : si le log pointe vers un plugin, commencez par lui. Sinon, désactivez tous les plugins puis réactivez-les un par un. C’est long, mais c’est déterministe.
4) Revenir sur un thème par défaut : pour éliminer les soucis de thème.
5) Vérifier les caches : cache plugin, cache serveur, CDN. Un fichier obsolète peut maintenir une erreur alors que le code a été corrigé.
6) Vérifier les limites serveur : mémoire, timeout, taille upload, nombre de processus.
Corriger proprement : patch minimal, puis sécurisation
Une correction efficace se fait en deux temps. D’abord, un patch minimal pour remettre le site debout (désactiver l’extension fautive, rollback, correction syntaxique). Ensuite, une sécurisation : mise à jour, remplacement d’extension, tests, ajout de garde-fous (staging, sauvegardes, monitoring).
Si vous intervenez dans du code, évitez les quick fixes qui masquent l’erreur (ex. ajouter des @ devant des fonctions, désactiver les logs, ou ignorer les warnings). Mieux vaut corriger la source : validation d’arguments, vérification d’existence (fonction/classe), compatibilité PHP, et respect des hooks WordPress.
Le rôle de l’hébergement : performance, stabilité et erreurs PHP
Beaucoup d’erreurs répétitives (timeouts, mémoire, erreurs 500) sont aggravées par un serveur sous-dimensionné ou mal réglé. Un hébergement trop limité peut transformer un simple warning en panne récurrente dès qu’un pic de trafic arrive. À l’inverse, une infra adaptée (PHP-FPM configuré, ressources suffisantes, stockage rapide, version PHP maintenue) réduit drastiquement les incidents.
Si vous vous posez la question d’un changement de serveur ou d’une montée en gamme, appuyez-vous sur des critères concrets (ressources, isolation, support, sauvegardes, logs, versions PHP/MySQL, politique de sécurité) : et Hébergement Comment Choisir un Serveur Performant.
Documenter pour corriger plus vite la prochaine fois
Les erreurs PHP ne sont jamais un épisode isolé : elles reviennent sous une autre forme si le site grandit, si l’équipe change, ou si la stack évolue. Documenter votre WordPress (plugins critiques, réglages serveur, snippets, procédures de mise à jour, accès, schémas fonctionnels) réduit fortement le temps de résolution.
Une documentation utile n’est pas un roman : elle doit aider à répondre vite à qu’est-ce qui a été changé ?, où est le code custom ?, quels sont les plugins indispensables ?, comment restaurer ?. Pour structurer cet aspect, vous pouvez vous appuyer sur Comment Documenter son Site pour Mieux le Maintenir.
Quand réparer devient un projet : restauration, nettoyage, remise à plat
Parfois, corriger une erreur PHP révèle une situation plus large : empilement de plugins, thèmes obsolètes, surcharge de code custom, base de données gonflée, droits fichiers incohérents. Dans ce cas, réparer ne se limite pas à corriger une ligne : il faut remettre le site dans un état maintenable (sauvegarde, audit, nettoyage, mise à jour, tests, durcissement sécurité).
Découvrez nos offres pour la maintenance de sites WordPress
Si vous cherchez un cadre de réparation plus global (au-delà du seul message d’erreur), une approche pas à pas peut aider : Comment réparer un site WordPress ?.
Prévenir plutôt que subir : maintenance, tests, sauvegardes, monitoring
La meilleure correction reste celle que vous n’avez pas à faire en urgence. Une maintenance régulière limite fortement les erreurs PHP : mises à jour contrôlées, tests sur staging, sauvegardes vérifiées, surveillance des logs, rotation des versions PHP, et revue périodique des extensions. Pour une PME, l’objectif est simple : éviter l’arrêt de production, protéger le chiffre d’affaires, et maintenir un site performant et sécurisé.
Si votre site supporte des enjeux business (leads, e-commerce, prises de rendez-vous), il est pertinent de cadrer ce qui est vraiment indispensable dans la durée : Maintenance pour PME Ce Qui Est Indispensable.
À quel moment confier la correction à un service de maintenance WordPress ?
Vous pouvez corriger vous-même une partie des erreurs si vous avez accès aux logs, un FTP/SFTP, et un minimum de méthode. En revanche, il est préférable de déléguer si : l’erreur est récurrente, l’admin est inaccessible, vous avez des enjeux de disponibilité, vous manquez de sauvegardes fiables, ou vous soupçonnez un problème serveur (ressources, base de données, configuration).
Un service de maintenance apporte généralement : monitoring, sauvegardes, mises à jour testées, interventions rapides, et surtout une réduction du risque incident critique au mauvais moment. Si vous voulez cadrer une solution récurrente plutôt que de gérer les urgences au cas par cas, vous pouvez découvrir nos offres de maintenance.
Conclusion : une erreur PHP se lit, se prouve, puis se corrige
Pour corriger efficacement, partez des faits : message exact, fichier, ligne, contexte de reproduction, et logs. Remettez le site en ligne avec un patch minimal, puis stabilisez : mises à jour cohérentes, hébergement adapté, documentation, et maintenance continue. Cette discipline transforme les pannes incompréhensibles en incidents maîtrisés, plus rapides à résoudre et beaucoup moins coûteux.
