WordPress risposta JSON non valida compare quando l’editor o un plugin attende una risposta REST in formato JSON ma riceve HTML, un redirect, un errore PHP, un blocco WAF o una risposta vuota. Il messaggio descrive il formato ricevuto, non necessariamente la causa originaria.
Questa guida approfondisce WordPress risposta JSON non valida con verifiche progressive e reversibili. Non inviare password, cookie, token, chiavi private, codici 2FA o file di configurazione completi nei ticket.
Che cosa significa
L’editor a blocchi usa la REST API per leggere e salvare contenuti. Se `/wp-json/` non funziona, se home e siteurl non sono coerenti o se una regola filtra la richiesta, il salvataggio può fallire.
Il codice HTTP e il corpo della richiesta REST devono essere controllati negli strumenti sviluppatore. Una pagina HTML di login, un 403 o un fatal error possono essere presentati come JSON non valido.
Come riconoscere il problema
- Pubblicazione o aggiornamento fallisce nell’editor.
- La console mostra una richiesta REST con 401, 403, 404 o 500.
- `/wp-json/` non restituisce JSON.
- Il problema nasce dopo HTTPS, migrazione o plugin di sicurezza.
- L’editor classico funziona ma quello a blocchi no.
Cause più frequenti
1. Permalink e rewrite
L’endpoint REST restituisce 404 o la homepage. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
2. URL WordPress incoerenti
Protocollo o hostname producono redirect. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
3. WAF o ModSecurity
La richiesta JSON viene bloccata. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
4. Errore PHP
La risposta contiene warning, notice o fatal error. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
5. Autenticazione e nonce
La sessione non è valida o wp-admin è cacheato. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
6. Plugin o tema
Un componente modifica REST, output o header. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla schermata mostrata dal client.
Diagnosi passo per passo
- Apri DevTools Network. Individua la richiesta fallita e il codice. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Leggi il corpo risposta. Verifica se è HTML, redirect o errore. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Testa `/wp-json/`. Controlla indice e route interessata. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Salva i permalink. Rigenera rewrite dopo backup di .htaccess. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Controlla home e siteurl. Devono usare hostname e protocollo canonici. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Esamina log e WAF. Correla orario, endpoint e rule ID. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
- Disattiva il componente in staging. Conferma plugin o tema senza compromettere produzione. Salva il risultato prima di passare al controllo successivo, così potrai individuare il punto preciso nel quale il comportamento cambia.
Metodo sicuro di diagnosi
Prima di modificare la configurazione, registra URL o servizio coinvolto, messaggio completo, data e ora, ultima modifica nota, client o rete e risultato ottenuto con un secondo strumento. Questa fotografia iniziale permette di confrontare i test e di tornare alla configurazione precedente quando una modifica non produce il risultato atteso.
Applica una sola correzione alla volta. Dopo ogni intervento ripeti esattamente la stessa operazione e controlla i log dello stesso intervallo temporale. Modificare contemporaneamente DNS, cache, PHP, plugin, proxy e firewall elimina la possibilità di attribuire il risultato a una causa precisa.
Controllo incrociato
Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin, Site Health e WP-CLI; per DNS interroga nameserver autoritativi e resolver pubblici; per la posta confronta Webmail, intestazioni originali e Track Delivery. Cache, TTL e code possono mostrare stati differenti per alcuni minuti.
Quando il problema sembra risolto, esegui una seconda prova con una nuova sessione, un secondo utente o una seconda rete quando applicabile. Verifica inoltre che TLS, autenticazione, WAF, permessi e controlli antispam restino attivi: una correzione che disabilita stabilmente le protezioni non è una soluzione definitiva.
Verifica prolungata dopo la correzione
Conserva temporaneamente backup, valori precedenti ed estratti dei log. Ripeti il controllo dopo il normale ciclo di cache, cron, coda o TTL. Se l’anomalia ricompare a intervalli regolari, confronta l’orario con backup, aggiornamenti, rinnovi SSL, rotazioni DNS, processi pianificati e servizi esterni.
Documenta il risultato finale con data, comando o schermata utilizzata e condizione verificata. Questa nota evita interventi duplicati e rende più rapida una futura analisi da parte dell’assistenza.
Procedura di risoluzione
- Ripristina permalink e rewrite. Correggi .htaccess o regole del web server. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Allinea HTTP e HTTPS. Configura WordPress, proxy e CDN coerentemente. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi il fatal error. Intervieni sul file indicato dal log. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Applica una esclusione WAF mirata. Limitata a route e parametro legittimi. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Escludi wp-admin e REST autenticata dalla cache. Mantieni la cache pubblica dove appropriato. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Aggiorna plugin e tema. Rimuovi filtri REST incompatibili. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Ritesta salvataggio e anteprima. Verifica anche media e metadati. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
Come raccogliere prove utili
Quando riproduci il problema, conserva soltanto i dati tecnici necessari: codice di risposta, URL priva di token, orario con fuso, request ID, nome del client, dimensione del file o del messaggio e una breve descrizione dell’operazione. Evita screenshot parziali quando puoi esportare il testo originale, perché header, log e messaggi completi permettono una diagnosi più precisa.
Prima di chiudere il controllo, confronta il comportamento con una configurazione nota e funzionante. Per una API usa un payload minimo; per WordPress prova una funzione core senza plugin aggiuntivi; per DNS interroga direttamente i nameserver; per la posta usa Webmail e conserva il file `.eml`. Questo confronto riduce le ipotesi e impedisce modifiche inutili.
Controlli finali
- Editor salva e pubblica.
- REST restituisce JSON.
- Nessun redirect inatteso.
- WAF attivo.
- Log senza nuovi errori.
Prevenzione
- Staging.
- Permalink controllati.
- HTTPS coerente.
- Plugin aggiornati.
- Monitoraggio REST.
Errori da evitare
- Non disattivare REST API globalmente.
- Non mostrare errori PHP ai visitatori.
- Non cancellare .htaccess senza backup.
- Non disabilitare WAF permanentemente.
- Non usare l’editor classico come unica correzione.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:
- URL articolo
- endpoint REST
- codice e corpo risposta
- orario
- log o rule ID
Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.
Fonti tecniche ufficiali
Domande frequenti su WordPress risposta JSON non valida
Il messaggio significa che il contenuto è JSON errato?
Non sempre; spesso WordPress riceve HTML o un errore al posto del JSON.
Salvare i permalink può risolvere?
Sì, se le regole REST non sono instradate correttamente.
Cloudflare può influire?
Sì, tramite redirect, cache o regole WAF.
Perché l’editor classico funziona?
Usa un flusso diverso e dipende meno dalla REST API.
Quale dato devo controllare per primo?
Codice e corpo della richiesta REST fallita in DevTools.