WordPress-editoren vil ikke indlæse — sådan finder du årsagen

Kort svar: Når blokeditoren står tom, hænger på indlæsning eller viser “Editoren stødte på en uventet fejl”, er årsagen næsten altid enten en JavaScript-fejl fra et plugin eller et REST API-kald, der bliver blokeret. Åbn browserens konsol (F12) og fanen Netværk: den første røde linje eller den første wp-json-forespørgsel, der ikke giver status 200, peger på synderen. Dit indhold er ikke væk – det ligger i databasen.

Fagligt gennemgået: 2. oktober 2026

Blokeditoren er en JavaScript-applikation, der kører i din browser og henter og gemmer alt gennem WordPress’ REST API på adressen /wp-json/. Det betyder, at editoren kan gå i stykker af to helt forskellige grunde: kode i browseren, der fejler, eller forespørgsler til serveren, der ikke får det svar, editoren forventer.

Fejlfindingen handler derfor om at finde ud af, hvilken af de to verdener problemet ligger i. Det tager sjældent mere end et par minutter, når du ved, hvor du skal kigge.

Før du ændrer noget: Kopiér tekst, du ikke har nået at gemme, til et andet sted, før du genindlæser. Slå ikke alle plugins fra på et live site med trafik – især ikke en webshop. Test på staging, eller brug en fejlfindingstilstand, der kun gælder din egen session (se trin 5).

Hvilket symptom ser du?

Symptom	Typisk årsag	Første kontrol
Editoren er helt hvid eller tom	JavaScript-fejl, der stopper hele editoren	Konsollen (trin 1)
“Editoren stødte på en uventet fejl”	En blok eller et plugin-script fejler	Knappen “Kopiér fejl” og konsollen
Hænger på indlæsning	REST API blokeret, langsomt eller fanget af en annonceblokering	Netværk-fanen (trin 3)
“Opdatering mislykkedes. Svaret er ikke et gyldigt JSON-svar”	REST-svaret er en HTML-side eller indeholder PHP-advarsler	Not a valid JSON response
“Denne blok indeholder uventet eller ugyldigt indhold”	Blokkens gemte HTML passer ikke til blokkens nuværende kode	Afsnittet om ugyldige blokke nedenfor
Virker for administrator, ikke for redaktør	REST API begrænset til bestemte roller	Sikkerhedsplugin og firewall
Gik i stykker lige efter en opdatering	Gamle scripts i cachen eller forældet Gutenberg-plugin	Ryd cache (trin 4)

1. Læs browserens konsol

Tryk F12 (eller Cmd+Option+I på Mac), vælg fanen Konsol, og genindlæs editoren. Den første røde linje er den vigtigste – senere fejl er ofte følgefejl. Filstien i linjen indeholder som regel navnet på pluginnet eller temaet.

De røde linjer falder i tre familier, og hver har sin løsning:

• “Uncaught TypeError” eller “… is not a function” med en sti under /wp-content/plugins/ eller /wp-content/themes/ er et plugin eller tema, der fejler. Stien siger hvilket.
• “Failed to load resource: 403” eller “net::ERR_BLOCKED_BY_CLIENT” er noget, der blokerer. Det første er en firewall eller et sikkerhedsplugin på serveren, det andet er en udvidelse i din egen browser.
• “Unexpected token < in JSON” betyder, at editoren bad om data og fik en HTML-side tilbage – typisk en fejlside eller en loginside, fordi sessionen udløb, eller fordi REST API’et omdirigeres.

Viser editoren “Editoren stødte på en uventet fejl”, så klik på Kopiér fejl. Teksten, du får, er den samme fejl som i konsollen og er nyttig at sende til en udvikler eller support.

2. Prøv et privat vindue

Åbn editoren i et privat vindue eller en anden browser. Virker den dér, er det næsten altid en browserudvidelse – typisk en annonceblokering, en privatlivsudvidelse eller en grammatikhjælper, der griber ind i tekstfelter. Slå udvidelserne fra én ad gangen, og tilføj sitet som undtagelse i den, der giver problemet.

Virker editoren heller ikke i et privat vindue, ligger fejlen på sitet, og du fortsætter til næste trin.

3. Tjek REST API’et og Netværk-fanen

Åbn fanen Netværk i udviklerværktøjerne, filtrér på wp-json, og genindlæs editoren. Kig på statuskoderne:

Status	Betydning	Hvor du leder
200	Kaldet virker	Problemet er i browseren – se konsollen
401	Du er ikke logget rigtigt ind, eller cookien afvises	Login-loop og cookies
403	Noget blokerer – sikkerhedsplugin, firewall eller Cloudflare-regel	Plugin- eller firewall-log for samme tidspunkt
404	REST-ruten findes ikke – ofte permalinks eller en omdirigering	Permalinks giver 404
500 eller 502	PHP eller serveren fejler på kaldet	PHP-fejlloggen
504 eller timeout	Kaldet tager for lang tid	504 Gateway Timeout

Du kan også teste API’et direkte ved at åbne denne adresse i browseren:

https://dinside.dk/wp-json/wp/v2/types

Får du JSON tilbage, svarer API’et. Får du en fejl, en tom side eller din forside, er det blokeret eller omdirigeret – og så kan editoren hverken indlæse eller gemme. Værktøjer → Webstedets helbred tester også REST API’et og melder fejl under “Kritiske problemer”. Se REST API-fejl i Webstedets helbred.

PHP-advarsler, der ødelægger svaret

En klassisk og overset årsag: WP_DEBUG_DISPLAY står til true på et live site, eller PHP er sat til at vise fejl. Så bliver en harmløs advarsel fra et plugin skrevet ind i starten af REST-svaret, og JSON-svaret bliver ugyldigt. Klik på den fejlende forespørgsel i Netværk-fanen og se fanen Svar: starter den med “Warning:”, “Notice:” eller “Deprecated:”, har du fundet det. Slå visning af fejl fra, og log dem i stedet:

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

Ret derefter den advarsel, loggen viser, eller opdatér pluginnet, der giver den.

4. Slå optimering fra i administrationen, og ryd cachen

Cache- og optimeringsplugins bør slet ikke røre wp-admin. Kontrollér at minificering, sammenlægning og udskydning af JavaScript kun gælder frontend, og at administrationsområdet er undtaget. Det samme gælder Cloudflare-funktioner som Rocket Loader, der omskriver scripts.

Editoren får nye scripts med hver WordPress-version, og de må ikke ligge i en cache. Går editoren i stykker lige efter en opdatering, så ryd først browserens cache og derefter sitets cache, inden du leder efter plugins – en gammel version af editorens scripts i cachen sammen med en ny kerne giver præcis de fejl, konsollen viser. Har du et CDN foran sitet, skal dets cache også ryddes for wp-includes og wp-admin.

Bruger sitet Gutenberg-pluginnet ved siden af kernen, så hold de to i takt. Gutenberg-pluginnet er udviklingsversionen af editoren, og en gammel udgave sammen med en ny WordPress-kerne er en klassisk kilde til tomme editorer. Har du ikke en grund til at køre det, så deaktivér det – kernen indeholder allerede editoren.

5. Find pluginet uden at ramme besøgende

Peger konsollen ikke tydeligt på et plugin, skal du indkredse det. Gør det på staging, eller brug pluginnet Health Check & Troubleshooting, hvis fejlfindingstilstand slår plugins fra kun for din egen session, mens besøgende ser sitet som normalt.

Slå plugins fra i halvdele: halvdelen fra, test editoren, og fortsæt med den halvdel, hvor fejlen er. Med 30 plugins finder du synderen på omkring fem runder. Se sådan finder du en plugin- eller temakonflikt for den fulde metode. Glem ikke temaet – et tema kan også indlæse scripts i editoren.

Virker editoren på sider, men ikke på produkter eller en bestemt indholdstype, er det pluginnet bag den indholdstype – typisk en tilpasset blok, der ikke er opdateret til den nyeste editorversion. Opdatér pluginnet først, og prøv igen.

6. Få læsbare fejl med SCRIPT_DEBUG

WordPress leverer normalt editorens scripts i minificeret form, så fejlbeskeder i konsollen kan pege på en linje med tusindvis af tegn. Sæt midlertidigt denne linje i wp-config.php:

define( 'SCRIPT_DEBUG', true );

Så indlæser WordPress de ikke-minificerede versioner af sine egne scripts, og fejlen i konsollen får et læsbart fil- og linjenummer. Det gælder kun WordPress’ egne filer, ikke plugins. Fjern linjen igen, når du har det, du skal bruge.

Når det virker for dig, men ikke for redaktøren

Virker editoren for administratoren, men ikke for en bruger med redaktør- eller forfatterrolle, er det som regel rettigheder på REST API’et. Nogle sikkerhedsplugins lukker /wp-json/ for alle, der ikke er administratorer, og så kan andre roller hverken indlæse blokke eller gemme. Åbn sikkerhedspluginnets indstillinger for REST API, og tillad det for indloggede brugere. Det samme kan ske med Cloudflares firewall-regler eller med regler i .htaccess, der blokerer wp-json for alle undtagen bestemte IP-adresser.

Tjek også, at rollen faktisk har de nødvendige rettigheder. Plugins til rollestyring kan have fjernet fx edit_posts eller rettigheden til at uploade filer, og så fejler dele af editoren uden en tydelig besked.

“Denne blok indeholder uventet eller ugyldigt indhold”

Denne besked er ikke et nedbrud, men en valideringsfejl. Hver blok gemmer sin HTML i indlægget, og når editoren indlæser det, genererer den HTML’en igen og sammenligner. Er de forskellige – fordi et plugin har ændret blokkens opbygning, eller fordi nogen har redigeret HTML’en i hånden – markeres blokken som ugyldig.

• Forsøg at gendanne blok lader editoren genopbygge blokken. Det virker oftest, men tjek resultatet.
• Konvertér til HTML beholder indholdet præcis som det er, som en HTML-blok.
• Sker det for mange blokke af samme type efter en pluginopdatering, så vent med at gemme og tjek, om pluginnet har en opdatering eller en migreringsvejledning.

Nødløsningen: den klassiske editor

Skal du redigere en side her og nu, kan du midlertidigt slå blokeditoren fra med pluginnet Classic Editor. Det er en nødudgang, ikke en løsning. Indhold skrevet i blokke vises som HTML med blokkommentarer, og redigerer du i dem, kan blokkene blive ugyldige, når du skifter tilbage. Brug den kun til små rettelser, og find den egentlige årsag bagefter.

Verificér, at editoren virker igen

• Åbn et eksisterende indlæg, en side og – hvis relevant – et produkt.
• Gem en kladde, og tjek i Netværk-fanen, at kaldet til wp-json giver 200.
• Upload et billede i en billedblok.
• Test med en redaktørbruger, ikke kun som administrator.
• Kontrollér, at konsollen ikke viser nye røde linjer.
• Fjern SCRIPT_DEBUG og eventuel debug-logning igen.

Læs også

• Hub: WordPress fejl og fejlfinding
• “Not a valid JSON response” i WordPress – når editoren ikke kan gemme
• WordPress REST API-fejl i Site Health – API’et, editoren afhænger af
• Find en plugin- eller temakonflikt – uden at ramme live-sitet
• Rocket Loader ødelægger JavaScript – når Cloudflare omskriver scripts
• Elementor til WordPress: hvad sidebyggeren er, hvad den koster i hastighed, og hvornår du skal vælge noget andet
• WordPress hosting hos Hostious – hosting med staging fra WP StartUp og dansk support

Ofte stillede spørgsmål om WordPress-editoren

Kan langsom hosting give det?

Indirekte. Timer kaldene til REST API’et ud, giver editoren op. Sker det jævnligt, så find ud af, om det er PHP, databasen eller et bestemt plugin, der gør kaldet langsomt – og om sitet mangler ressourcer.

Mister jeg mit indhold?

Nej. Indholdet ligger i databasen, og WordPress gemmer automatiske kladder og revisioner undervejs. Kopiér dog tekst, du ikke har nået at gemme, før du genindlæser.

Editoren virker for mig, men ikke for redaktøren. Hvorfor?

Sandsynligvis fordi et sikkerhedsplugin eller en firewall-regel kun tillader REST API’et for administratorer. Editoren bruger API’et til at indlæse og gemme, så tillad /wp-json/ for alle indloggede brugere.

Hvad betyder ‘Unexpected token < in JSON’ i konsollen?

At editoren bad om data fra REST API’et og fik en HTML-side i stedet – typisk en loginside, en fejlside eller en omdirigering. Tjek, om du stadig er logget ind, og om noget omdirigerer eller blokerer wp-json.