syntax error, unexpected: een PHP-parse error in WordPress oplossen

Je site toont ineens een melding die begint met Parse error: syntax error, unexpected, gevolgd door een bestandspad en een regelnummer. Of er staat helemaal niets: een leeg wit scherm, of die bekende "Er heeft zich een kritieke fout voorgedaan op deze website" terwijl de echte parse error eronder verborgen blijft. Hoe dan ook: PHP is iets in je code tegengekomen wat het niet begrijpt en heeft de boel direct stilgelegd.

Wat deze fout precies betekent

Een parse error is PHP die weigert een bestand uit te voeren omdat de syntaxis niet klopt. Volgens de PHP-handleiding bij de error-constanten is E_PARSE een compile-time fout: die treedt op voordat je script überhaupt start. Eén verkeerd teken en het hele bestand is onbruikbaar. In WordPress betekent dat meestal dat je hele site onbruikbaar is, want zo'n bestand wordt bij elke request geladen.

Een volledige WordPress parse error ziet er zo uit:

Parse error: syntax error, unexpected token "function" in /home/jouwsite/public_html/wp-content/themes/jouwthema/functions.php on line 42

Drie stukjes informatie tellen, in deze volgorde:

1. Het bestand. Hier: wp-content/themes/jouwthema/functions.php. Dit vertelt je of het probleem in een thema, een plugin, wp-config.php of ergens anders zit.
2. Het regelnummer. Hier: 42. Dat zit bijna altijd vlakbij de echte fout. PHP meldt de regel waar het voor het eerst iets raars zag, en dat kan een of twee regels ná de echte oorzaak liggen (een vergeten puntkomma op regel 41 leidt bijvoorbeeld tot een "unexpected token" op regel 42).
3. De onverwachte token. Hier: "function". PHP vertelt je wat het vond dat het niet verwachtte. Een onverwachte ) betekent meestal dat er eerder een ( mist. Een onverwachte } betekent meestal een afsluitende accolade teveel of een openende die mist. Een onverwachte function betekent vaak dat de vorige regel niet werd afgesloten met ;.

Zie je de fout helemaal niet? Spring dan even naar Eerst diagnosticeren, dan pas aanraken en zet WP_DEBUG aan. Alles wat daarna volgt leunt op het kennen van het bestand en het regelnummer.

De meest voorkomende oorzaken, op volgorde van waarschijnlijkheid

1. Je hebt functions.php bewerkt vanuit de WordPress-editor in het dashboard. Dit is verreweg de meest voorkomende manier om je site zelf plat te leggen. Je plakt een snippet, klikt op opslaan, en op datzelfde moment verliest je admin de toegang omdat WordPress dezelfde kapotte functions.php ook nodig heeft om het dashboard te renderen. Resultaat: geen front-end, geen back-end en geen duidelijke weg terug.
2. Je hebt een snippet gekopieerd van een blog of forum. Code die is geschreven voor PHP 5.6 of voor een oudere WordPress-versie bevat soms syntaxis die PHP 8.2 niet meer slikt. String-access met accolades zoals $string{0} is verwijderd in PHP 8.0, maar staat nog in oude tutorials. Snippets zonder <?php ?>-tags eromheen, of met per ongeluk twee keer <?php, laten de parser ook meteen sneuvelen.
3. Een plugin- of thema-update bracht kapotte PHP mee voor jouw PHP-versie. De ontwikkelaar testte op PHP 8.3, jij zit op PHP 8.2, en een taalconstructie gedraagt zich anders. Zeldzaam maar het gebeurt. Je ziet de fout dan direct na de update. Als de update niet afgerond werd, zie je hem mogelijk samen met een vastgelopen "Briefly unavailable for scheduled maintenance"-pagina.
4. Een vergeten of overtollig haakje, accolade, puntkomma of aanhalingsteken. De klassieker. Eén teken. Je voegt een nieuwe functie toe aan functions.php, vergeet de afsluitende }, en PHP meldt "unexpected end of file" op de allerlaatste regel. Of je opent een string met " en sluit hem met ', en PHP eet vrolijk de halve code op terwijl het op zoek is naar het juiste sluitteken.
5. Een afgebroken FTP-upload. De upload werd onderbroken, het bestand is half, en PHP botst op het einde van een functie of class die nooit werd afgesloten. Opnieuw uploaden vanuit een schone kopie lost het op.

De rode draad: bijna elke parse error verschijnt direct nadat er code veranderd is. Door jou of door iets dat jij net in gang hebt gezet. "Vanochtend deed-ie het nog" is in 95 procent van de gevallen het verhaal. Dat is eigenlijk goed nieuws, want het betekent dat je ongeveer weet waar je moet kijken.

Eerst diagnosticeren, dan pas aanraken

Voordat je ook maar één bestand opent: weet zeker dat je de foutmelding echt ziet en dat je weet welk bestand stuk is.

• Zie je de volledige Parse error:-melding in de browser? Noteer het bestandspad en het regelnummer. Door naar de oplossing.
• Zie je "Er heeft zich een kritieke fout voorgedaan op deze website"? Dan verbergt WordPress de echte fout met opzet omdat WP_DEBUG uit staat. Dat is de standaardinstelling op een live site. Je moet WP_DEBUG tijdelijk aanzetten. Werk eerst mijn artikel over de critical error door: WordPress 5.2 en hoger sturen een recovery mode-mail naar het admin-adres waarin de schuldige plugin of het schuldige thema met naam wordt genoemd. Vaak is die mail alleen al genoeg om de rest van dit artikel over te slaan.
• Zie je een volledig leeg wit scherm? Dan heb je de klassieke White Screen of Death te pakken. Dezelfde oplossing: WP_DEBUG aanzetten om de parse error eronder zichtbaar te maken.

Om debug-output aan te zetten, log je met SFTP in of open je de file manager in je hosting-paneel. Open wp-config.php in de WordPress-root (de map met wp-content erin) en zoek deze regel:

define( 'WP_DEBUG', false );

Wijzig hem in:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WP_DEBUG_LOG schrijft fouten naar wp-content/debug.log in plaats van ze aan bezoekers te tonen. WP_DEBUG_DISPLAY op false houdt de fout buiten de publieke kant. Herlaad de pagina en open daarna wp-content/debug.log. Daar zie je de volledige parse error met bestand en regelnummer. Schrijf het op.

Je weet dat de diagnose klaar is als je het exacte bestandspad én het exacte regelnummer in handen hebt. Is de log leeg? Dan onderdrukt je host PHP-fouten mogelijk op serverniveau. Kijk in dat geval in de PHP error log van je control panel (cPanel noemt het Errors, DirectAdmin noemt het Site Error Log, Plesk noemt het Logs). Dezelfde regel staat daar ook.

Zet debug weer uit als je klaar bent: WP_DEBUG terug naar false. Laat je hem aan staan, dan lekken paden en foutdetails naar bezoekers.

De oplossing: terugzetten of herstellen van het kapotte bestand

Je weet nu welk bestand stuk is en ongeveer waar. Je hebt drie opties, op volgorde van veiligheid. Pak de eerste die bij jouw situatie past.

Optie 1: gebruik de recovery mail van WordPress 5.2+

Zit het kapotte bestand in een plugin of thema, en draai je WordPress 5.2 of hoger (vrijwel zeker op een moderne install, en op WordPress 6.7 sowieso), dan heeft WordPress je al een mail gestuurd. Die gaat naar het admin-adres in Instellingen → Algemeen en heeft een onderwerp zoals "Je site ondervindt een technisch probleem". De recovery mode-functie is geïntroduceerd in WordPress 5.2 voor exact deze situatie.

1. Check de inbox van het admin-adres, ook de spam. De afzender is je eigen site.
2. Open de mail. Daar staat welke plugin of welk thema de boel heeft laten crashen.
3. Klik op de recovery-link in de mail. Je logt in op een werkende versie van wp-admin waarin de schuldige extensie tijdelijk is uitgeschakeld.
4. Ga naar Plugins of Weergave → Thema's. Deactiveer, verwijder of zet de genoemde extensie terug op de vorige versie. Heb je net een update geïnstalleerd? Dan is de vorige versie van de meeste plugins nog beschikbaar in de WordPress plugin directory, of in de dagelijkse back-up van je host.
5. Log uit van recovery mode. Herlaad de publieke site.

Je weet dat het werkt als de site normaal laadt voor bezoekers en er geen nieuwe regels meer bij komen in debug.log.

Is er geen mail aangekomen, werkt de uitgaande mail van je site niet, of zit de fout helemaal niet in een plugin of thema (maar in wp-config.php, .htaccess of een core-bestand)? Spring naar optie 2.

Optie 2: zet het kapotte bestand terug via SFTP of file manager

Dit is de veiligste handmatige aanpak. Je bewerkt niks, je vervangt het bestand door een werkende versie.

1. Open je SFTP-client (FileZilla, Cyberduck, Transmit) of de file manager van je host. Maak verbinding.
2. Navigeer naar het kapotte bestand uit de parse error. Voor een thema: wp-content/themes/jouwthema/functions.php. Voor een plugin: wp-content/plugins/pluginnaam/pluginnaam.php, of welk bestand de fout ook noemde.
3. Zit het kapotte bestand in een plugin of thema? Download een schone kopie van diezelfde versie vanaf wordpress.org/plugins of van de site van de ontwikkelaar. Upload die en overschrijf het kapotte bestand. Zat je op een nieuwere versie die de directory niet meer bijhoudt? Val dan terug op de dagelijkse back-up van je host.
4. Is het kapotte bestand functions.php in een actief thema waar je zelf in zat te editen? Hernoem de kapotte functions.php naar functions.php.broken zodat je je wijzigingen nog kunt teruglezen. Upload daarna een schone functions.php uit de originele ZIP van je thema. De site komt direct terug, simpelweg omdat WordPress je custom code kwijtraakt tot jij die zorgvuldig opnieuw toevoegt.
5. Zit het kapotte bestand in wp-config.php of .htaccess? Bij beide heb je een voorbeeldbestand om mee te vergelijken. Naast wp-config.php staat wp-config-sample.php in de WordPress-download. Voor .htaccess regenereert WordPress een werkende versie met de standaard rewrite-regels zodra je de permalinks opslaat in Instellingen → Permalinks.
6. Herlaad de site.

Je weet dat het werkt als de voorpagina gewoon laadt, er geen nieuwe Parse error-regels meer in debug.log verschijnen en wp-admin weer bereikbaar is.

Optie 3: repareer de regel direct (alleen als je weet wat je kapot hebt gemaakt)

Heb je zelf net een snippet toegevoegd en weet je precies welke regels? Dan kun je het bestand openen in een fatsoenlijke editor en de fout ter plekke repareren. Bewerk PHP niet in kladblok of Notepad. Gebruik VS Code of een andere editor met PHP syntax highlighting en bracket matching: die markeert de stukke regel al voordat je opslaat.

Veelvoorkomende fixes bij veelvoorkomende foutteksten:

Opslaan, site herladen, debug.log in de gaten houden. Verschijnt er een nieuwe fout op een andere regel? Dan zit daar de volgende fout: die los je op dezelfde manier op. Herhaal tot de site het weer doet.

Je weet dat het werkt als debug.log niet verder groeit en de site gewoon laadt na een harde refresh.

Wanneer escaleren

Heb je recovery mode geprobeerd, het bestand teruggezet én handmatig gerepareerd, en doet de site het nog steeds niet? Tijd om hulp te vragen. Verzamel eerst dit, voordat je een ticket opent bij je host, je ontwikkelaar of je managed WordPress-partij:

• De exacte parse error-tekst, letterlijk gekopieerd uit debug.log of de browser. Inclusief het volledige bestandspad en het regelnummer.
• Je WordPress-versie, PHP-versie (zichtbaar in Gereedschap → Sitediagnose → Info → Server als je bij het dashboard kunt, of in het hosting-paneel), en de naam van het actieve thema.
• De plugin of het thema dat sneuvelde, plus de versie vóór en ná de wijziging als je dat weet.
• Een overzicht van wat je al hebt geprobeerd uit dit artikel (recovery-mail, bestand teruggezet, handmatig gerepareerd).
• De laatste 50 regels uit wp-content/debug.log van het afgelopen uur.
• De bijbehorende PHP-foutregel uit de error log van je hosting control panel op hetzelfde tijdstip.

Met dat rijtje erbij kan een support engineer een parse error meestal binnen vijf minuten diagnosticeren. Zonder dat rijtje moet diezelfde engineer je één voor één om dezelfde details gaan vragen, en dan wordt een fix van tien minuten ineens een dag werk.

Hoe je de volgende voorkomt

• Bewerk nooit PHP vanuit de WordPress-editor in het dashboard. De in-dashboard file editor (Weergave → Themabestandseditor, Plugins → Plugin-bestandeneditor) slaat direct op zonder vangnet. Eén typfout en je bent het dashboard kwijt. Zet hem helemaal uit door define( 'DISALLOW_FILE_EDIT', true ); toe te voegen aan wp-config.php.
• Gebruik een child theme voor code die je zelf schrijft. Een child theme is een dun schilletje over je echte thema. Maak je daar iets stuk, dan kun je de hele child-map gewoon hernoemen via SFTP en neemt het parent-thema het weer over. Je live site blijft dan gewoon draaien terwijl je de child-map repareert.
• Test nieuwe code eerst in staging of lokaal. Local by WP Engine zet in een paar klikken een complete WordPress op je laptop neer. Elke host die het geld waard is, heeft ook een staging-knop. Plak je snippet daar eerst. Gaat het stuk, dan gaat het stuk op een plek waar niemand het ziet.
• Gebruik een echte editor met PHP syntax highlighting. VS Code, PhpStorm of Sublime Text pakken ongepaarde haakjes en vergeten puntkomma's op terwijl je typt. Niet alles, maar wel de voor de hand liggende fouten.
• Maak een back-up vóór elke codewijziging en elke update. Bij fatsoenlijke managed hosts gebeurt dat dagelijks automatisch, en sommige triggeren bovendien een snapshot net voor een update draait. Check of die van jou dat doet. Een parse error herstel je met een back-up in tien seconden, zonder back-up ben je een uur kwijt.