De WordPress-blokeditor die niet laadt oplossen

Meestal is een WordPress-blokeditor die niet wil laden een JavaScript-fout — één kapot script van een plugin of thema legt de hele React-app plat, en de editor rendert nooit helemaal. Open de developer console van je browser (F12, of Cmd+Option+I op een Mac), herlaad het bewerkscherm en lees de rode fout. Die noemt vrijwel altijd het bestand dat de fout gooide. Die ene regel vertelt je welke plugin je moet uitschakelen, en meestal kun je binnen vijf minuten weer schrijven. WordPress opnieuw installeren, de PHP memory limit ophogen en overstappen naar de Classic Editor zijn de drie meest genoemde suggesties online, en alle drie zijn meestal de verkeerde zet.

Waarom de editor kapotgaat zoals hij doet

De blokeditor (Gutenberg) is een single-page React-applicatie die draait binnen wp-admin/post.php en post-new.php. WordPress laadt een stapel scriptpakketten in de wachtrij — wp-blocks, wp-element, wp-editor, wp-edit-post — en de app start op via wp.domReady(). JavaScript stopt met uitvoeren bij de eerste onafgevangen uitzondering. Dus als een van de ingeladen scripts een fout gooit terwijl de editor initialiseert, sterft alles daarna mee. Je zorgvuldig geschreven berichtgebied stort in tot een leeg wit vlak of de melding “The editor has encountered an unexpected error.”

Standaard voegt WordPress ook admin-scripts samen tot minder verzoeken. Dat betekent dat de kapotte JS van één plugin niet-gerelateerde scripts kan meesleuren die in dezelfde bundel geladen worden, en daarom is de boosdoener niet altijd duidelijk uit het gedrag alleen. De console wel.

De tweede manier waarop het misgaat ziet er anders uit: de editor laadt wel, maar bij het opslaan komt “Updating failed. The response is not a valid JSON response.” Dat is geen JavaScript-probleem. De editor praat met de REST API op /wp-json/wp/v2/, en verwacht daar schone JSON terug. Als een plugin of de functions.php van je thema een PHP-notice, -warning of kritieke fout uitstoot vóór de JSON — of een security-plugin de REST-route blokkeert, of een redirect-plugin de URL herschrijft — dan is de response vervuild en kan de editor die niet parsen.

Hoe je het oplost, snelste eerst

1. Lees de console. Reproduceer de fout met DevTools open. Een fout als Uncaught TypeError ... some-plugin/build/index.js wijst je meteen naar de schuldige plugin. Deze ene stap lost de meeste gevallen op en bespaart je blind zoeken.

2. Sluit de browser uit. Doe een harde refresh (Cmd/Ctrl+Shift+R) en probeer daarna een incognitovenster met extensies uit. Adblockers en privacy-extensies verwijderen soms admin-scripts. Als het in incognito wel werkt, zit het probleem in een browserextensie of een verouderde cache, niet in je site.

3. Controleer de REST API rechtstreeks als je de melding “not a valid JSON” zag. Ga naar https://yoursite.com/wp-json/ in een browser. Je zou een muur van JSON moeten krijgen. Krijg je HTML, een 500 of een login-redirect, dan is dat je bug — een plugin breekt de REST-response, niet de editor zelf.

4. Zoek je plugins uit via halveren. Schakel ze allemaal uit, bevestig dat de editor laadt, en zet ze daarna een voor een weer aan tot het opnieuw misgaat. Als je helemaal buitengesloten bent uit wp-admin, doe het dan via SFTP door de map te hernoemen:

mv wp-content/plugins wp-content/plugins_off

WordPress schakelt alles uit zodra de map verdwijnt. Hernoem hem terug en verplaats de plugins daarna een voor een in en uit.

5. Test het thema. Schakel over naar Twenty Twenty-Four. Een thema dat kapotte editor-JS inlaadt of PHP-fouten gooit in functions.php geeft dezelfde symptomen.

6. Zet de log aan en lees de echte fout. Vooral bij de REST/JSON-problemen: schakel debugging in via wp-config.php:

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

De kritieke fout wordt weggeschreven naar wp-content/debug.log met het exacte bestand en regelnummer. Is die stack trace dicht — namespaced klassenamen, require-ketens, een kritieke fout begraven onder tien regels trace — plak hem dan in onze WordPress error log decoder om in gewone taal te zien welke plugin en welke regel het echt veroorzaakten. Dat is het verschil tussen “er is iets kapot” en “regel 214 van deze specifieke plugin is kapot.”

Vermoed je dat het samenvoegen van scripts de echte boosdoener maskeert, dwing dan elk script om apart te laden zodat de console-fout precies naar één bestand wijst:

define( 'SCRIPT_DEBUG', true );
define( 'CONCATENATE_SCRIPTS', false );

Wat je niet moet doen

Installeer niet de Classic Editor-plugin en noem het opgelost. Het lost niets op — het verbergt de blokeditor zodat je de fout niet meer ziet. De kapotte JavaScript of kapotte REST-response zit er nog steeds, en die bijt je opnieuw in de site-editor, in widgets, of de volgende keer dat je updatet. Stel eerst de diagnose; val alleen terug op Classic als je een bewuste keuze hebt gemaakt om te stoppen met blokken.

Verhoog niet reflexmatig de PHP memory limit. Het is de favoriete kopieer-plak-oplossing van het internet, maar een lege editor is zelden een uitgeput geheugen. Echte uitputting gooit een specifieke kritieke fout — “Allowed memory size of N bytes exhausted” — die je in debug.log ziet. Staat die regel er niet, dan verandert meer geheugen niets.

Installeer WordPress-core niet opnieuw. Core-bestanden zijn byte-identiek op elke installatie. Als core het probleem was, zou elke WordPress-site ter wereld nu een kapotte editor hebben. De fout zit vrijwel altijd in je plugins of thema, en core opnieuw installeren riskeert dingen te overschrijven terwijl het niets oplost.

Leeg of schakel niet blindelings je cache-plugin uit als eerste stap. Agressieve JS-minificatie en samenvoeging kunnen de editor breken, dus het is de moeite waard om te testen — maar controleer de console voordat je lukraak caches gaat legen. Gokken is hoe een fix van vijf minuten een middag kost.

Kom je er niet uit?

Is de console schoon, geeft de REST API geldige JSON terug, en laat een volledige plugin- en thema-halvering de editor nog steeds dood, dan zit het antwoord vrijwel altijd in debug.log. Schakel WP_DEBUG_LOG in, reproduceer de fout één keer, en haal de resulterende kritieke fout door de error log decoder. De stack trace noemt het bestand — begin daar.