Fouten en waarschuwingen in WordPress onderdrukken bij noodgevallen

Soms verschijnen PHP-fouten of -waarschuwingen op je live WordPress-site en verstoren ze het ontwerp of verwarren ze bezoekers. Je kunt die berichten tijdelijk van het scherm verbergen zodat de openbare site er weer normaal uitziet. Dat is alleen een noodstap. Het herstelt de bug niet en betekent niet dat het probleem verdwenen is.

Belangrijk: waarschuwingen of fouten op het scherm verbergen is alleen tijdelijk. Weergave onderdrukken lost de onderliggende oorzaak niet op. Gebruik het alleen als kortetermijnoplossing op een productiesite; inspecteer daarna veilig de logbestanden, identificeer de plugin, het thema of de PHP-code die verantwoordelijk is, werk vanaf een back-up of een stagingkopie, herstel of werk die code bij en controleer de site. Behandel verborgen fouten niet alsof je ze veilig kunt negeren. WP_DEBUG uitschakelen schrijft fouten ook niet naar een logbestand.

Tijdelijke stap: foutberichten voor bezoekers verbergen

WordPress bevat in wp-config.php al een regel met WP_DEBUG. Bewerk die bestaande regel. Plak geen tweede define( 'WP_DEBUG', ... ) — dezelfde constante twee keer definiëren kan een PHP-melding veroorzaken. Plaats deze instellingen vóór de opmerking /* That's all, stop editing! */, niet erna.

1. Zoek `wp-config.php`

Maak verbinding met een FTP-programma of de bestandsbeheerder van je hosting en open wp-config.php in de hoofdmap van je WordPress-installatie.

2. Bewerk de bestaande `WP_DEBUG`-regel

Zoek de regel die er al uitziet als define( 'WP_DEBUG', true ); of define( 'WP_DEBUG', false );. Wijzig die zodat debugging uitstaat:

define( 'WP_DEBUG', false );

Gebruik de boolean false zonder aanhalingstekens. Een 'false' tussen aanhalingstekens is een string, en PHP zou dat als waar behandelen.

3. Verberg overige PHP-fouten op het scherm indien nodig

Sommige hosts printen PHP-fouten nog steeds, ook als de debugmodus van WordPress uitstaat. Als dat gebeurt, voeg dan de volgende regel toe bij je WP_DEBUG-instelling, alleen als die er nog niet staat:

@ini_set( 'display_errors', 0 );

Na een zorgvuldige bewerking moet dat gedeelte er zo uitzien — niet als twee kopieën van WP_DEBUG onder elkaar:

define( 'WP_DEBUG', false );
@ini_set( 'display_errors', 0 );

Wat dit doet:

define( 'WP_DEBUG', false ); — Zet de debugmodus van WordPress uit. Bezoekers zouden geen WordPress-debuguitvoer meer moeten zien. Dit logt de fouten niet voor je.
@ini_set( 'display_errors', 0 ); — Zegt tegen PHP dat fouten niet in de HTML van de pagina moeten worden geprint. Het is een weergave-instelling, geen oplossing.

Vermijd error_reporting(0); als hoofdbenadering. Het dempt PHP-rapportage zo grondig dat het moeilijker wordt te achterhalen wat kapotging.

Wat je daarna moet doen: de echte fout diagnosticeren en herstellen

Zodra de openbare site weer leesbaar is, zoek je de oorzaak. Een goede werkwijze:

Maak een back-up voordat je plugins, thema’s of code wijzigt.
Reproduceer het probleem wanneer je kunt op een stagingkopie of een lokale site, zodat bezoekers nooit debuguitvoer zien.
Schakel op die stagingkopie logging in zonder fouten op het scherm te tonen. Plaats dit vóór /* That's all, stop editing! */ en werk bestaande debugregels bij in plaats van ze te dupliceren:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Hoe die regels samenwerken:

WP_DEBUG — moet true zijn wil de andere twee debugconstanten effect hebben.
WP_DEBUG_LOG — schrijft berichten naar wp-content/debug.log (of een ander pad dat je instelt). Het doet niets als WP_DEBUG false is.
WP_DEBUG_DISPLAY — ingesteld op false, plus display_errors ingesteld op 0, houdt die berichten van de pagina zodat je ze in het logbestand kunt lezen.

Open debug.log via FTP of de bestandsbeheerder van je host — niet door het in een browser downloadbaar te laten. Een logbestand in wp-content kan serverpaden en pluginnamen blootleggen als iemand het via HTTP kan ophalen. Schakel debugging daarna weer uit en verwijder of beperk het logbestand.

Gebruik het log om de plugin, het thema of het PHP-bestand te identificeren dat de waarschuwing of fout veroorzaakte. Werk die code bij of herstel die, en laad de betrokken pagina’s opnieuw om te bevestigen dat het bericht verdwenen is.

WordPress documenteert deze debuginstelling in het handboek voor ontwikkelaars.

Waarom je niet moet stoppen bij het verbergen van het bericht

Verborgen fouten kunnen nog steeds functies breken, de site vertragen of een beveiligingsprobleem laten bestaan. De opruiming op het scherm beschermt alleen bezoekers terwijl je werkt. Het echte doel is een stabiele site waarvan het onderliggende probleem is opgelost.

Conclusie

In een noodgeval kun je de foutuitvoer van WordPress en PHP verbergen door de bestaande WP_DEBUG-regel naar false te zetten en, indien nodig, display_errors uit te schakelen — altijd vóór de opmerking “stop editing”, en nooit door dezelfde constante twee keer te definiëren. Diagnoseer daarna de oorzaak op een back-up of stagingsite met debuglogging, herstel de verantwoordelijke plugin, het thema of de PHP-code, en controleer. Een waarschuwing verbergen is tijdelijk; de fout herstellen is wat blijft.