‘Not a valid JSON response’ i WordPress: REST, permalink og firewall

Kort svar: Fejlen opstår, når WordPress-editoren forventer JSON fra en REST-request, men modtager noget andet – f.eks. en 403-side, redirect, PHP-fejl eller HTML. Åbn browserens Network-panel, gentag gemningen, og undersøg den konkrete /wp-json/-request. Ret derefter det dokumenterede lag: URL/HTTPS, rewrite, firewall, autentificering eller plugin. Classic Editor kan omgå symptomet, men løser ikke den defekte response.

Fagligt gennemgået: 2. oktober 2026

Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151 på isoleret staging. Forkert HTML-svar og REST-/noncefejl er kontrolleret med Hostious Article Lab 1.4.1; et rigtigt site skal diagnosticeres ud fra sin egen fejlede request.

“Updating failed. The response is not a valid JSON response” er en slutbesked, ikke en årsag. Editorens JavaScript kunne ikke parse det svar, den fik. Det kan være tomt, afbrudt, omdirigeret eller være en HTML-fejlside i stedet for JSON.

Derfor begynder en sikker fejlfinding ved den ene request – ikke med ti tilfældige WordPress-indstillinger.

Før du ændrer noget: Gem kladden lokalt, tag backup, og kopier requestens URL, status og response body. Slå ikke REST API fra, og publicér ikke PHP-fejl i response body på et live-site.

Find den request, der faktisk fejler

1. Åbn det indlæg eller den side, der ikke kan gemmes.
2. Åbn browserens udviklerværktøj og vælg Network.
3. Ryd listen, klik Gem kladde eller Opdater én gang.
4. Filtrér på wp-json eller røde requests.
5. Vælg requesten og notér metode, status, request URL, response headers og Response.

En editoropdatering bruger typisk et autentificeret REST-kald. At forsiden virker, eller at /wp-json/ viser et JSON-indeks, beviser derfor ikke, at den konkrete POST/PUT-request med cookie og nonce virker.

Network-resultat	Hvad det typisk betyder	Kontrol	Næste skridt
301/302 til login, www eller anden protokol	URL/HTTPS/canonical/redirectproblem	Location-header og Settings → General	Trin 1
401/403 med JSON-fejlkode	Session, nonce, capability eller auth-regel	Response body og ny login-session	Trin 2
403 med HTML/challenge	Firewall/WAF/sikkerhedsplugin	Regel-event på samme tidspunkt	Trin 3
404 på /wp-json/...	Rewrite/permalink eller manglende endpoint	REST-indeks og permalinkstatus	Trin 4
500/502 eller PHP-tekst før JSON	Fatal fejl, output eller serverproblem	PHP-log og response body	Trin 5
200, men body er HTML eller tom	Redirect, injected output eller cache	Content-Type og første bytes	Trin 5-6

1. Kontrollér WordPress-URL og Site-URL

Gå til Indstillinger → Generelt og sammenlign:

• WordPress-adresse (URL);
• Webstedsadresse (URL);
• den URL, du bruger i browseren;
• request URL i Network.

Vær især opmærksom på http kontra https, www kontra uden www og en gammel stagingadresse. Ret kun værdierne, hvis du ved, hvad installationens WordPress- og public root er. En forkert ændring kan låse dig ude af admin.

Hvis en reverse proxy afslutter HTTPS, skal WordPress og proxyen være enige om den oprindelige protokol. Beviset er et redirect i request-kæden – ikke blot at siden “ser ud til at være HTTPS”.

Efter en rettelse logger du ud og ind igen, så cookies og nonce oprettes på den korrekte origin, og gentager præcis samme gemning.

2. Udeluk udløbet session, nonce og brugerrettighed

Hvis response body er en WordPress JSON-fejl med 401/403:

1. Gem teksten lokalt.
2. Log ud og ind i en ny fane.
3. Åbn indlægget igen og gentag én gang.
4. Test på staging med en anden administrator, hvis fejlen fortsætter.
5. Kontrollér, om den berørte bruger har den nødvendige capability til posttypen.

WordPress' browserbaserede REST-authentication bruger login-cookie og en nonce. Et gammelt redigeringsvindue kan have en udløbet nonce, men en vedvarende fejl efter ny login skal undersøges – ikke “løses” ved konstant genlogin.

3. Find firewall- eller sikkerhedsreglen

Hvis response er en HTML-blokside eller 403:

• find requesten i sikkerhedspluginets eller hostingens eventlog;
• match sti, metode, bruger/IP og tidspunkt;
• notér regel-id og den del af payloaden, der udløser den;
• lav en snæver undtagelse for endpoint og nødvendig metode;
• gentag samme request og en negativ kontrol.

Undgå at allowliste hele /wp-json/ eller alle administratorrequests. REST API indeholder både offentlige og autentificerede routes, og en bred undtagelse kan fjerne relevant beskyttelse.

Hvis fejlen kommer fra Cloudflare, hører regeljusteringen hjemme i Cloudflare-hubben; denne artikel skal blot forklare, hvordan Network-response beviser laget.

4. Genopbyg rewrite-regler uden at skifte URL-struktur

Hvis endpointet giver 404, men /?rest_route=/ virker, peger det på rewrite/permalinklaget.

1. Tag kopi af .htaccess eller den relevante Nginx-konfiguration.
2. Gå til Indstillinger → Permanente links.
3. Notér den valgte struktur.
4. Klik Gem ændringer uden at vælge en anden struktur.
5. Kontroller WordPress' besked om, hvorvidt reglerne blev skrevet.
6. Gentag REST-requesten.

På Nginx ændrer WordPress ikke en .htaccess; serverens try_files/routing skal være korrekt. Hvis du ikke ejer serverkonfigurationen, sender du hostingen endpoint, status og tidspunkt.

Skift ikke permanent til “Plain” for at skjule problemet. Det ændrer offentlige URL'er og løser ikke den manglende serverrouting.

5. Stop PHP-output og find fatal errors

En REST-response skal være ren JSON. En PHP-notice, warning, BOM, debugtekst eller fatal fejl kan gøre body ugyldig.

Brug WordPress-logning med fejlvisning slået fra på live:

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

Konstanterne placeres før WordPress' “stop editing”-linje og fjernes eller sættes tilbage efter testen. Logfilen må ikke være offentligt tilgængelig.

Gentag gemningen én gang og match tidspunktet i loggen. Hvis en pluginfil eller hook skriver output, ret eller rul den komponent tilbage. Slet ikke bare output fra response body; årsagen skal væk.

Hvis Network viser 500/502, følg den konkrete kritisk fejl eller 502-guide i stedet for at fortsætte med permalinks.

6. Isolér plugin, tema eller optimering i staging

Cache-, sikkerheds-, redirect- og optimeringsplugins kan ændre REST-responses. Brug staging eller sessionbaseret Troubleshooting Mode:

1. Reproducer fejlen med samme indhold.
2. Test med et standardtema og kun nødvendige plugins i din session.
3. Aktivér mistænkte grupper binært.
4. Gentag samme Network-request efter hver ændring.
5. Dokumentér den kombination, der får body til at skifte fra gyldig JSON til fejl.

Hvis kun ét bestemt indlæg fejler, opret på staging en kopi og fjern senest tilføjede blokke i grupper. En defekt specialblok eller serverregel, der matcher dens indhold, kan være mere sandsynlig end et globalt REST-problem.

Brug konfliktguiden til den fulde metode. Classic Editor er kun en midlertidig arbejdsvej, hvis redaktionen skal redde tekst; den dokumenterer ikke, at REST API er repareret.

7. Kontrollér redirect- og cachelaget

Se hele request-kæden i Network. En POST-request må ikke ændres til en login- eller HTML-side af en generisk redirect. Kontroller regler, der matcher:

• /wp-json/;
• posttypen eller slugdele i endpointet;
• trailing slash;
• www/non-www;
• HTTP/HTTPS;
• sprog- eller loginredirects.

REST-responses til indloggede brugere bør ikke serveres som en offentlig cachevariant. Bekræft med response headers, om et cachelag rammer requesten. Purge kun efter, at kildereglen er rettet.

Et konkret mønster er en POST til /wp-json/wp/v2/pages/123, som får 302 til login og derefter 200 HTML. Editorens slutbesked nævner JSON, men den første fejl er redirecten. Sammenlign cookie-domain, HTTPS og Location-header; ret login- eller canonicalreglen, og bekræft at samme POST igen svarer direkte med JSON uden mellemliggende hop.

Kontrollér samtidig, at en anonym REST-request stadig har den tilsigtede adgang.

Gem status for begge kontroller.

Notér også den endelige Content-Type.

Sådan verificerer du rettelsen

Test ikke kun en tom kladde. Gentag det oprindelige scenarie:

• samme indlæg, indhold og brugerrolle;
• én gemning som kladde og én opdatering;
• den fejlende request returnerer forventet 2xx-status;
• Content-Type er JSON-kompatibel;
• body kan parses og indeholder den forventede postrespons;
• ingen ny PHP- eller firewall-event opstår.

Åbn derefter den offentlige URL og kontroller titel, indhold og canonical. En succes-toast i editoren er ikke alene bevis for, at det rigtige indlæg blev opdateret.

Rollback

• gendan oprindelige URL-/proxyværdier, hvis ændringen ikke hjælper;
• gendan .htaccess eller serverkonfiguration fra kopien;
• fjern den snævre firewallundtagelse;
• sæt debugkonstanter tilbage;
• reaktivér stagingens oprindelige plugin-/temakombination.

Efter rollback gentages Network-testen, så du ved, om årsagssammenhængen var reel.

Hvornår skal hosting eller udvikler hjælpe?

Hosting skal hjælpe, når endpointet rammer serverrouting, mod_security/WAF, proxy, auth-header eller PHP-fejl uden for din adgang. Send endpoint, metode, status, timestamp og anonymiseret response – aldrig cookies, nonce eller loginoplysninger.

Plugin-/temaudvikleren skal have den mindste reproducerbare kombination og den præcise REST-fejlkode. Hostious WordPress-support kan hjælpe med Network- og logafgrænsningen.

Sådan dokumenterer du JSON-fejlen

Følg den samme fejlede request gennem editor, Netværk og log:

1. Editorens fejlbesked og Network-filter i samme billede på et testsite.
2. Failing request: status, Content-Type og anonymiseret Response.
3. Site Health REST-test med detaljepanelet åbent.
4. Før/efter af samme request, hvor body går fra HTML/fejl til JSON.

Gem et renset HAR-udsnit eller request/response-headers sammen med det matchende logevent. Fjern cookies, X-WP-Nonce, bruger-id og indholdsdata, før materialet deles.

Ofte stillede spørgsmål om JSON-fejlen

Hvorfor siger WordPress-editoren Not a valid JSON response?

Editoren forventede JSON fra /wp-json/, men fik noget andet – typisk en 403-side, et redirect eller en PHP-fejl. Åbn browserens Network-panel, gentag gemningen, og se hvad requesten reelt returnerer.

Mister jeg mit indhold, når fejlen opstår?

Som regel ikke. WordPress gemmer kladder lokalt og autosaver løbende. Kopiér alligevel teksten, før du genindlæser siden, hvis du er midt i en større ændring.

Løser Classic Editor problemet?

Nej, den skjuler det kun. Classic Editor bruger ikke samme REST-kald, så symptomet forsvinder, men den defekte response findes stadig og kan ramme andre funktioner som plugins og mediebiblioteket.

Læs også

• Hub: WordPress fejl og fejlfinding
• WordPress REST API-fejl
• 403 Forbidden i WordPress
• Kritisk fejl i WordPress
• Plugin- eller temakonflikt
• WordPress hosting hos Hostious – managed WordPress med daglig backup og staging fra WP StartUp