Reconnaître une sortie PHP envoyée trop tôt
WordPress affiche « Cannot modify header information – headers already sent » après une modification de fichier, un ajout de code ou une mise à jour. Une redirection peut rester bloquée ou la connexion ne pas aboutir. Ce message signifie que PHP essaie d’envoyer un en-tête après avoir commencé à transmettre du contenu. Il ne prouve pas que le fichier nommé à la fin de l’avertissement est défectueux.
Le résultat recherché est de supprimer la sortie accidentelle ou de replacer l’action au bon moment, puis de vérifier le parcours concerné. Le problème peut venir d’un espace invisible, d’une marque d’encodage, d’un texte de débogage ou d’une redirection exécutée après le rendu. Ces cas demandent des corrections différentes.
Les manipulations de fichiers concernent une installation auto-hébergée avec accès autorisé. Sur WordPress.com ou un service qui déploie la configuration automatiquement, passez par le propriétaire du composant et les outils permis. En multisite, un fichier partagé peut affecter plusieurs sites. Commencez par le message exact et une seule action représentative.
Préserver le fichier modifié et les actions déjà réalisées
Conservez le fichier actuel avant toute correction, même s’il semble responsable. Gardez aussi une version antérieure connue si elle existe. Stockez ces copies dans un emplacement privé hors du dossier publié ; un fichier de configuration laissé sous un nom de secours accessible peut exposer des secrets. Une copie du fichier et une sauvegarde complète répondent à des besoins différents.
Notez la modification récente, son heure et l’action qui déclenche l’avertissement. Si celui-ci apparaît après l’enregistrement d’un article, vérifiez si le texte a déjà été enregistré avant de cliquer de nouveau. Une redirection qui échoue n’annule pas forcément l’opération réalisée juste avant. Le même principe vaut pour une commande ou un envoi.
Préparez un accès SFTP ou un gestionnaire de fichiers qui fonctionne indépendamment de WordPress. Conservez une session autorisée encore utilisable. Une copie isolée du site permet les comparaisons de composants ; ses paiements, courriels et automatismes externes doivent être neutralisés avant les essais. Ne testez pas plusieurs corrections simultanément au risque de perdre leur attribution.
Lire les deux emplacements dans le message
Relevez le chemin qui suit « output started at » et son numéro de ligne. Il désigne l’endroit où la sortie a commencé. Le chemin qui suit ensuite « in », avec une autre ligne, indique où l’envoi d’en-tête a été tenté trop tard. Cette distinction évite de modifier une fonction du cœur qui ne fait que subir le problème.
Dans un exemple fictif, une sortie signalée à la première ligne de wp-config.php conduit à vérifier son début et son encodage. Une sortie plus loin dans un fichier personnel peut correspondre à du HTML, un echo ou un avertissement affiché. Un fichier du thème qui produit normalement la page peut aussi révéler que la redirection arrive simplement après lui.
Consultez le journal privé à l’heure de la même requête et lisez les messages précédents. Un premier avertissement rendu à l’écran peut précéder l’erreur d’en-tête. Ne concluez pas à une marque d’encodage sur le seul numéro un. Conservez les chemins en privé et ne partagez que l’extrait utile nettoyé, sans cookies ni configuration complète.
Identifier le propriétaire du fichier avant d’agir
Associez le chemin à un composant précis. wp-config.php contient la configuration du site. Un fichier sous wp-content/themes appartient à un thème ; un chemin sous wp-content/plugins désigne généralement une extension. Vérifiez le répertoire réellement utilisé, surtout si plusieurs installations ou copies possèdent des noms voisins.
Un fichier du cœur peut être le premier à produire une sortie normale parce qu’un code personnel tente ensuite une redirection trop tardive. Il ne faut alors pas supprimer sa sortie ou modifier le cœur. Recherchez l’appel tardif et son propriétaire. Inversement, un fichier personnel récemment enregistré et signalé avant toute page mérite un contrôle de ses premiers caractères.
Choisissez la branche adaptée. Une modification manuelle identifiée se corrige dans son original ou sa copie préparée. Une régression de produit se compare sur copie et se traite par un correctif officiel. Un code personnel qui agit après le rendu doit changer de moment d’exécution. Si vous ne connaissez pas le fichier, relevez son chemin et les messages voisins avant d’appliquer une recette destinée à un autre cas.
Corriger l’encodage ou les espaces d’un fichier personnel
- Avec votre accès aux fichiers, téléchargez le fichier personnel identifié et ouvrez-le dans un éditeur de texte brut. Pour un fichier entièrement PHP comme une configuration, le début doit être l’ouverture
<?php, sans texte ni espace envoyé avant elle. Examinez aussi l’encodage : une marque UTF-8 BOM peut produire une sortie invisible. Enregistrez en UTF-8 sans BOM lorsque l’éditeur propose ce choix. - Si un fichier entièrement PHP se termine par une fermeture
?>, les caractères qui la suivent peuvent sortir du mode PHP. La convention WordPress préfère omettre cette fermeture finale. Retirez seulement la fermeture finale superflue et son espace extérieur dans ce type de fichier. N’appliquez pas cette règle aveuglément à un modèle qui contient volontairement du HTML entre des blocs PHP. - Comparez le fichier corrigé à la copie privée : les identifiants, clés, chemins et autres instructions doivent être conservés. Remplacez ensuite le seul fichier concerné sur la copie du site et contrôlez l’action. Si une erreur de syntaxe ou un autre comportement apparaît, remettez le fichier préservé. Ne reconstruisez pas
wp-config.phpà partir de quelques lignes d’un tutoriel.
Retirer une sortie de diagnostic qui précède les en-têtes
Un echo, un print_r ou un var_dump ajouté pour examiner une valeur peut envoyer du contenu avant une connexion ou une redirection. Recherchez seulement les ajouts liés à votre dernière intervention dans le fichier identifié. Préservez leur contexte et retirez la sortie de diagnostic temporaire lorsque son rôle est confirmé. Ne supprimez pas toutes les instructions d’affichage d’un thème.
Un avertissement PHP affiché avant le message d’en-tête doit aussi être traité à son origine. Par exemple, une propriété manquante peut déclencher un avertissement dans une extension. Masquer cet avertissement dans la réponse peut changer le symptôme sans corriger le composant. Gardez le message dans le journal privé et recherchez son correctif ou sa configuration valide.
Pour le diagnostic WordPress, privilégiez les journaux existants. Si une journalisation temporaire doit être préparée sur copie, faites conserver les réglages initiaux et utilisez un fichier privé prévu à cet effet, sans affichage des erreurs aux visiteurs. Après l’observation, revenez aux réglages d’exploitation. La disparition d’un texte à l’écran ne suffit pas : la connexion, l’enregistrement et les en-têtes attendus doivent fonctionner.
Contrôler la syntaxe du fichier sans confondre les validations
Un éditeur qui sait vérifier PHP peut repérer une parenthèse ou une apostrophe manquante après votre correction. Si vous disposez déjà d’un terminal et du bon exécutable PHP, son option -l contrôle la syntaxe sans exécuter le fichier comme un script. Sur SSH, lancez la commande avec votre compte habituel, sans élévation de privilèges. Adaptez le chemin à votre copie privée et utilisez une version compatible avec celle du site.
Une réponse indiquant qu’aucune erreur de syntaxe n’est détectée ne prouve pas que les en-têtes seront envoyés correctement. Un espace extérieur au code peut rester une sortie valide du point de vue du parseur. Le contrôle du parcours web reste indispensable. La commande ne remplace donc ni la comparaison du fichier ni la lecture du message initial.
Si une erreur de syntaxe est signalée, corrigez la modification sur la copie ou rétablissez le fichier préservé avant transfert. Ne chargez pas volontairement en production un fichier que vous savez invalide pour voir ce qui se passe. Cette étape ne demande pas de lancer le fichier directement avec PHP sans l’option de contrôle.
php -l '/chemin/prive/copie/wp-config.php'Traiter une régression d’extension ou de thème
Lorsque l’erreur commence après une mise à jour sans modification manuelle connue, conservez les versions avant et après et recherchez les annonces officielles du composant. Un signalement de forum aide à reconnaître une famille de symptômes ; il ne prouve pas que votre installation possède exactement le même défaut. Comparez les fichiers et messages dans le contexte observé.
Sur une copie isolée, ouvrez Extensions, puis Extensions installées si l’administration fonctionne. Relevez l’état de la seule extension suspecte, désactivez-la normalement et reproduisez une action sans effet externe. Réactivez-la après le relevé avant d’examiner une autre piste. Si l’action n’existe plus sans elle, la comparaison ne permet pas de conclure sur cette action.
Un correctif officiel compatible peut ensuite être essayé sur la copie. Ne remplacez pas toute une extension par un fichier provenant d’une autre version, et ne supprimez pas un fichier du cœur nommé dans la trace. Le retour de version exige de vérifier aussi les évolutions de données. Si le tableau de bord est inaccessible, utilisez l’accès aux fichiers préparé avec le mainteneur pour une intervention ciblée et réversible.
Replacer une redirection personnelle avant le rendu
Cette branche convient à un code personnel identifié qui redirige après avoir chargé l’en-tête, affiché du HTML ou produit un bloc de page. Le propriétaire de ce code doit conserver l’original et retirer l’ancien appel tardif. Ajouter une nouvelle redirection tout en gardant la précédente peut créer une chaîne ou masquer le diagnostic.
Dans WordPress, template_redirect permet de décider d’une redirection avant le choix du modèle avec connaissance du contenu demandé. Le code doit être enregistré dans un composant chargé à temps, par exemple le fichier de fonctions d’un thème enfant déjà utilisé ou une extension de fonctionnalités existante. Un bloc HTML dans l’éditeur de page ne constitue pas cet emplacement.
Validez la condition et la destination avec le responsable du site avant de modifier le code. Ce déplacement concerne la navigation publique ; il n’est pas une solution universelle pour les cookies, les exports ou une opération d’administration. Testez sur copie le chemin concerné et un chemin sans rapport. Pour annuler, retirez la seule correction et restaurez la personnalisation d’origine dans son état documenté.
Adapter un exemple de redirection à une seule page
L’exemple ci-dessous sert uniquement à remplacer une redirection personnelle équivalente exécutée trop tard. Il suppose deux pages fictives : ancienne-page et nouvelle-page. Remplacez le slug passé à is_page et le chemin passé à home_url par ceux vérifiés sur votre copie. La condition doit viser uniquement la page abandonnée ; elle ne doit pas aussi correspondre à la destination. Avec des pages hiérarchiques dont les slugs peuvent se répéter, faites cibler l’identifiant exact de la page par le mainteneur.
Dans le composant de personnalisation déjà retenu, insérez ce code à l’intérieur du PHP existant, sans ajouter une nouvelle ouverture PHP au milieu du fichier. Conservez une copie privée avant l’édition. Le statut 302 convient à la vérification temporaire ; une décision de redirection permanente se traite ensuite selon le projet, sans supposer que tous les caches l’oublieront immédiatement.
wp_safe_redirect contrôle la destination locale et n’arrête pas automatiquement le traitement. L’exemple termine donc l’exécution après une redirection acceptée. Vérifiez que l’ancienne page mène à la nouvelle sans boucle et qu’une autre page s’affiche normalement. Cette correction ne supprimera pas une sortie déjà envoyée avant le hook : si le même avertissement persiste, reprenez sa première origine.
add_action( 'template_redirect', function () {
if ( is_page( 'ancienne-page' ) ) {
if ( wp_safe_redirect( home_url( '/nouvelle-page/' ), 302 ) ) {
exit;
}
}
} );Comparer les composants avec Troubleshooting si l’accès existe
Troubleshooting peut aider à comparer des composants dans une session de diagnostic lorsque l’administration est encore utilisable. Sur une copie de préférence, un administrateur ouvre Extensions, Ajouter, recherche Troubleshooting de Marius L. J. et vérifie le produit. La version documentaire 1.0.2 annonce WordPress 5.8 et PHP 7.1 au minimum, avec un test déclaré jusqu’à WordPress 7.1.4. Une branche PHP ancienne n’est pas une recommandation d’exploitation.
Après installation et activation si l’outil est nécessaire, ouvrez Outils, Santé du site, puis l’onglet Troubleshooting et le bouton Enable Troubleshooting Mode. L’outil revient au Tableau de bord, où son widget et la barre d’administration permettent de réactiver les composants utiles un par un pour comparer le même parcours. Les libellés du plugin peuvent rester en anglais. Le mode ne constitue pas une copie indépendante de la base : n’y déclenchez pas d’envoi, de commande ou d’import réel.
Pour terminer, utilisez Disable Troubleshooting Mode dans le widget ou dans le menu de la barre d’administration, puis contrôlez le retour à l’état normal. Les extensions indispensables, dites Must Use, restent chargées ; certains caches peuvent aussi perturber la comparaison. L’outil ne répare ni un BOM ni une sortie dans la configuration chargée trop tôt. Si l’administration ne démarre pas, l’installer ne fournit pas un chemin de secours. Un onglet absent ou une activation refusée doit être vérifié avec l’administrateur, sans élargir les permissions des fichiers pour forcer le mode.
Éviter de masquer le défaut par un tampon global
Un tampon de sortie peut retarder l’envoi du contenu et rendre le problème moins visible. Cela ne transforme pas une redirection tardive en organisation correcte du code. Ajouter un appel global à ob_start dans la configuration pour faire disparaître l’avertissement risque aussi de modifier le traitement d’autres réponses. Ne le présentez pas comme la réparation par défaut d’un fichier mal encodé.
De même, désactiver tout affichage d’erreurs est une règle d’exploitation distincte de la correction de leur cause. Le fait qu’un visiteur ne voie plus le message ne garantit pas que la session ou la redirection fonctionne. Conservez la trace privée correspondante pour vérifier ce qui s’exécute après la modification.
Si un composant utilise volontairement un tampon, sa gestion appartient à son mainteneur. N’ajoutez pas au hasard un vidage ou une fermeture de tampon dans un autre fichier. Revenez à la sortie et au moment d’exécution identifiés. Le critère reste une réponse correcte obtenue avec une cause comprise, pas seulement une page qui semble silencieuse.
Vérifier le parcours qui échouait et les autres réponses
Reproduisez d’abord le cas conservé dans l’environnement de test. Pour une connexion, vérifiez que votre profil s’ouvre puis qu’une seconde page garde la session. Pour un enregistrement, rouvrez le contenu afin de confirmer sa sauvegarde. Pour une redirection, ouvrez les outils de développement de Chrome, onglet Réseau ou Network, avant de charger l’ancienne page. Activez Preserve log pour conserver la navigation. Sélectionnez la requête du document et examinez Headers : le statut et l’en-tête Location doivent correspondre à la destination prévue, suivie d’un chargement sans boucle. Gardez les cookies et en-têtes de session privés.
Consultez le journal à l’heure du nouvel essai : l’ancien avertissement ne doit pas simplement avoir été remplacé par une autre erreur. Comparez aussi une page publique sans rapport et l’administration habituelle. Si un cache identifié conserve une ancienne réponse, purgez seulement le périmètre concerné après correction de la source, puis recommencez le contrôle.
Une action sensible ne doit pas être rejouée pour obtenir une capture plus propre. Vérifiez son état déjà enregistré avec la personne compétente. Si l’essai dégrade d’autres pages, restaurez le fichier ou le réglage préservé par l’accès indépendant, et notez le résultat. Le passage en production reprend uniquement la correction validée, sans laisser les fichiers de diagnostic ni leurs copies de secours exposés.
Documenter la cause et prévenir le prochain incident
Gardez le message initial, le fichier de première sortie, la modification retenue et le contrôle qui a confirmé son effet. Notez si la cause était un encodage, un espace extérieur au PHP, une sortie temporaire ou un appel exécuté après le rendu. Cette précision évite de traiter le prochain avertissement comme un problème général de cookies ou de serveur.
Pour les personnalisations, documentez le composant propriétaire et le moment d’exécution prévu. Travaillez dans une copie et avec un éditeur de texte qui conserve l’encodage attendu. Les fichiers du cœur et du thème parent ne doivent pas devenir le lieu permanent de corrections locales qui disparaîtront lors d’une mise à jour.
Si le problème persiste, transmettez au mainteneur le parcours précis, les versions et un extrait nettoyé des messages de la même requête. Distinguez clairement ce que vous avez vérifié de ce qui reste une hypothèse. Une preuve d’accès, un mot de passe ou l’intégralité de wp-config.php ne sont pas nécessaires pour expliquer l’ordre des sorties. Préservez le dernier état fonctionnel et le chemin de restauration avant toute nouvelle intervention.
