WordPress: capire perché l’editor blocca i salvataggi

Quando WordPress salva male, il problema quasi mai è “l’editor”

Se l’editor di WordPress non salva, resta in caricamento, mostra un errore generico o perde le modifiche, la causa di solito non è unica. In pratica i guasti più frequenti stanno in uno di questi punti: REST API bloccata, nonce scaduti, conflitti tra plugin, cache aggressiva, permessi file errati, mod_security, limiti PHP o un backend lento che manda in timeout la richiesta.

La chiave è non intervenire a caso. Prima si stabilisce se il salvataggio fallisce per un problema applicativo, HTTP o lato server, poi si applica il fix minimo e reversibile. Questo approccio evita di disattivare mezzo sito senza sapere dove sta il collo di bottiglia.

Sintomi tipici da non ignorare

• Il pulsante di aggiornamento gira all’infinito e poi fallisce.
• Compare un messaggio come “Aggiornamento non riuscito” o “Publishing failed”.
• Il contenuto sembra salvato, ma dopo il refresh torna indietro.
• Alcuni utenti riescono a salvare e altri no.
• Il problema appare solo su pagine molto lunghe, con molti blocchi o immagini.
• Funziona in admin classico ma non nell’editor a blocchi, oppure il contrario.

Se il sito è in produzione e gli editor non riescono a pubblicare, trattalo come un incidente operativo: ogni minuto di attesa può tradursi in contenuti persi o pubblicazioni bloccate.

Diagnosi rapida: da dove partire

La sequenza corretta è semplice: verifica REST API, controlla errori del browser, escludi plugin/cache, poi valuta il server. Se salti questo ordine, rischi di modificare impostazioni che non c’entrano nulla.

1. Verifica la REST API

WordPress usa la REST API per salvare molti contenuti, specialmente nell’editor a blocchi. Se la richiesta verso /wp-json/ fallisce, il salvataggio può andare in errore anche se il sito “sembra” online.

Apri nel browser l’URL:

https://tuodominio.it/wp-json/

Esito atteso: una risposta JSON leggibile, non una pagina 403, 404, 500 o un redirect strano verso login o homepage.

Se ricevi errore, il problema può essere in un plugin di sicurezza, in regole server, in rewrite, in firewall applicativo o in una cache che intercetta richieste dinamiche.

2. Controlla la console del browser

Apri gli strumenti sviluppatore e guarda la scheda Console e Network. Durante il salvataggio cerca errori come:

• 403 Forbidden
• 404 Not Found
• 500 Internal Server Error
• rest_cookie_invalid_nonce
• cURL error o timeout

Esito atteso: la richiesta di salvataggio deve restituire 200 o 201. Se torna 4xx o 5xx, hai già il livello del guasto.

3. Escludi il conflitto più comune: cache e plugin di sicurezza

Molti blocchi di salvataggio nascono da plugin che filtrano troppo aggressivamente REST API, admin-ajax o cookie di autenticazione. Se usi cache lato WordPress, CDN o WAF, verifica che le richieste amministrative non vengano servite come contenuto statico.

Da controllare subito:

• plugin di cache come page cache, object cache o ottimizzatori HTML;
• plugin di sicurezza con regole anti-bot o anti-spam;
• CDN con caching dell’area admin;
• moduli server che bloccano richieste con parametri JSON.

Verifiche immediate da fare prima di toccare altro

1. Prova con un utente amministratore diverso per escludere un problema di sessione o privilegi. Esito atteso: il salvataggio deve funzionare in modo identico per tutti gli admin validi.
2. Apri il sito in finestra anonima e ripeti il salvataggio. Se in anonimo cambia il comportamento, il problema può essere cookie, cache del browser o sessione corrotta.
3. Disattiva temporaneamente la cache della pagina dal pannello del plugin o del CDN, senza cancellare configurazioni permanenti. Esito atteso: l’editor deve tornare a salvare con risposte fresche dal server.
4. Controlla la salute del sito in Strumenti > Stato del sito. Se WordPress segnala REST API, loopback request o errori di configurazione, hai un indizio concreto sul punto guasto.

Se il problema compare solo su articoli lunghi o con molti blocchi, valuta anche la dimensione della richiesta: a volte non è “WordPress rotto”, ma un limite PHP o un reverse proxy che taglia la connessione prima del completamento.

Soluzione consigliata passo-passo

1. Metti in sicurezza il punto di partenza

Prima di cambiare qualcosa, fai un backup rapido di file e database. Se usi cPanel, Plesk o un backup del provider, crea uno snapshot o esporta almeno il database e il file wp-config.php. Questo è il rollback minimo se il fix peggiora la situazione.

Se hai accesso al pannello WordPress, annota anche quali plugin sono attivi e quali impostazioni di cache o sicurezza sono in uso.

2. Verifica e correggi i permessi dei file solo se c’è un indizio concreto

Permessi errati possono impedire il salvataggio di revisioni, media o file temporanei, ma non sono la prima causa in assoluto. Intervieni solo se trovi errori di scrittura nei log o messaggi tipo failed to write file.

Valori normalmente corretti su hosting Linux:

• cartelle: 755
• file: 644
• wp-config.php: spesso più restrittivo, ad esempio 600 o 640 se compatibile con il server

Se usi cPanel o Plesk, il controllo si fa dal file manager. Cerca cartelle impostate a 777 o file con proprietario sbagliato: sono segnali da correggere subito, ma senza cambiare tutto indiscriminatamente.

3. Isola i plugin senza spegnere il sito intero

Se sospetti un conflitto, disattiva prima i plugin più probabili: cache, sicurezza, ottimizzazione, editor, page builder e plugin che modificano REST API o login. Se il sito è sensibile, fallo in manutenzione o su una copia di staging.

Procedura pratica e reversibile:

1. disattiva un solo plugin alla volta;
2. ripeti il salvataggio nell’editor;
3. se il problema sparisce, hai trovato il colpevole o almeno la famiglia di colpevoli;
4. riattiva il resto e verifica che il malfunzionamento non torni.

Se non hai accesso al backend perché l’editor è troppo instabile, la via più rapida è rinominare temporaneamente la cartella del plugin via file manager o FTP. È un fix reversibile, ma va fatto con attenzione per non interrompere plugin critici per il frontend.

4. Controlla i limiti PHP e i timeout

Un salvataggio che fallisce su contenuti grandi può dipendere da limiti troppo bassi. Verifica almeno questi parametri:

• memory_limit
• max_execution_time
• max_input_vars
• post_max_size
• upload_max_filesize

Valori pratici di partenza spesso utili:

• memory_limit almeno 256M, meglio 512M su siti pesanti;
• max_execution_time almeno 120;
• max_input_vars almeno 3000 o più se usi page builder;
• post_max_size coerente con upload e contenuti caricati.

Se modifichi questi valori, fallo dal pannello hosting o dal file di configurazione PHP del dominio, poi verifica con una pagina phpinfo o dal pannello stesso che il valore sia stato applicato davvero.

5. Escludi regole di sicurezza che bloccano l’editor

ModSecurity, WAF del provider, regole del firewall applicativo o filtri del reverse proxy possono bloccare richieste JSON o chiamate all’endpoint di salvataggio. In questi casi il sito non è “giù”, ma una singola richiesta viene respinta.

Indicazioni utili:

• controlla i log del web server o del WAF per richieste bloccate verso /wp-json/, /wp-admin/admin-ajax.php o endpoint correlati;
• verifica se il blocco coincide con un codice 403 o con una regola specifica;
• se disponibile, disabilita temporaneamente la sola regola che colpisce il salvataggio, non tutto il WAF.

Se il provider offre un pannello sicurezza, è preferibile usare il livello GUI per l’eccezione mirata, così riduci il rischio di aprire troppo il sito.

6. Controlla la cache server e la CDN

Una cache configurata male può far vedere all’editor dati vecchi o impedire la corretta autenticazione. L’area amministrativa di WordPress non dovrebbe essere servita come contenuto pubblico e cacheabile.

Controlla che siano esclusi almeno:

• /wp-admin/
• /wp-login.php
• /wp-json/ se il sistema di cache lo richiede;
• cookie di login e sessione.

Se usi CDN, verifica che le pagine amministrative non passino da edge cache. Esito atteso: l’editor deve ricevere risposte dinamiche e corrette per ogni utente autenticato.

7. Se il problema continua, leggi i log giusti

Quando i controlli base non bastano, la prova migliore è il log. Cerca negli errori di PHP, del web server e di WordPress.

File e punti utili:

• wp-content/debug.log se il debug è attivo;
• error log PHP;
• error log di Apache o Nginx;
• eventuali log del WAF o del proxy.

Se vuoi attivare temporaneamente il debug di WordPress, fallo solo per il tempo necessario e poi spegnilo. Un’impostazione possibile nel file wp-config.php è la seguente:

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

Prima modifica fai sempre una copia del file. Esito atteso: il log deve registrare l’errore reale al momento del salvataggio, non generare rumore inutile.

Un caso frequente: REST API bloccata da rewrite o sicurezza

Se /wp-json/ non risponde, il problema può stare nelle regole di riscrittura, nel file .htaccess o in un plugin che altera gli endpoint. In alcuni casi il sito funziona nel frontend ma l’editor fallisce perché la parte editoriale dipende da chiamate AJAX e REST non replicate dalla navigazione normale.

Controlla che il file .htaccess non sia stato alterato in modo anomalo. Se usi Apache e WordPress standard, il blocco base deve essere coerente con quello generato da WordPress. Se ci sono regole custom, verifica che non intercettino le richieste JSON o non riscrivano tutto verso la homepage.

Se il sito usa Nginx, controlla che le location per WordPress non blocchino l’accesso agli endpoint REST. Una configurazione errata può sembrare invisibile finché non si usa l’editor.

Quando il problema è il database, non l’editor

Un salvataggio che fallisce solo su contenuti grandi o in momenti di carico può dipendere da query lente, lock, tabelle con problemi o connessioni instabili a MySQL/MariaDB. In questo caso l’editor invia la richiesta, ma il backend non completa l’operazione in tempo utile.

Segnali utili:

• errori 500 intermittenti;
• salvataggi lenti solo nelle ore di punta;
• log con timeout verso il database;
• sito generalmente lento anche fuori dall’editor.

Verifica se il database è sotto pressione e se il server ha CPU, RAM o I/O saturi. Se il backend è congestionato, il fix non è nel plugin ma nel collo di bottiglia infrastrutturale.

Rollback pratico se un test peggiora la situazione

Ogni test deve essere reversibile. Se dopo aver disattivato un plugin o cambiato un parametro PHP il comportamento peggiora, torna subito allo stato precedente:

• riattiva il plugin disattivato;
• ripristina il valore PHP precedente;
• riabilita la cache solo dopo aver verificato che l’editor salvi correttamente;
• se hai toccato il file .htaccess o le regole Nginx, ripristina la copia di backup.

Il rollback non è una sconfitta: è parte del metodo. In troubleshooting serio, sapere cosa non c’entra vale quasi quanto trovare il colpevole.

Checklist finale rapida

1. La REST API risponde correttamente su /wp-json/.
2. La console del browser non mostra 403, 500 o errori nonce durante il salvataggio.
3. Cache, CDN e plugin di sicurezza escludono l’area admin e le chiamate dinamiche.
4. I limiti PHP sono adeguati al sito e ai contenuti.
5. I log mostrano o escludono con chiarezza il punto di blocco.

Se tutti questi controlli sono in ordine e il problema resta, la probabilità sale su un guasto più specifico del tema, del page builder o del backend applicativo. In quel caso conviene lavorare su staging, con un test per volta e un solo cambiamento alla volta.