U wilt even een tekst aanpassen op de homepage. U klikt op Bewerken, het scherm wordt wit en er gebeurt niets meer. Of de editor verschijnt wel, maar bij het opslaan krijgt u de melding “Bijwerken mislukt. De reactie is geen geldige JSON-reactie.” De site zelf werkt gewoon; bezoekers merken niets. Maar u kunt niets meer veranderen, en dat is op den duur net zo vervelend.

Als de WordPress editor niet laadt, is dat zelden een defect in WordPress zelf. De blokkeneditor is een toepassing die in uw browser draait en voortdurend met de server praat. Zodra dat gesprek stokt, valt de editor stil. In dit artikel bespreken we de vijf oorzaken die wij het vaakst tegenkomen en de volgorde waarin u ze het snelst uitsluit.

Hoe de blokkeneditor werkt en waarom dat uitmaakt

De klassieke editor van vroeger was een gewoon formulier: u typte, klikte op opslaan en de pagina laadde opnieuw. De blokkeneditor werkt anders. Hij laadt één keer en haalt daarna alles op via de REST API, een soort loket op de server waar de editor gegevens ophaalt en terugbrengt. Elke handeling, van het openen van een pagina tot het opslaan van een concept, is een verzoek aan dat loket.

Daaruit volgt de belangrijkste conclusie: als de editor wit blijft of niet kan opslaan, is de kans groot dat het loket dicht is, verkeerd antwoordt of dat iets in de browser de editor zelf tegenhoudt. Dat zijn precies de plekken waar u gaat zoeken.

Vijf oorzaken waarom de WordPress editor niet laadt

1. De REST API wordt geblokkeerd

Beveiligingsplugins hebben vaak een optie om de REST API uit te schakelen of af te schermen, bedoeld om aanvallers geen informatie te geven. Staat die optie te streng, dan kan ook de ingelogde beheerder er niet meer bij. Hetzelfde geldt voor firewalls bij de hostingpartij en voor Cloudflare-regels die verzoeken naar /wp-json/ tegenhouden. Controleer dit eerst onder Gereedschap, Sitegezondheid: een melding over de REST API is een sterke aanwijzing.

2. Een plugin- of themaconflict

Een plugin die een JavaScript-fout veroorzaakt in het beheer, kan de hele editor laten stranden. Vaak gaat het om oudere plugins die nog voor de klassieke editor zijn geschreven, om paginabouwers die de editor overnemen, of om een thema dat een verouderde manier van laden gebruikt. Na een update komt dit het meest voor.

3. Permalinks of .htaccess zijn beschadigd

De REST API is bereikbaar via een mooie URL zoals uwdomein.nl/wp-json/. Die URL werkt alleen als de herschrijfregels op de server kloppen. Zijn die kwijt, dan geeft het loket een 404 en toont de editor de JSON-melding. Dit gebeurt na een verhuizing, na het handmatig aanpassen van .htaccess of na een pluginconflict dat de regels overschrijft.

4. Mixed content of een verkeerde site-URL

Staat de site-URL onder Instellingen op http terwijl u inlogt via https, dan probeert de editor scripts te laden van een onveilig adres. De browser blokkeert dat stilletjes. Het resultaat is een wit vlak zonder foutmelding.

5. Te weinig geheugen of een PHP-fout op de achtergrond

Als de server tijdens het antwoorden op een REST-verzoek een fout tegenkomt, komt er geen nette JSON terug maar een stuk foutmeldingstekst. De editor kan daar niets mee. Een te lage geheugenlimiet of een verouderde PHP-versie is dan vaak de onderliggende reden.

Stappenplan in de juiste volgorde

  1. Test in een ander venster. Open het beheer in een privévenster of een andere browser. Werkt het daar wel, dan zit het in een browserextensie of in de cache. Adblockers en privacy-extensies blokkeren regelmatig scripts van de editor.
  2. Kijk in Sitegezondheid. Staat daar een melding over de REST API of over loopback-verzoeken, dan weet u de richting. Meer over wat die meldingen betekenen leest u in de uitleg over sitegezondheid.
  3. Open uwdomein.nl/wp-json/ in de browser. Ziet u een lange lap tekst met accolades, dan werkt het loket. Ziet u een 404 of een lege pagina, ga dan naar Instellingen, Permalinks en klik op Wijzigingen opslaan zonder iets te veranderen. Dat herschrijft de regels.
  4. Controleer de site-URL’s. Onder Instellingen, Algemeen moeten beide adressen op https staan als uw site via https draait.
  5. Schakel de beveiligingsplugin tijdelijk uit en probeer de editor opnieuw. Werkt hij nu wel, zoek dan in de plugin-instellingen naar een optie over de REST API en sta die toe voor ingelogde gebruikers.
  6. Schakel de overige plugins één voor één uit, of allemaal tegelijk en dan één voor één weer aan. Hoe u dat doet zonder de site voor bezoekers te verstoren, staat in het artikel over een pluginconflict vinden.
  7. Zet tijdelijk een standaardthema aan als de plugins zijn uitgesloten. Werkt de editor dan wel, dan zit het probleem in het thema.
  8. Laat de foutmelding in de browserconsole bekijken. Met F12 opent u de ontwikkelaarstools; het tabblad Console toont rode regels die precies aangeven welk script faalt. U hoeft ze niet zelf te begrijpen, maar ze zijn goud waard voor wie u helpt.

Praktijkvoorbeeld: een kinderopvang in Nijmegen

Een kinderopvangorganisatie in Nijmegen kon al drie weken geen nieuwsberichten meer plaatsen. De editor bleef wit. De locatiemanager had een collega gevraagd, die had een cacheplugin geleegd, zonder resultaat. Toen wij keken, meldde Sitegezondheid dat de REST API “een onverwacht resultaat” gaf. In de browserconsole stond een 403-fout op elk verzoek naar /wp-json/.

De oorzaak zat bij de hostingpartij: die had drie weken eerder een nieuwe firewallregel ingevoerd die verzoeken met bepaalde kenmerken weigerde, en de editor viel daar per ongeluk onder. Een uitzondering voor ingelogde gebruikers loste het op. Wat opviel: de site was in die drie weken voor bezoekers nooit uit de lucht geweest, dus niemand had het als storing herkend. Precies daarom is een editor die niet laadt zo verraderlijk.

Als het niet lukt

Stap 1 tot en met 5 kan iedere beheerder zelf. Het uitsluiten van plugins en thema’s kost meer tijd en vraagt om een moment waarop bezoekers er weinig van merken, of om een staging-omgeving. Komt u er na een uur niet uit, dan is dit een typisch geval om te laten oplossen. Bij het verhelpen van WordPress-fouten is een niet-ladende editor een van de vaker voorkomende opdrachten, en met de gegevens uit de console en Sitegezondheid is de oorzaak meestal snel gevonden.

Voorkomen

Houd plugins en thema bijgewerkt, maar wel met een back-up vooraf en een test van de editor achteraf. Laat de REST API aan voor ingelogde gebruikers, ook als u een beveiligingsplugin gebruikt. Controleer na elke verhuizing de permalinks en de site-URL. En test de editor kort nadat uw hostingpartij een wijziging aankondigt. Wie deze paar gewoontes aanhoudt, ziet het witte scherm zelden terug.