Dépannage WordPress
Erreur « Headers already sent » dans WordPress : correction sûre
L’avertissement « Cannot modify header information » signifie qu’une sortie a commencé avant l’envoi d’un en-tête HTTP. La première ligne du message indique généralement le fichier et la ligne d’origine ; la ligne « headers already sent by » est le point de départ du diagnostic.
Ce que ce symptôme signifie réellement
Un espace avant <?php, une marque BOM, un avertissement affiché, un echo ou une fermeture PHP suivie de caractères peut suffire.
Le fichier mentionné après « in » est souvent la victime qui tente d’envoyer cookie ou redirection. Modifier cette ligne sans traiter la première sortie ne résout pas la cause.
Avant toute modification : préserver les preuves et le retour arrière
Notez l’heure, l’URL, le message exact, le code HTTP et le dernier changement connu. Vérifiez ensuite qu’une sauvegarde récente couvre bien les fichiers et la base de données, qu’elle est lisible et qu’un retour arrière limité est possible. Une sauvegarde non testée ne suffit pas pour une intervention risquée.
- Ne transmettez jamais de mot de passe, clé privée, jeton, fichier
wp-config.phpou export de base dans un formulaire ou une capture. - Travaillez d’abord sur un staging ou une copie isolée lorsque le diagnostic exige une mise à jour, une modification de code ou une opération de base de données.
- Conservez les journaux et les fichiers suspects avant nettoyage : ils peuvent être nécessaires pour comprendre la cause ou vérifier l’étendue d’un incident.
Diagnostic : avancer du signal le plus fiable au test le moins intrusif
Reproduisez sur staging avec l’affichage public désactivé et la journalisation active. Relevez le message complet, sans publier de chemin privé.
- Repérer le premier fichier et la première ligne après « output started at ».
- Comparer ce fichier à une version saine et vérifier encodage, espaces, sortie et erreurs précédentes.
- Tester l’extension ou le thème propriétaire du fichier par désactivation réversible.
- Contrôler cookies, connexion, redirections et REST après correction.
Correction : appliquer une action ciblée et réversible
Supprimez uniquement la sortie fautive ou corrigez l’erreur PHP qui l’a générée. Ne contournez pas le problème avec une temporisation de sortie globale.
- Enregistrer le fichier en UTF-8 sans BOM.
- Retirer espaces ou HTML avant l’ouverture PHP et éviter la balise de fermeture dans un fichier PHP pur.
- Mettre à jour ou corriger le composant identifié sur staging.
- Conserver les erreurs dans un journal protégé, jamais dans la réponse publique.
Contrôles après correction
Une page qui se recharge ne suffit pas à prouver que le problème est résolu. Contrôlez le parcours concerné, une page non connectée, l’administration, les erreurs console et réseau, les journaux serveur, le cache et les redirections. Vérifiez aussi les écrans mobile et desktop si le symptôme touchait le rendu.
- Connexion, cookies et redirections fonctionnent.
- REST et formulaires renvoient le bon type de réponse.
- Aucun nouvel avertissement dans les journaux.
Quand arrêter et demander une intervention
Si la sortie vient du cœur WordPress, ne modifiez pas le cœur : vérifiez son intégrité et recherchez le composant ou fichier compromis qui l’a altéré.