Dépannage WordPress
Erreur « Headers already sent » dans WordPress : correction sûre
Identifier la sortie PHP qui provoque Headers already sent dans WordPress, puis la corriger sans masquer l’avertissement.
Lire le conseilL’avertissement « Cannot modify header information — headers already sent » indique que PHP tente d’envoyer un en-tête HTTP alors qu’une sortie a déjà commencé. Il peut apparaître pendant une connexion, une redirection ou l’envoi d’une réponse. La page peut encore s’afficher, mais cela ne prouve pas que l’action attendue fonctionne correctement.
Le bon point de départ est le message complet, conservé dans un journal privé. Il permet souvent de distinguer le fichier qui produit la première sortie de celui qui essaie ensuite d’envoyer un en-tête. Corriger seulement le dernier fichier cité peut laisser la cause intacte.
Lire les deux positions indiquées dans le message
Repérez la mention output started at, suivie d’un fichier et d’un numéro de ligne : elle désigne le début de la sortie signalée. Le fichier indiqué ensuite, avec la ligne de l’avertissement, correspond à la tentative d’envoi devenue trop tardive. Ce ne sont pas nécessairement deux erreurs différentes.
Le responsable technique doit examiner le premier emplacement et les messages qui le précèdent dans le journal. Si le début de sortie vient d’un avertissement PHP déjà affiché, cet avertissement peut être la vraie piste à traiter. Un fichier du cœur WordPress cité en dernier ne suffit pas à conclure que le cœur est défectueux.
Pour demander de l’aide, indiquez l’action, l’heure approximative et le composant concerné. Masquez les chemins privés et les informations sensibles dans une capture destinée à être partagée. Un export de configuration ou de base de données n’est pas nécessaire pour présenter ce symptôme.
Chercher ce qui sort avant les en-têtes
- Des caractères hors des balises PHP : espaces, lignes vides ou HTML dans un fichier chargé avant l’envoi des en-têtes.
- Une sortie de débogage : texte affiché par un
echo, un affichage de variable ou un outil ajouté pendant un essai. - Un autre avertissement visible : une erreur produite plus tôt par un thème, une extension ou du code personnalisé.
Comparez le fichier en cause avec une version saine de la même version du composant, ou avec son état avant la dernière modification connue. Vérifiez aussi son encodage et la présence éventuelle d’une marque invisible en début de fichier. Un éditeur adapté permet de rechercher ce point sans convertir tous les fichiers du site.
Dans un fichier contenant uniquement du PHP, la documentation PHP recommande d’omettre la balise de fermeture finale pour éviter des caractères indésirables après celle-ci. Cette règle ne signifie pas qu’il faut retirer les balises d’un modèle qui mélange volontairement PHP et HTML.
Corriger au bon endroit avec un retour arrière
Travaillez sur un environnement de test avec une sauvegarde restaurable et la version précédente du fichier. La correction dépend de la sortie trouvée : retirer les caractères accidentels, enlever un affichage de débogage ou réparer l’erreur initiale. Gardez la modification limitée au composant identifié.
Si l’erreur suit une modification de code, le guide des erreurs de syntaxe PHP dans WordPress aide à préparer une correction réversible. Si elle concerne un composant tiers, recherchez un correctif compatible ou faites examiner sa source. Modifier le cœur WordPress directement laisserait un changement fragile et pourrait masquer l’origine du problème.
Conservez les erreurs utiles dans une journalisation protégée, avec leur affichage public désactivé. Le responsable doit vérifier l’emplacement et l’accès au journal : un fichier de diagnostic accessible aux visiteurs peut exposer des informations privées. Désactiver l’affichage évite cette exposition, mais ne remplace pas la correction de la cause.
La mise en tampon de sortie peut modifier le moment où les données sont envoyées. Elle doit être étudiée dans le fonctionnement du code, plutôt qu’ajoutée globalement pour faire disparaître un avertissement encore inexpliqué. Une purge de cache ou une hausse de mémoire n’identifie pas non plus la première sortie.
Vérifier le parcours qui échouait
Reprenez l’action initiale sur l’environnement adapté. Pour une connexion, contrôlez le résultat de la connexion puis de la déconnexion. Pour une redirection, vérifiez sa destination et la réponse reçue. Pour un formulaire ou une API, contrôlez le résultat enregistré et le type de réponse attendu, pas seulement l’absence de texte d’erreur à l’écran.
Testez aussi une page publique et les parcours voisins concernés par le même composant. Relisez les nouveaux journaux pour confirmer que l’avertissement ne revient pas. Si un formulaire peut créer une commande, un paiement ou une publication, préparez les essais sans déclencher ces effets réels sur le site public.
Un diagnostic WordPress peut partir de ces éléments : action reproductible, première sortie identifiée, dernier changement et résultat des essais. Vous n’avez pas besoin de transmettre votre mot de passe dans le message initial.