Zie je na een aanpassing of update een lange PHP-waarschuwing bovenaan je WordPress-website? De melding Can not Modify Header Information betekent dat PHP al uitvoer naar de browser heeft gestuurd voordat WordPress nog een HTTP-header wilde aanpassen. Controleer daarom eerst het bestand en regelnummer achter output started at. Daar begint meestal de werkelijke oorzaak.
Die uitvoer kan bestaan uit een spatie, lege regel, foutmelding, onzichtbaar BOM-teken, losse tekst of verkeerd geplaatste PHP-code. Verwijder je de ongewenste uitvoer op de juiste plaats, dan verdwijnt de waarschuwing meestal direct.
De melding heeft niet te maken met de zichtbare header van je website waarin het logo en navigatiemenu staan. Het gaat om technische HTTP-headers die WordPress gebruikt voor onder andere redirects, cookies, downloads en het inloggen van gebruikers.
Wat betekent Can not Modify Header Information?
De volledige waarschuwing ziet er meestal ongeveer zo uit:
Warning: Cannot modify header information - headers already sent by
(output started at /home/website/public_html/wp-config.php:34)
in /home/website/public_html/wp-includes/pluggable.php on line 1435De varianten Can not Modify Header Information en Cannot modify header information verwijzen naar hetzelfde probleem. Vaak staat ook de tekst headers already sent by in de foutmelding.
PHP stuurt eerst technische headers naar de browser. Pas daarna volgt de zichtbare inhoud van de pagina. Zodra al tekst, HTML, witruimte of een foutmelding is uitgevoerd, kunnen bepaalde headers niet meer worden toegevoegd of gewijzigd.
Daardoor kunnen bijvoorbeeld redirects, cookies, wachtwoordherstel, inloggen of het opslaan van instellingen niet goed werken.
Hoe lees je de foutmelding correct?
De foutmelding bevat meestal twee bestandspaden met twee verschillende regelnummers. Het eerste gedeelte is het belangrijkst:
output started at /home/website/public_html/wp-config.php:34Dit betekent dat de uitvoer in wp-config.php rond regel 34 is begonnen. Daar moet je als eerste kijken.
Het tweede gedeelte toont waar WordPress daarna probeerde een HTTP-header te versturen:
wp-includes/pluggable.php on line 1435Dat tweede bestand is meestal niet de oorzaak. Het is alleen de plaats waar WordPress merkt dat de header niet meer kan worden verzonden.
Pas daarom niet direct pluggable.php, wp-login.php of een ander WordPress-kernbestand aan. Controleer eerst het bestand en regelnummer achter output started at.
Ontbreekt output started at in de melding? Bekijk dan het PHP-foutlogboek van je hosting of schakel WordPress-debugging tijdelijk in. Daarin staat vaak meer informatie over de eerste fout.
Zo los je Can not Modify Header Information op
Voer de volgende stappen in deze volgorde uit. Pas steeds één onderdeel aan en test daarna opnieuw. Zo weet je welke wijziging het probleem heeft opgelost.
1. Controleer wat vlak voor de fout is veranderd
Denk terug aan de laatste wijziging voordat de waarschuwing verscheen. Heb je code toegevoegd aan functions.php, wp-config.php bewerkt, een snippet geactiveerd of een plugin of thema bijgewerkt?
Zet eerst alleen die laatste wijziging terug. Wanneer de fout direct daarna verdwijnt, hoef je niet onnodig andere bestanden of plugins aan te passen.
Maak vóór het bewerken van een bestand een kopie van dat specifieke bestand. Bij belangrijke websites is een volledige back-up verstandiger, zodat je zowel de bestanden als de database kunt herstellen.
Meer uitleg over het veilig bewaren en herstellen van een website vind je in: Wat is een website backup en hoe beschermt dit je site?
2. Open het bestand waar de uitvoer begon
Log in bij het hostingpaneel en open Bestandsbeheer. Open daarna de hoofdmap van de website. Deze map heet meestal public_html, httpdocs, www of de naam van het domein.
Volg vervolgens het bestandspad uit de foutmelding. Zie je bijvoorbeeld:
/home/website/public_html/wp-content/themes/hello-elementor-child/functions.php:85Open dan achtereenvolgens public_html, wp-content, themes en hello-elementor-child. Open daarna functions.php en ga naar regel 85.
De tekst output started at in de foutmelding betekent dat de uitvoer op die plaats is begonnen. Je hoeft deze Engelse tekst dus nergens zelf in WordPress in te voeren. Het is alleen een vast onderdeel van de technische foutmelding.
Controleer ook enkele regels boven het genoemde regelnummer. Een losse spatie, foutmelding of ander teken kan eerder zijn uitgevoerd dan de plaats waar WordPress uiteindelijk vastloopt.
3. Verwijder spaties en lege regels rond PHP-code
Controleer eerst het begin van het genoemde PHP-bestand. Voor de openingsregel mag geen tekst, HTML, spatie of lege regel staan.
Het bestand moet direct beginnen met:
<?phpControleer daarna het einde van het bestand. Staat daar een afsluitende PHP-tag, dan kunnen spaties en lege regels die daarna staan als uitvoer worden verzonden.
Bij een bestand dat uitsluitend uit PHP-code bestaat, kun je de afsluitende tag aan het einde meestal weglaten. Het bestand eindigt dan direct na de laatste coderegel.
Verwijder niet alle witruimte uit het bestand. Spaties en lege regels tussen normale coderegels zijn meestal geen probleem. Controleer vooral de ruimte vóór de eerste PHP-tag, na een afsluitende tag en tussen afzonderlijke PHP-blokken.
4. Controleer op een onzichtbaar BOM-teken
Ziet het bestand er correct uit, maar blijft de melding terugkomen? Dan kan er een onzichtbaar teken aan het begin van het bestand staan.
Sommige teksteditors slaan een bestand op als UTF-8 met BOM. BOM is een kleine markering aan het begin van een tekstbestand. PHP kan deze markering als uitvoer behandelen, hoewel je op het scherm geen gewone letter of spatie ziet.
Open het bestand in een code-editor waarmee je de tekencodering kunt aanpassen. Sla het opnieuw op als UTF-8 zonder BOM en upload het bestand daarna terug naar de website.
Gebruik geen tekstverwerkingsprogramma zoals Microsoft Word om PHP-bestanden te bewerken. Zo’n programma kan extra opmaaktekens toevoegen waardoor nieuwe fouten ontstaan.
5. Controleer recent toegevoegde PHP-code
Staat functions.php, een child theme, een snippetbestand of een maatwerkplugin in de foutmelding? Controleer dan eerst de code die je daar als laatste hebt toegevoegd.
Functies zoals echo, print, print_r en var_dump sturen direct informatie naar de browser. Deze functies zijn niet altijd verkeerd, maar kunnen een headers already sent-fout veroorzaken wanneer ze worden uitgevoerd voordat WordPress een redirect, cookie of andere HTTP-header verwerkt.
Controleer ook of er per ongeluk losse tekst of HTML buiten een PHP-blok staat. Eén onbedoeld teken kan al voldoende zijn om de uitvoer te starten.
Een andere fout ontstaat wanneer je deze openingsregel midden in een bestaand PHP-bestand plakt:
<?phpVeel codevoorbeelden beginnen met deze regel. Wanneer functions.php al met PHP-code is geopend, mag je de openingsregel niet opnieuw toevoegen.
Meer uitleg over dit bestand en het veilig toevoegen van PHP-code vind je in: Wat is functions.php? Uitleg over dit WordPress bestand.
6. Los de eerste PHP-fout op
Can not Modify Header Information is soms een gevolg van een andere fout. Een PHP Warning, Notice, Deprecated-melding of Syntax error kan al eerder op de pagina zijn uitgevoerd.
Die eerste foutmelding wordt door PHP als uitvoer behandeld. Wanneer WordPress daarna een HTTP-header probeert te wijzigen, verschijnt ook de melding over reeds verzonden headers.
Bekijk daarom altijd de meldingen die direct vóór de headerfout staan. Los eerst de bovenste en oorspronkelijke PHP-fout op. De waarschuwing over de headers kan daarna vanzelf verdwijnen.
Zie je een Parse error of Syntax error met een bestand en regelnummer? Bekijk dan: Syntax error in WordPress oplossen: zo fix je de fout snel.
7. Controleer de genoemde plugin
Staat wp-content/plugins in het bestandspad? Dan komt de uitvoer waarschijnlijk uit een bestand van een plugin.
Kun je nog inloggen, ga dan naar Plugins > Geïnstalleerde plugins. Deactiveer alleen de plugin waarvan de mapnaam in de foutmelding staat en test daarna opnieuw.
Kun je het WordPress-dashboard niet openen, ga dan via Bestandsbeheer naar:
wp-content/pluginsZoek de betreffende pluginmap en verander de naam tijdelijk. Wijzig bijvoorbeeld:
plugins-old
WordPress kan de plugin daarna niet meer laden. Verdwijnt de foutmelding, dan weet je dat deze plugin of een recente wijziging daarin de oorzaak is.
Controleer vervolgens of er een nieuwe versie beschikbaar is. Ontstond de fout direct na een update, herstel dan de laatste werkende versie en onderzoek welke wijziging het probleem veroorzaakt.
Meer uitleg over het veilig bijwerken en herstellen van plugins vind je in: WordPress plugins updaten, alles wat je moet weten voor een goede update.
8. Controleer het actieve thema
Staat wp-content/themes in de foutmelding? Dan bevindt de oorzaak zich waarschijnlijk in het actieve thema of child theme.
Controleer eerst functions.php en andere themabestanden die onlangs zijn aangepast. Verwijder de laatste wijziging of zet een eerdere werkende kopie terug.
Kun je nog inloggen, activeer dan tijdelijk een standaard WordPress-thema. Verdwijnt de waarschuwing, dan moet het oorspronkelijke thema verder worden onderzocht.
Kun je niet inloggen, open dan via Bestandsbeheer:
wp-content/themesVerander tijdelijk de naam van de map van het actieve thema. Dit werkt alleen goed wanneer er ook een ander bruikbaar thema op de website is geïnstalleerd.
Plaats eigen wijzigingen niet rechtstreeks in het hoofdthema wanneer ze na een thema-update behouden moeten blijven. Meer uitleg hierover vind je in: Wat is een WordPress child theme?
9. Schakel WordPress-debugging tijdelijk in
Geeft de zichtbare melding onvoldoende informatie? Laat WordPress de fouten dan tijdelijk opslaan in debug.log.
Open wp-config.php in de hoofdmap van de website. Controleer eerst of WP_DEBUG, WP_DEBUG_LOG en WP_DEBUG_DISPLAY al in het bestand staan. Pas bestaande regels aan en voeg dezelfde instellingen niet opnieuw toe.
Gebruik tijdelijk:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Plaats deze regels vóór:
/* That's all, stop editing! Happy publishing. */Sla het bestand op en open opnieuw de pagina waarop de fout verschijnt. WordPress slaat de meldingen normaal op in wp-content/debug.log. WP_DEBUG_LOG werkt alleen wanneer WP_DEBUG is ingeschakeld. Met WP_DEBUG_DISPLAY op false worden de foutmeldingen niet op de openbare pagina weergegeven.
Open debug.log en bekijk de nieuwste regels. Zoek niet alleen naar Cannot modify header information, maar vooral naar de eerste fout die daar direct boven staat.
Wordt debug.log niet aangemaakt? Bekijk dan het PHP-foutlogboek in het hostingpaneel. Dit onderdeel kan Foutlogboek, PHP-fouten of Logboeken heten.
Een uitgebreidere uitleg over het instellen en lezen van het logbestand vind je in: Handleiding WordPress debugging inschakelen stap voor stap.
Zet debugging na het onderzoek weer uit:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );Verwijder debug.log wanneer je het bestand niet meer nodig hebt.
10. Wis de cache en test de website
Wis na het herstellen de cache van je cachingplugin, hosting en eventueel het CDN. Open de website daarna in een privévenster.
Controleer niet alleen of de melding verdwenen is. Test ook de functie waarbij de fout ontstond.
Probeer bijvoorbeeld opnieuw in te loggen, een instelling op te slaan, een formulier te verzenden of een wachtwoordherstellink aan te vragen. Controleer daarnaast of redirects en cookies weer normaal werken.
Welke oplossingen kun je beter vermijden?
Sommige aanpassingen kunnen de melding tijdelijk verbergen zonder dat de werkelijke oorzaak wordt opgelost.
Pas WordPress-kernbestanden niet aan
In de foutmelding staat vaak pluggable.php, wp-login.php of een ander bestand uit wp-includes. Dit is meestal de plaats waar WordPress ontdekt dat de HTTP-header niet meer kan worden verzonden.
De werkelijke uitvoer is eerder in een ander bestand begonnen. Dat bestand staat in het eerste gedeelte van de foutmelding.
Aanpassingen aan WordPress-kernbestanden worden bovendien bij een update overschreven en kunnen nieuwe problemen veroorzaken.
Verplaats get_header() niet zonder duidelijke reden
De woorden header information zorgen soms voor verwarring. De fout gaat niet automatisch over header.php, get_header() of het zichtbare bovenste gedeelte van de website.
Verplaats get_header() daarom niet zomaar naar een andere regel. Controleer eerst welk bestand volgens de foutmelding de uitvoer heeft gestart.
Staat header.php daadwerkelijk als eerste bestand genoemd? Controleer dan dat bestand op losse tekst, witruimte of foutieve PHP-code. Staat een ander bestand genoemd, dan moet je dat bestand onderzoeken.
Verberg de fout niet met uitvoerbuffering
Uitvoerbuffering houdt de inhoud tijdelijk vast voordat deze naar de browser wordt verzonden. Daardoor kan de waarschuwing in sommige situaties verdwijnen.
De oorspronkelijke spatie, foutmelding of foutieve code blijft dan echter aanwezig. De oorzaak is alleen minder zichtbaar geworden.
Gebruik uitvoerbuffering daarom niet als eerste oplossing. Zoek eerst waar de ongewenste uitvoer begint en herstel het betreffende bestand. Alleen bij bewust ontwikkelde maatwerkcode kan uitvoerbuffering een passende technische keuze zijn.
Wanneer neem je contact op met je hostingprovider?
Neem contact op met de hostingprovider wanneer je het genoemde bestand niet kunt openen, wijzigingen niet kunt opslaan of de foutmelding geen bruikbaar bestandspad toont.
Stuur de volledige foutmelding mee. Vermeld ook de pagina waarop de fout verschijnt, het tijdstip en de laatste wijziging die je hebt uitgevoerd.
De hostingprovider kan het PHP-foutlogboek, de tekencodering, bestandsrechten en serverinstellingen controleren. Verander tijdens dit onderzoek niet meerdere onderdelen tegelijk. Daardoor wordt het moeilijker om de oorspronkelijke oorzaak te vinden.
Conclusie
De melding Can not Modify Header Information betekent dat PHP al uitvoer naar de browser heeft gestuurd voordat WordPress een HTTP-header wilde toevoegen of wijzigen.
Begin bij het eerste bestand en regelnummer in de melding. Controleer daar op spaties, lege regels, een BOM-teken, losse tekst, een eerdere PHP-fout of verkeerd geplaatste code.
Staat een plugin of thema in het bestandspad, test dan alleen dat onderdeel. Geeft de zichtbare melding onvoldoende informatie, schakel WordPress-debugging tijdelijk in en zoek in debug.log naar de eerste fout.
Pas geen WordPress-kernbestanden aan en verberg de oorzaak niet met uitvoerbuffering. Zodra je de eerste ongewenste uitvoer verwijdert, kunnen de HTTP-headers meestal weer normaal worden verwerkt.
Veelgestelde vragen
1. Wat betekent Can not Modify Header Information?
PHP heeft al uitvoer verzonden, waardoor WordPress bepaalde HTTP-headers niet meer kan toevoegen of wijzigen.
2. Welk bestand moet ik als eerste controleren?
Controleer het eerste bestand en regelnummer in de melding. Daar is de uitvoer meestal begonnen.
3. Heeft deze fout te maken met de zichtbare websiteheader?
Nee. De melding gaat over technische HTTP-headers en niet automatisch over het logo of navigatiemenu.
4. Kan een lege regel deze fout veroorzaken?
Ja. Een spatie, lege regel of onzichtbaar BOM-teken kan als uitvoer worden verzonden.
5. Kan een plugin de fout veroorzaken?
Ja. Staat een pluginmap in het bestandspad, deactiveer dan eerst alleen die specifieke plugin.
6. Moet WordPress-debugging ingeschakeld blijven?
Nee. Gebruik debugging alleen tijdens het onderzoek en zet de drie debug-instellingen daarna weer op false.