WordPress, editor e salvataggio

WordPress non salva le modifiche: cosa significa “risposta JSON non valida”

Scorri per leggere la guida
Persona al computer aggiorna una pagina del sito con campioni prodotto e appunti sulla scrivania.

La pagina si apre nell’editor, ma quando premi Aggiorna compare un errore sulla risposta JSON e il lavoro sembra bloccato.

Questo messaggio descrive una risposta che l’editor non riesce a interpretare. Per trovare la causa occorre seguire il tentativo di salvataggio, preservare il contenuto e distinguere sessione, indirizzi, protezioni e componenti del sito.

In breve

L’errore JSON non identifica da solo il componente guasto. Una diagnosi utile parte da una bozza di prova e dalla risposta effettiva del server, mettendo in relazione l’errore con gli ultimi cambiamenti del sito.

  • Conserva testo e blocchi prima di chiudere la pagina.
  • Confronta una bozza semplice con il contenuto problematico.
  • Fai controllare richiesta, risposta e registri del server.
  • Collauda salvataggio, anteprima e pubblicazione.
Passaggio 01

Conservare il contenuto prima delle prove

Non chiudere subito la scheda dell’editor. Copia il testo in un documento locale e, se sai usare l’editor del codice dei blocchi, conserva anche la struttura del contenuto. Annotare titolo, immagini inserite e modifiche recenti aiuta a ricostruire il lavoro qualora il salvataggio non sia stato completato.

Apri una seconda scheda per controllare l’ultima versione registrata, senza sovrascrivere quella su cui stai lavorando. Un errore nella risposta non prova che tutte le operazioni siano fallite: confronta contenuto e revisioni disponibili. Se più persone modificano la stessa pagina, concorda chi prosegue e ferma i tentativi sovrapposti.

Quando il problema è già nella schermata di accesso, consulta la guida al pannello WordPress bloccato. Qui il punto di partenza è un editor aperto che non conclude un’operazione.

Passaggio 02

Capire che cosa sta segnalando l’editor

L’editor a blocchi scambia dati con WordPress attraverso la REST API, come descritto nel manuale ufficiale delle REST API. Quando si aspetta una risposta in formato JSON e riceve qualcosa di diverso o non interpretabile, può mostrare questo errore. Il messaggio indica il risultato osservato dall’editor, non una causa unica.

Al posto dei dati attesi potrebbe arrivare una pagina HTML di errore, un reindirizzamento all’accesso o una risposta interrotta. La verifica decisiva consiste quindi nell’esaminare la richiesta fallita. Non serve installare un plugin soltanto perché contiene “JSON” nel nome: prima occorre capire quale passaggio ha alterato la comunicazione.

Passaggio 03

Distinguere sessione scaduta e contenuto problematico

Dopo aver conservato il lavoro, entra nuovamente dal collegamento abituale e crea una bozza con un titolo e un paragrafo semplice. Se questa viene salvata, confrontala con la pagina originale: blocchi particolari, campi aggiuntivi o dimensione del contenuto possono delimitare l’indagine. Non pubblicare una pagina di prova visibile ai clienti.

Se nessuna bozza funziona, prova un’altra sessione del browser e coinvolgi un collega autorizzato con il proprio account. La documentazione sull’autenticazione REST spiega che le operazioni interne dipendono da cookie, controlli della richiesta e permessi dell’utente. Un accesso da rinnovare e un ruolo insufficiente richiedono verifiche diverse.

Registra l’esito di ogni confronto. “Non salva nulla” e “non salva solo quella pagina con un blocco esterno” sono segnalazioni molto differenti per chi deve intervenire.

Passaggio 04

Far leggere la risposta effettiva del server

Il tecnico può ripetere la prova osservando la scheda Rete degli strumenti del browser. Servono indirizzo della richiesta, stato HTTP, tipo di risposta e orario. Un accesso negato suggerisce il controllo di autenticazione o protezioni; una pagina non trovata orienta verso percorso e instradamento; un errore del server richiede i registri applicativi. Sono indizi, non diagnosi automatiche.

Non condividere pubblicamente esportazioni di rete complete: possono contenere cookie, identificativi e parti del contenuto. Concorda una raccolta limitata con il manutentore. Il controllo di un indirizzo pubblico dell’API può essere utile, ma una lettura riuscita non dimostra che il salvataggio autenticato funzioni: vanno provate l’operazione e la pagina interessate.

Passaggio 05

Controllare indirizzi, protezioni e ultime modifiche

Se l’errore è iniziato dopo una migrazione, confronta dominio, HTTPS e indirizzi configurati. Chi gestisce il server deve verificare eventuali reindirizzamenti e regole che interessano l’API. Non cambiare la struttura dei permalink a tentativi: gli indirizzi pubblici del sito hanno un proprio ruolo e qualsiasi modifica va valutata.

Controlla inoltre se un firewall, un plugin di sicurezza o un sistema di cache ha intercettato la richiesta. Quando emerge un componente sospetto, prova una correzione circoscritta in un ambiente di test, mantenendo una copia recuperabile. La guida agli errori dopo un aggiornamento aiuta a ricostruire la sequenza degli interventi.

La schermata Salute del sito offre informazioni utili su configurazione e componenti. Per errori PHP, la documentazione WordPress sul debug distingue raccolta dei registri e visualizzazione degli errori: le informazioni tecniche non vanno lasciate esposte ai visitatori.

Passaggio 06

Un esempio ipotetico: il salvataggio viene intercettato

Una redattrice aggiorna regolarmente un catalogo, ma dopo una nuova regola di protezione una pagina specifica non si salva. La bozza di un paragrafo funziona. Il tecnico confronta i tentativi e trova nei registri del firewall una richiesta bloccata allo stesso orario dell’errore; la risposta ricevuta è una pagina HTML del sistema di protezione.

In questo scenario verifica il falso positivo, corregge la regola interessata secondo le procedure del servizio e ripete il salvataggio mantenendo attive le altre protezioni. Non attribuisce il problema al testo per il solo fatto che una bozza breve funzionasse. Il confronto tra richiesta e registro è ciò che consente di confermare la causa.

Passaggio 07

Verificare il recupero con il lavoro editoriale reale

Riprova la pagina originaria e confronta il risultato salvato con la copia conservata. Controlla i campi aggiuntivi, le immagini e l’anteprima. Poi esegui una modifica breve e riapri l’editor: vedere una conferma una sola volta non basta se le informazioni non persistono.

  • Bozza e aggiornamento completano la richiesta.
  • Il contenuto salvato coincide con quello atteso.
  • Anteprima e pagina pubblica mostrano la versione corretta.
  • Ruoli editoriali e controlli di accesso restano coerenti.
  • La causa e la correzione sono documentate.

Inserisci la prova nel processo per aggiornare il sito in autonomia. Se l’anomalia ricompare, lo storico permette di confrontare versione, contenuto e configurazione senza ripartire da zero.

Passaggio 08

Domande frequenti

Il testo contiene caratteri sbagliati?

Il messaggio, da solo, non lo dimostra. Un contenuto specifico può far emergere un problema, ma la risposta del server deve essere esaminata prima di attribuirgli la causa.

Passare a un altro editor risolve?

Può cambiare il percorso usato per salvare, ma non chiarisce perché la richiesta precedente falliva. Valuta la causa prima di modificare il modo di lavorare del personale.

Devo ripristinare tutto il sito?

Solo se la diagnosi lo rende necessario e dopo aver protetto i dati recenti. Molti controlli riguardano sessione, configurazione o singole regole e non richiedono una sostituzione completa.

Fonti e approfondimenti

Documentazione ufficiale per approfondire i criteri descritti nella guida.

Torniamo a pubblicare con un percorso di verifica chiaro

Raccontaci in quale pagina si blocca il salvataggio e quali modifiche hanno preceduto l’errore. Possiamo esaminare il flusso editoriale e organizzare l’intervento sul sito.

Approfondisci il servizio

Parliamo del tuo sitoUn primo confronto chiaro, senza impegno e con un referente dedicato.