{"id":13897,"date":"2026-11-09T09:12:30","date_gmt":"2026-11-09T09:12:30","guid":{"rendered":"https:\/\/andreafreelance.com\/?p=13897"},"modified":"2026-11-09T09:12:32","modified_gmt":"2026-11-09T09:12:32","slug":"errori-rest-api-wordpress","status":"publish","type":"post","link":"https:\/\/andreafreelance.com\/en\/errori-rest-api-wordpress\/","title":{"rendered":"WordPress: correggere gli errori REST API al salvataggio"},"content":{"rendered":"\n\n
\n \n
\n \n
\n
\n \n\n
<\/div>\n <\/div>\n
\n \n\n
<\/div>\n <\/div>\n
\n \n\n
<\/div>\n <\/div>\n
\n \n\n
<\/div>\n <\/div>\n
\n \n\n
<\/div>\n <\/div>\n <\/div>\n \n
\n
\n \n\n
<\/div>\n <\/div>\n
\n \n\n
<\/div>\n <\/div>\n
\n \n\n
<\/div>\n <\/div>\n
\n \n\n
<\/div>\n <\/div>\n
\n \n\n
<\/div>\n <\/div>\n <\/div>\n<\/div>\n \n\n
\n Vota questo post<\/span>\n <\/div>\n <\/div>\n\n

Per risolvere gli errori della WordPress REST API durante il salvataggio, individua la richiesta non riuscita e leggi la risposta del server. Il messaggio “La risposta non \u00e8 una risposta JSON valida” pu\u00f2 dipendere da una sessione scaduta, dai permalink, da un plugin o dalla configurazione del server. La risposta HTTP aiuta a distinguere queste cause.<\/p>\n\n\n\n

Il mio consiglio \u00e8 partire dalla risposta HTTP<\/strong>, evitando modifiche casuali. Prima proteggi il lavoro non salvato, poi segui una diagnosi che separi autenticazione, permessi e problemi infrastrutturali.<\/p>\n\n\n\n

Come funzionano le richieste REST di WordPress<\/h2>\n\n\n\n

Perch\u00e9 l’editor comunica con gli endpoint<\/h3>\n\n\n\n

L’editor a blocchi usa la REST API per leggere e salvare contenuti, inviando richieste HTTP al server web. WordPress 4.7 ha integrato nel core gli endpoint dei contenuti nel dicembre 2016.<\/p>\n\n\n\n

Le route predefinite comprendono \/wp\/v2\/posts<\/code>, \/wp\/v2\/pages<\/code> e \/wp\/v2\/users<\/code>, normalmente raggiungibili sotto \/wp-json\/<\/code>. Ogni endpoint deve essere registrato e associato a un’operazione. I metodi HTTP mappano le azioni: GET legge i dati, POST crea contenuti e pu\u00f2 aggiornarli, PUT indica un aggiornamento e DELETE elimina. Durante la diagnosi, considero normale anche un aggiornamento inviato con POST.<\/p>\n\n\n\n

La documentazione distingue precisamente route ed endpoint REST<\/a>: percorso e metodo HTTP devono corrispondere a un’operazione registrata.<\/p>\n\n\n\n

Quale risposta si aspetta WordPress<\/h3>\n\n\n\n

L’editor deve ricevere una risposta JSON coerente. Una pagina HTML di accesso, un avviso PHP o un blocco del firewall possono rendere illeggibile la risposta.<\/p>\n\n\n\n

REST deriva dalla tesi di Roy Fielding<\/a> del 2000. I vincoli comprendono interfaccia uniforme, separazione client-server, statelessness, cacheabilit\u00e0 e architettura a strati; il codice eseguibile su richiesta \u00e8 opzionale. Lo stesso disaccoppiamento tra client e server permette di usare WordPress come headless CMS. Un front end separato legge e invia contenuti tramite REST API.<\/p>\n\n\n\n

Per correggere il salvataggio, serve capire quale livello interrompe questa comunicazione.<\/p>\n\n\n\n

1. Individua la richiesta che non salva<\/h2>\n\n\n\n

Proteggi contenuti e ambiente di lavoro<\/h3>\n\n\n\n

Prima di ricaricare l’editor, copia altrove il testo non salvato. Le revisioni non sostituiscono una copia delle modifiche ancora presenti soltanto nel browser.<\/p>\n\n\n\n

Prima di cambiare configurazioni, crea un backup di file e database. Preferisco eseguire le prove su staging, soprattutto quando il sito raccoglie ordini o richieste.<\/p>\n\n\n\n

Su un e-commerce WooCommerce, disattivare un’estensione pu\u00f2 interrompere pagamenti o integrazioni. Inoltre, un ripristino completo pu\u00f2 sovrascrivere gli ordini successivi al backup. La mia guida all’assistenza WordPress per PMI<\/a> approfondisce l’organizzazione degli interventi.<\/p>\n\n\n\n

Leggi la scheda Rete del browser<\/h3>\n\n\n\n

Apri gli strumenti per sviluppatori, seleziona Rete<\/strong> e ripeti il salvataggio. Filtra le richieste Fetch\/XHR oppure cerca wp-json<\/code>.<\/p>\n\n\n\n

\"Una<\/figure>\n\n\n\n

Seleziona la richiesta fallita e annota URL, metodo, stato HTTP e orario. Nella scheda Risposta distingui il JSON da eventuali pagine HTML. Controlla anche gli header, in particolare Content-Type<\/code>.<\/p>\n\n\n\n

La Console aiuta a trovare errori JavaScript, ma da sola non identifica la risposta del server. Evita inoltre di condividere esportazioni delle richieste senza oscurare cookie, token CSRF e credenziali.<\/p>\n\n\n\n

2. Interpreta lo stato HTTP e il messaggio JSON<\/h2>\n\n\n\n

Questi codici orientano la diagnosi, ma non identificano automaticamente il componente responsabile.<\/p>\n\n\n\n

Stato<\/th>Indizio principale<\/th>Primo controllo<\/th><\/tr><\/thead>
400<\/td>Dati o parametri non validi<\/td>Corpo JSON e campi richiesti<\/td><\/tr>
401<\/td>Autenticazione assente o fallita<\/td>Credenziali e sessione<\/td><\/tr>
403<\/td>Accesso negato<\/td>Token di sicurezza, capability o firewall<\/td><\/tr>
404<\/td>Risorsa o route non trovata<\/td>Percorso, metodo e permalink<\/td><\/tr>
413<\/td>Richiesta troppo grande<\/td>Limiti di server o proxy<\/td><\/tr>
429<\/td>Troppe richieste<\/td>Policy o regole di rate limiting attive su server, reverse proxy o CDN<\/td><\/tr>
500<\/td>Errore interno<\/td>Log PHP e server<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Parti quindi dalla categoria indicata, poi confronta risposta e log.<\/p>\n\n\n\n

Un errore REST generato da WP_Error<\/code> pu\u00f2 contenere code<\/code>, message<\/code> e data.status<\/code>. Per esempio, rest_cookie_invalid_nonce<\/code> indirizza verso la verifica del token di richiesta; rest_invalid_param<\/code> indica un parametro rifiutato.<\/p>\n\n\n\n

\n

Anche una risposta HTTP 200 pu\u00f2 far fallire il salvataggio se contiene HTML o avvisi PHP invece del JSON atteso.<\/p>\n<\/blockquote>\n\n\n\n

Un codice 403 accompagnato dal marchio del firewall richiede invece una diagnosi diversa da un errore JSON prodotto da WordPress.<\/p>\n\n\n\n

3. Ripristina autenticazione e nonce<\/h2>\n\n\n\n

Sessione dell’editor e nonce scaduto<\/h3>\n\n\n\n

Con l’autenticazione tramite cookie, WordPress richiede un nonce associato all’azione wp_rest<\/code>. Il codice pu\u00f2 generare questo token con wp_create_nonce( 'wp_rest' )<\/code> e inviarlo tramite X-WP-Nonce<\/code> oppure _wpnonce<\/code>.<\/p>\n\n\n\n

Se il token manca, WordPress tratta la richiesta come non autenticata, anche quando esiste un cookie di accesso. Se \u00e8 scaduto, pu\u00f2 comparire un 403.<\/p>\n\n\n\n

Dopo aver copiato il testo, rinnova l’accesso e riapri l’editor. Controlla inoltre che pannello e richieste usino lo stesso dominio e HTTPS. L’autenticazione valida, comunque, non concede automaticamente i permessi necessari.<\/p>\n\n\n\n

Application Password e prova con curl<\/h3>\n\n\n\n

Per chiamate esterne, WordPress supporta le Application Password dalla versione 5.6. La documentazione sull’autenticazione<\/a> descrive il loro utilizzo tramite Basic Authentication, che richiede HTTPS. Per script diagnostici e integrazioni server-to-server, sono una soluzione pi\u00f9 immediata rispetto a flussi complessi come OAuth.<\/p>\n\n\n\n

L’header Authorization<\/code> contiene lo schema Basic<\/code> seguito da username:password<\/code> codificato in Base64. Base64 non cifra le credenziali<\/strong>.<\/p>\n\n\n\n

In locale, define( 'WP_ENVIRONMENT_TYPE', 'local' );<\/code> in wp-config.php<\/code> dichiara l’ambiente e consente questa modalit\u00e0 anche senza HTTPS. Non usarla per aggirare la protezione del sito pubblico.<\/p>\n\n\n\n

Imposta le variabili dell’ambiente e prova soltanto su una bozza:<\/p>\n\n\n\n

curl --user \"$WP_USER:$WP_APP_PASSWORD\" \n  --request POST \n  \"$WP_URL\/wp-json\/wp\/v2\/posts\/$POST_ID\" \n  --header 'Content-Type: application\/json' \n  --data '{\"title\":\"Bozza di prova\"}'\n<\/code><\/pre>\n\n\n\n
WP_APP_PASSWORD<\/code> deve contenere la password applicativa, non quella principale. La richiesta modifica il titolo del contenuto indicato da POST_ID<\/code>.<\/p>\n\n\n\n