{"id":167192,"date":"2025-08-11T09:00:00","date_gmt":"2025-08-11T09:00:00","guid":{"rendered":"https:\/\/gtechgroup.it\/blog\/classic-editor-problemi-comuni-troubleshooting\/"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T22:00:00","slug":"classic-editor-problemi-comuni-troubleshooting","status":"publish","type":"post","link":"https:\/\/gtechgroup.it\/blog\/classic-editor-problemi-comuni-troubleshooting\/","title":{"rendered":"Risolvere i Problemi Comuni di Classic Editor: Troubleshooting"},"content":{"rendered":"

Risolvere i Problemi Comuni di Classic Editor: Troubleshooting<\/h2>\n

Classic Editor è uno dei plugin più stabili e affidabili dell’ecosistema WordPress, ma nessun software è immune da problemi occasionali. Conflitti con altri plugin, configurazioni errate del server, aggiornamenti di WordPress e particolarità dell’hosting possono causare comportamenti inaspettati. In questa guida completa al troubleshooting, analizzeremo i problemi più comuni riscontrati dagli utenti di Classic Editor e forniremo soluzioni dettagliate e testate per ciascuno di essi.<\/p>\n

Problema 1: Classic Editor Non Sostituisce Gutenberg<\/h2>\n

Uno dei problemi più segnalati è che, nonostante Classic Editor sia installato e attivato, Gutenberg continua ad apparire quando si crea o modifica un articolo. Le cause possono essere diverse.<\/p>\n

Verifica l’attivazione<\/strong>: vai su Plugin > Plugin Installati<\/strong> e controlla che Classic Editor sia effettivamente attivo (non solo installato). Può sembrare banale, ma è la causa più frequente di questo problema.<\/p>\n

Controlla le impostazioni<\/strong>: vai su Impostazioni > Scrittura<\/strong> e verifica che “Editor Classico” sia selezionato come editor predefinito. Se l’opzione “Consenti agli utenti di cambiare editor” è attiva, controlla anche le impostazioni nel tuo profilo utente (Utenti > Il tuo profilo<\/strong>) per assicurarti che non sia selezionato “Editor a blocchi” come preferenza personale.<\/p>\n

Plugin in conflitto<\/strong>: altri plugin che interagiscono con l’editor potrebbero interferire con Classic Editor. Plugin come “Disable Gutenberg”, “Gutenberg” (il plugin che installa versioni sperimentali dell’editor a blocchi) o plugin di page builder potrebbero sovrascrivere le impostazioni di Classic Editor. Disattiva temporaneamente tutti i plugin tranne Classic Editor e verifica se il problema persiste. Se si risolve, riattiva i plugin uno alla volta per identificare quello in conflitto.<\/p>\n

\"Verifica<\/p>\n

Problema 2: La Barra degli Strumenti Non Appare<\/h2>\n

Se l’editor classico si carica ma la barra degli strumenti di TinyMCE non appare o appare incompleta, il problema è quasi sempre legato a un conflitto JavaScript o a file corrotti nella cache.<\/p>\n

Svuota la cache del browser<\/strong>: premi Ctrl+Shift+Delete (o Cmd+Shift+Delete su Mac), seleziona “Cache e file temporanei” e svuota. Ricarica la pagina con Ctrl+F5 per forzare il caricamento di tutti gli asset da zero.<\/p>\n

Controlla la console del browser<\/strong>: apri gli strumenti per sviluppatori del browser (F12), vai alla scheda “Console” e cerca errori JavaScript in rosso. Gli errori più comuni sono file JS che non si caricano (errore 404) o conflitti tra script. Se vedi un errore specifico, cerca il nome del file o del plugin responsabile per identificare la causa.<\/p>\n

Verifica i permessi dei file<\/strong>: TinyMCE richiede che i suoi file JavaScript siano leggibili dal web server. Controlla i permessi della directory wp-includes\/js\/tinymce\/<\/code> e assicurati che i file abbiano permessi 644 e le directory 755. Se i permessi sono sbagliati, correggili tramite FTP o SSH.<\/p>\n

Plugin di ottimizzazione<\/strong>: plugin di caching e ottimizzazione come WP Rocket, W3 Total Cache, Autoptimize o LiteSpeed Cache possono minificare e combinare i file JavaScript in modo da causare conflitti con TinyMCE. Se usi uno di questi plugin, prova a escludere i file di TinyMCE dalla minificazione o a disabilitare temporaneamente la minificazione JS nel backend.<\/p>\n

Problema 3: L’Editor è Vuoto o Mostra Solo HTML<\/h2>\n

Se l’editor mostra un’area bianca vuota o visualizza il codice HTML grezzo invece dell’interfaccia visuale, ci sono diverse possibili cause.<\/p>\n

Modalità Testo attiva<\/strong>: verifica di non essere nella scheda “Testo” dell’editor. Se vedi i tag HTML, clicca sulla scheda “Visuale” per tornare all’editor WYSIWYG. WordPress ricorda l’ultima scheda utilizzata, quindi se hai usato la modalità Testo nell’ultima sessione, si riaprirà in quella modalità.<\/p>\n

Errore di inizializzazione di TinyMCE<\/strong>: se l’area dell’editor è completamente vuota (né visuale né testo), TinyMCE potrebbe non riuscire a inizializzarsi. Controlla la console del browser per errori JavaScript. Un errore frequente è “tinyMCE is not defined”, che indica che il file core di TinyMCE non è stato caricato correttamente.<\/p>\n

Conflitto con editor multipli<\/strong>: se la pagina contiene più istanze di TinyMCE (ad esempio, l’editor principale più un campo WYSIWYG di ACF), un conflitto nell’inizializzazione può causare il mancato rendering di uno o più editor. Questo è un problema noto e generalmente si risolve aggiornando ACF e Classic Editor alle ultime versioni.<\/p>\n

\"Editor<\/p>\n

Problema 4: Impossibile Inserire Immagini o Media<\/h2>\n

Se il pulsante “Aggiungi media” non funziona, la finestra della libreria media non si apre o le immagini non vengono inserite nell’editor, il problema è spesso legato a JavaScript o alla configurazione del server.<\/p>\n

Errore JavaScript nella libreria media<\/strong>: la libreria media di WordPress utilizza JavaScript complesso (Backbone.js) che può entrare in conflitto con script di altri plugin. Controlla la console del browser quando clicchi su “Aggiungi media” per identificare eventuali errori.<\/p>\n

Limiti di upload<\/strong>: se puoi aprire la libreria media ma non caricare file, il problema potrebbe essere un limite di upload del server. Controlla i valori di upload_max_filesize<\/code> e post_max_size<\/code> nel file php.ini<\/code> o nella pagina Strumenti > Salute del sito > Info > Server<\/strong>. Se i limiti sono troppo bassi, aumentali tramite il pannello di controllo del tuo hosting o contatta il supporto.<\/p>\n

Permessi della cartella uploads<\/strong>: la directory wp-content\/uploads\/<\/code> deve avere permessi 755 e essere scrivibile dal web server. Se i permessi sono sbagliati, WordPress non può salvare i file caricati e l’inserimento nell’editor fallisce silenziosamente.<\/p>\n

Problema 5: Formattazione Persa o Modificata<\/h2>\n

Un problema frustrante è la perdita o la modifica della formattazione quando si salva un articolo o si passa tra le modalità Visuale e Testo dell’editor.<\/p>\n

wpautop e il passaggio tra modalità<\/strong>: WordPress applica la funzione wpautop<\/code> che aggiunge automaticamente tag <p><\/code> e converte le interruzioni di riga in <br><\/code>. Questo può causare formattazione indesiderata, specialmente per contenuti con HTML personalizzato. Se usi TinyMCE Advanced, attiva l’opzione “Mantieni i tag paragrafo” per prevenire queste conversioni automatiche.<\/p>\n

Tag HTML rimossi<\/strong>: WordPress e TinyMCE filtrano alcuni tag HTML considerati non sicuri o non necessari. Se inserisci tag come <iframe><\/code>, <script><\/code> o attributi come onclick<\/code> nella modalità Testo, potresti trovarli rimossi quando torni alla modalità Visuale. Questo è un comportamento di sicurezza deliberato. Per consentire tag aggiuntivi, usa il filtro tiny_mce_before_init<\/code> con l’opzione extended_valid_elements<\/code>.<\/p>\n

Ruolo utente e kses<\/strong>: WordPress applica il filtro wp_kses<\/code> quando utenti con ruoli inferiori all’amministratore salvano contenuti. Questo filtro rimuove tag HTML potenzialmente pericolosi. Se un autore o un redattore lamenta la perdita di formattazione, verifica che il contenuto non contenga tag che vengono filtrati da kses per il suo ruolo.<\/p>\n

Problema 6: Classic Editor Lento o che Si Blocca<\/h2>\n

Se l’editor classico è lento nel caricamento o si blocca durante l’editing, il problema è raramente causato da Classic Editor stesso (che è molto leggero) e più probabilmente da fattori esterni.<\/p>\n

Articoli con molto contenuto<\/strong>: articoli molto lunghi (oltre 10.000 parole) con molte immagini possono rallentare TinyMCE perché tutto il contenuto viene caricato nell’editor DOM. Se lavori regolarmente con contenuti molto lunghi, considera di dividerli in più pagine usando il tag <!--nextpage--><\/code>.<\/p>\n

Troppe metabox<\/strong>: ogni metabox nella pagina di editing aggiunge peso al DOM e richiede il caricamento di CSS e JavaScript aggiuntivi. Se hai molti plugin che aggiungono metabox, la pagina di editing può diventare lenta. Usa la scheda “Impostazioni schermo” (in alto a destra nella pagina di editing) per nascondere le metabox che non utilizzi regolarmente.<\/p>\n

Salvataggio automatico<\/strong>: WordPress salva automaticamente i contenuti ogni 60 secondi. Su server lenti o con connessioni instabili, questo salvataggio automatico può causare blocchi temporanei dell’editor. Puoi aumentare l’intervallo di autosalvataggio aggiungendo nel wp-config.php<\/code>: define(AUTOSAVE_INTERVAL, 300);<\/code> (300 secondi = 5 minuti).<\/p>\n

\"Diagnostica<\/p>\n

Problema 7: Incompatibilità dopo un Aggiornamento di WordPress<\/h2>\n

Dopo un aggiornamento major di WordPress, Classic Editor potrebbe temporaneamente non funzionare correttamente. Questo è raro ma possibile, specialmente con aggiornamenti che modificano significativamente il backend.<\/p>\n

Aggiorna Classic Editor<\/strong>: controlla se è disponibile un aggiornamento di Classic Editor. Il team WordPress rilascia aggiornamenti di compatibilità in concomitanza con le nuove versioni del core.<\/p>\n

Verifica la versione di PHP<\/strong>: gli aggiornamenti di WordPress possono richiedere versioni di PHP più recenti. Controlla che il tuo server utilizzi almeno PHP 7.4 (consigliato PHP 8.0 o superiore nel 2026). Versioni di PHP obsolete possono causare errori inattesi con WordPress e i suoi plugin.<\/p>\n

Rigenera i permalink<\/strong>: vai su Impostazioni > Permalink<\/strong> e clicca su “Salva le modifiche” senza cambiare nulla. Questa operazione rigenera il file .htaccess<\/code> e può risolvere problemi di routing che influenzano il caricamento dell’editor.<\/p>\n

Problema 8: L’Editor Non Si Carica su Hosting Condiviso<\/h2>\n

Su hosting condivisi con risorse limitate, l’editor classico potrebbe non caricarsi completamente o mostrare una pagina bianca. Le cause più comuni sono il limite di memoria PHP e il timeout di esecuzione.<\/p>\n

Aumenta il limite di memoria PHP<\/strong>: aggiungi define(WP_MEMORY_LIMIT, 256M);<\/code> al file wp-config.php<\/code>. Questo imposta il limite di memoria di WordPress a 256 MB. Se il tuo hosting lo permette, puoi anche aumentare il valore nel php.ini<\/code> con memory_limit = 256M<\/code>.<\/p>\n

Aumenta il tempo di esecuzione<\/strong>: se la pagina va in timeout, puoi aumentare il tempo massimo di esecuzione PHP aggiungendo max_execution_time = 120<\/code> nel php.ini<\/code> o nel file .htaccess<\/code> con la direttiva php_value max_execution_time 120<\/code>.<\/p>\n

Problema 9: Contenuti Gutenberg in Classic Editor<\/h2>\n

Se apri un articolo creato con Gutenberg in Classic Editor, vedrai i commenti HTML dei blocchi (come <!-- wp:paragraph --><\/code>) nel codice sorgente. Questo non è un bug ma il comportamento previsto. Questi commenti non sono visibili nel front-end e non influenzano la visualizzazione dell’articolo per i visitatori.<\/p>\n

Se vuoi rimuoverli, puoi farlo manualmente nella modalità Testo dell’editor, cercando e cancellando i commenti che iniziano con <!-- wp:<\/code>. Per operazioni massive, puoi usare un plugin come “Classic Editor Addon” che rimuove automaticamente i commenti dei blocchi quando un articolo viene salvato con Classic Editor. In alternativa, una query SQL può pulire il campo post_content<\/code> di tutti i post in una sola operazione, ma esegui sempre un backup completo del database prima.<\/p>\n

Strumenti di Diagnostica<\/h2>\n

WordPress offre diversi strumenti integrati per la diagnostica dei problemi. La pagina Strumenti > Salute del sito<\/strong> esegue una serie di controlli automatici e segnala problemi di configurazione, sicurezza e performance. Controlla questa pagina regolarmente e risolvi tutti i problemi segnalati come “critici” o “consigliati”.<\/p>\n

Il file debug.log<\/code> è un’altra risorsa preziosa. Abilita il debug logging aggiungendo al wp-config.php<\/code>: define(WP_DEBUG, true); define(WP_DEBUG_LOG, true); define(WP_DEBUG_DISPLAY, false);<\/code>. Gli errori verranno salvati nel file wp-content\/debug.log<\/code> senza essere mostrati ai visitatori. Controlla questo file per errori PHP che potrebbero influenzare il funzionamento dell’editor. Ricorda di disattivare il debug in produzione una volta risolto il problema.<\/p>\n

\"Plugin<\/p>\n

Quando Contattare il Supporto<\/h2>\n

Se hai provato tutte le soluzioni elencate e il problema persiste, potrebbe essere il momento di contattare il supporto. Per problemi specifici di Classic Editor, puoi aprire una discussione nel forum di supporto del plugin su wordpress.org. Includi sempre: la versione di WordPress, la versione di Classic Editor, la versione di PHP, il nome del tema attivo, la lista dei plugin attivi e una descrizione dettagliata del problema con screenshot.<\/p>\n

Per problemi legati al server (memoria, timeout, permessi), contatta il supporto del tuo hosting provider. Per problemi legati a conflitti con plugin specifici, contatta lo sviluppatore del plugin in conflitto.<\/p>\n

Conclusioni<\/h2>\n

La maggior parte dei problemi con Classic Editor ha soluzioni semplici e ben documentate. La chiave è procedere sistematicamente: identificare il sintomo, isolare la causa (server, plugin, tema, configurazione) e applicare la soluzione appropriata. Con le tecniche di troubleshooting descritte in questa guida, sarai in grado di risolvere la stragrande maggioranza dei problemi autonomamente.<\/p>\n

Ricorda sempre di lavorare su un backup recente quando effettui modifiche alla configurazione del sito, e di testare le soluzioni in un ambiente di staging prima di applicarle al sito in produzione.<\/p>\n

\n

Leggi anche gli altri articoli della serie Classic Editor<\/h3>\n