L’editor WordPress non funziona: può aprirsi vuoto, restare in caricamento, perdere pulsanti oppure impedire il salvataggio con un errore. Questi sintomi non indicano tutti la stessa causa. Prima di disattivare plugin o modificare il server, conviene capire dove si interrompe il flusso tra browser, editor a blocchi e WordPress.
Questa guida propone una diagnosi ordinata di Gutenberg. Si parte dalle verifiche reversibili e dalle evidenze disponibili, poi si isolano REST API, permessi, plugin, tema, cache, firewall e ambiente server. L’obiettivo non è provare soluzioni a caso, ma restringere il problema senza introdurre nuovi errori.
In breve: cosa controllare quando l’editor WordPress non funziona
Prima di intervenire, verifica nell’ordine:
- se il problema riguarda un solo browser, utente, contenuto o tutto il sito;
- quale operazione fallisce: apertura, inserimento dei blocchi, caricamento dei media o salvataggio;
- gli errori nelle schede Console e Rete degli strumenti per sviluppatori del browser;
- lo stato della REST API in Strumenti → Salute del sito;
- le modifiche recenti a plugin, tema, WordPress, PHP, cache, CDN o firewall;
- i log PHP e del server, usando un ambiente di staging quando serve un test invasivo;
- che la correzione funzioni anche dopo logout, nuovo accesso e svuotamento delle cache.
Conserva screenshot, orario dell’errore, URL del contenuto e messaggio completo. Sono dettagli molto più utili di una descrizione generica come “Gutenberg è rotto”.
Identifica il sintomo prima di cercare la soluzione
Il primo passaggio consiste nel delimitare il guasto. Una schermata bianca durante l’apertura suggerisce un percorso diverso da un errore che compare soltanto quando si salva.
| Sintomo | Primi controlli utili | Area probabile |
|---|---|---|
| Editor vuoto o caricamento infinito | Console, file JavaScript, richieste bloccate | Browser, plugin, tema, cache |
| “Aggiornamento fallito” o risposta JSON non valida | Scheda Rete, REST API, codice HTTP e corpo della risposta | REST API, autenticazione, redirect, firewall, server |
| Blocchi o pannelli mancanti | Preferenze dell’editor, ruolo utente, plugin che modifica Gutenberg | Configurazione o permessi |
| Il problema riguarda un solo articolo | Blocchi non validi, shortcode, pattern o contenuti incorporati | Contenuto specifico |
| Funziona in incognito o con un altro browser | Estensioni, cache, cookie, profilo del browser | Client locale |
| Anche sito e wp-admin mostrano errori | Log PHP, hosting, database, aggiornamenti recenti | Problema generale di WordPress |
Quando l’intero sito o l’amministrazione non sono raggiungibili, la guida sul sito WordPress bloccato descrive un percorso più adatto. Se invece il problema riguarda esclusivamente il page builder, consulta i controlli specifici per Elementor che non carica. Qui ci concentriamo sull’editor a blocchi nativo.
Prima della diagnosi: proteggi il sito e raccogli le evidenze
Annota cosa è cambiato subito prima del malfunzionamento: aggiornamento automatico, nuovo plugin, modifica al tema, cambio di PHP, migrazione, attivazione di una CDN o nuova regola di sicurezza. La sequenza temporale non dimostra la causa, ma stabilisce quali verifiche hanno maggiore priorità.
Evita di aggiornare altri componenti “per provare” e non disattivare in massa plugin su un sito operativo senza backup. La documentazione ufficiale sul debug di WordPress raccomanda un ambiente di staging o un backup adeguato prima delle modifiche. Inoltre sconsiglia di mostrare gli errori di debug sul sito pubblico.
1. Capisci l’estensione del problema
Esegui quattro prove semplici, senza cambiare la configurazione:
- apri un altro articolo o una nuova bozza;
- prova con un secondo utente dotato di ruolo adeguato;
- usa una finestra privata o un browser differente;
- controlla frontend e altre pagine di wp-admin.
Se fallisce un solo contenuto, sospetta un blocco, uno shortcode o un dato specifico. Se fallisce un solo utente, controlla capacità, sessione e preferenze. Se il difetto scompare in incognito, indaga estensioni, cookie e cache del browser. Un errore riprodotto da tutti gli utenti e su più contenuti sposta invece l’attenzione verso WordPress o il server.
2. Se l’editor WordPress non funziona, controlla Console e Rete
Apri gli strumenti per sviluppatori del browser, ricarica l’editor e ripeti l’azione che fallisce. Nella Console cerca il primo errore JavaScript rilevante, non soltanto l’ultimo messaggio. Nella scheda Rete filtra le richieste fetch/XHR e osserva quelle verso wp-json.
Registra URL, metodo, codice HTTP e risposta. Un 401 o 403 orienta verso autenticazione, nonce, permessi o regole di sicurezza. Un 404 può indicare un problema di percorso o riscrittura. Un 500 richiede i log server. Un 502 o 504 rimanda a un servizio a monte o a un timeout. Una risposta HTML quando l’editor attende JSON può essere una pagina di login, un redirect, una pagina di errore o il blocco di un WAF.
Non pubblicare screenshot che contengono cookie, nonce, indirizzi interni o altri dati sensibili. Per l’assistenza basta condividere le informazioni necessarie a riprodurre il problema.
3. Verifica REST API e Salute del sito
L’editor a blocchi è un’applicazione JavaScript che scambia dati con WordPress. Il manuale ufficiale della REST API conferma che le risposte vengono restituite in JSON e cita proprio il block editor tra le applicazioni client-side che usano questa interfaccia.
Vai in Strumenti → Salute del sito → Stato e controlla gli avvisi relativi alla REST API, alle richieste HTTP e ai loopback. Nella scheda Informazioni puoi raccogliere dati su WordPress, plugin, tema, server e database. La documentazione di Salute del sito chiarisce che questa schermata espone informazioni tecniche e test divisi per gravità, ma non modifica direttamente le impostazioni.
Un test REST superato non esclude qualsiasi problema: l’errore potrebbe riguardare un endpoint specifico, una particolare operazione di scrittura o soltanto la richiesta generata da quel contenuto. Per questo Console, Rete e log devono essere letti insieme.
4. Controlla permessi, sessione e configurazione dell’utente
Quando Gutenberg si apre ma alcune azioni sono assenti o il salvataggio è negato, verifica ruolo e capacità dell’account. Esci da WordPress, cancella i cookie del dominio e accedi di nuovo: una sessione scaduta o incoerente può produrre richieste non autorizzate.
Confronta il comportamento con un secondo account autorizzato. Se il problema resta confinato a un utente, non ha senso iniziare dalla sostituzione del tema o dalla configurazione PHP. Controlla anche le preferenze dell’editor: un pannello nascosto non equivale a una funzionalità guasta.
5. Isola plugin e tema senza procedere alla cieca
Un conflitto può introdurre errori JavaScript, modificare gli endpoint REST, alterare i permessi o interrompere l’esecuzione PHP. Inizia dal componente modificato più vicino all’orario del guasto. Prima di disattivarlo, verifica che il sito disponga di un backup e che il test non interrompa funzioni essenziali.
Su un sito aziendale o e-commerce, riproduci preferibilmente il problema in staging. Disattiva un elemento alla volta e ripeti sempre lo stesso test. Se l’editor torna a funzionare, riattiva il componente per confermare la relazione e conserva l’errore originale. La semplice coincidenza dopo una disattivazione non basta: cache o sessione potrebbero aver falsato il risultato.
Per il tema vale lo stesso metodo: il passaggio temporaneo a un tema predefinito serve come test di isolamento, non come soluzione definitiva. Prima di farlo sul sito pubblico valuta menu, widget, template e funzioni personalizzate che potrebbero cambiare.
6. Verifica cache, CDN, ottimizzazioni e firewall
Cache del browser, plugin di ottimizzazione, cache server e CDN possono consegnare file JavaScript non coerenti dopo un aggiornamento. Svuota un livello alla volta e ripeti il test con una ricarica completa, così saprai quale intervento ha inciso.
Se minificazione, combinazione o caricamento differito degli script sono attivi anche nell’area amministrativa, disabilitali temporaneamente in staging o escludi gli URL di wp-admin secondo la documentazione dello strumento. Per WAF e plugin di sicurezza, usa il codice della richiesta e l’orario per consultare i log: disattivare tutta la protezione è una prova più rischiosa e meno informativa.
7. Leggi i log WordPress, PHP e server
Quando la richiesta restituisce 500, timeout o una risposta incompleta, i log sono il punto decisivo. La documentazione WordPress spiega che WP_DEBUG_LOG, insieme a WP_DEBUG, può registrare errori in wp-content/debug.log; WP_DEBUG_DISPLAY può essere disattivato per non mostrare dettagli ai visitatori. Queste impostazioni richiedono competenza e non dovrebbero restare attive inutilmente in produzione.
Allinea il timestamp del log con l’azione eseguita nell’editor. Cerca errori fatali, memoria esaurita, funzioni o classi mancanti, eccezioni, timeout e risposte bloccate dal server. I log dell’hosting, PHP-FPM, web server e firewall possono contenere informazioni che WordPress non registra.
8. L’editor WordPress non funziona su un solo contenuto
Se altri articoli si aprono e si salvano, evita una diagnosi generale del server. Quando l’editor WordPress non funziona soltanto su una pagina, duplica il contenuto in staging o crea una copia di prova, poi individua il blocco che scatena l’errore. Shortcode complessi, HTML personalizzato, embed, pattern sincronizzati o metadati aggiunti da un plugin possono coinvolgere richieste diverse rispetto a una bozza vuota.
Il messaggio “Questo blocco contiene contenuto inatteso o non valido” è un caso specifico: WordPress mette a disposizione opzioni di risoluzione o conversione del singolo blocco. Non va confuso con l’intero editor bianco o con un salvataggio REST fallito. Prima di usare “Tenta il recupero del blocco”, conserva una copia del contenuto.
Come verificare che l’editor WordPress sia davvero ripristinato
La scomparsa del messaggio non conclude la diagnosi. Esegui un collaudo minimo:
- apri un contenuto esistente e una nuova bozza;
- inserisci, sposta ed elimina un blocco;
- carica un’immagine di prova quando pertinente;
- salva la bozza e ricarica la pagina;
- controlla revisioni, anteprima e permalink;
- ripeti il test con l’utente che aveva segnalato il problema;
- svuota le cache interessate e verifica nuovamente;
- controlla che frontend e funzioni critiche non abbiano subito regressioni.
Infine documenta causa, correzione, componenti coinvolti e procedura di rollback. Questo passaggio trasforma un intervento isolato in una misura utile per prevenire recidive.
Quando chiedere assistenza per Gutenberg
Conviene fermarsi quando il test richiede modifiche a produzione, credenziali server, accesso ai log, interventi su database o esclusioni del firewall che non sai valutare. È opportuno chiedere supporto anche quando il sito gestisce ordini, lead o contenuti aggiornati da più persone: una prova non controllata può avere un costo superiore al malfunzionamento iniziale.
BNZ Solutions offre consulenza e assistenza WordPress per analizzare conflitti, REST API, log, cache e configurazione hosting con priorità chiare. Per una valutazione, prepara URL interessato, sintomo, orario, modifiche recenti, screenshot e risultati delle prove già eseguite.
Domande frequenti sull’editor WordPress che non funziona
Perché Gutenberg mostra una schermata bianca?
Una schermata bianca nell’editor può dipendere da un errore JavaScript, una risorsa non caricata, un conflitto di plugin o tema, una risposta REST errata oppure un problema server. Console e Rete del browser aiutano a scegliere il percorso diagnostico corretto.
Cosa significa “La risposta non è una risposta JSON valida”?
Significa che l’editor non ha ricevuto la risposta JSON attesa. La causa può essere un errore o redirect del server, un blocco del firewall, un problema di autenticazione, REST API o riscrittura degli URL. Il corpo e il codice HTTP della richiesta fallita sono più utili di una soluzione generica.
Devo disattivare tutti i plugin?
Non come prima mossa su un sito in produzione. Raccogli le evidenze, considera le modifiche recenti e testa in staging un componente alla volta. Se devi intervenire sul sito pubblico, predisponi backup e rollback e valuta l’impatto delle funzioni che stai disattivando.
Passare all’editor classico risolve il problema?
Può aggirare temporaneamente alcuni sintomi o aiutare a delimitare il problema, ma non dimostra che Gutenberg sia la causa. Se REST API, plugin, server o permessi restano difettosi, il malfunzionamento può ricomparire altrove. Usa l’editor classico come test o soluzione temporanea motivata, non come sostituto della diagnosi.
