Apri una pagina per modificarla e la rotellina di Elementor gira all’infinito. Oppure l’editor si apre ma il pannello dei widget resta vuoto. Oppure salvi, ricarichi il sito e il layout è saltato.
Sono tre guasti diversi, con cause diverse, e questa è la parte che quasi tutte le guide saltano: propongono venti soluzioni da provare in sequenza, sperando che una funzioni. Partire dal sintomo restringe il campo in pochi minuti, e nella maggior parte dei casi evita del tutto la fase dei tentativi.
In breve
Quando Elementor non funziona la causa è quasi sempre una tra quattro: memoria PHP insufficiente, conflitto con un altro plugin o con il tema, cache e ottimizzazione che alterano i file dell’editor, o disallineamento tra versione gratuita e Pro. Il pannello Elementor, Informazioni di sistema dice già in quale delle quattro ti trovi.
Prima domanda: cosa esattamente non funziona
Elementor si rompe in modi riconoscibili. Individuare il modo esatto è metà della diagnosi.
| Sintomo | Causa più probabile |
|---|---|
| L’editor resta sulla schermata di caricamento | Memoria PHP esaurita o conflitto tra plugin |
| L’editor si apre ma il pannello dei widget è vuoto | Conflitto con un addon o con un plugin di sicurezza |
| Le modifiche non si salvano | Timeout del server o firewall che blocca la richiesta |
| Il sito cambia aspetto dopo il salvataggio | File CSS generati in modo incompleto |
| Il layout si rompe solo su mobile | Impostazioni responsive, non un guasto tecnico |
| Pagina bianca al posto dell’editor | Errore fatale di PHP |
L’ultima riga merita una precisazione. Se al posto dell’editor compare una pagina completamente bianca o il messaggio di errore critico, il problema ha superato Elementor e riguarda WordPress: in quel caso la strada giusta è quella descritta nella guida su come identificare la causa di un errore 500, perché serve leggere il log.
Il pannello che sa già la risposta
Prima di toccare qualsiasi impostazione, vai in Elementor, Informazioni di sistema. È una schermata che quasi nessuno apre e che contiene esattamente i dati che servono.
Tre valori in particolare.
- Limite di memoria PHP. Elementor indica 128 MB come minimo, ma su un sito con tema e addon la soglia realistica è 256 MB, e la documentazione consiglia 512 MB per lavorare senza attriti. Sotto i 128 MB l’editor si blocca in caricamento con regolarità.
- Tempo massimo di esecuzione. Se è basso, il salvataggio di pagine complesse va in timeout a metà. Il valore di riferimento indicato da Elementor è 300 secondi.
- Versioni di Elementor ed Elementor Pro. Devono essere allineate. È una causa di malfunzionamento tanto banale quanto frequente, perché aggiornare solo uno dei due è facilissimo.
Se Pro è aggiornato e la versione gratuita no, o viceversa, aspettati comportamenti strani. Allinea le versioni prima di cercare altrove.
I cinque sintomi e cosa indicano
1. L’editor resta sulla schermata di caricamento
È il caso più comune e quello che genera più ricerche. Elementor stesso attribuisce buona parte di questi blocchi ai conflitti tra plugin, ma la memoria insufficiente è altrettanto frequente sui piani condivisi.
Ordine di verifica: prima guarda il limite di memoria nelle informazioni di sistema, poi disattiva gli addon di Elementor uno alla volta, poi gli altri plugin. Gli addon vengono prima perché toccano lo stesso codice dell’editor, quindi hanno più probabilità di entrare in conflitto.
Se il limite è basso, puoi provare ad alzarlo aggiungendo in wp-config.php, sopra la riga che dice di non modificare oltre:
define( 'WP_MEMORY_LIMIT', '256M' );Vale la stessa avvertenza di sempre: su molti hosting condivisi il tetto è imposto a monte e questa riga viene ignorata. Torna nelle informazioni di sistema dopo la modifica e verifica se il valore è cambiato davvero.
2. L’editor si apre ma i widget non compaiono
Il pannello laterale resta vuoto o continua a caricare. Qui la memoria c’entra poco: il problema è che qualcosa blocca il caricamento delle risorse dell’editor.
I sospetti in ordine sono i plugin di sicurezza con firewall aggressivo, che scambiano le richieste di Elementor per traffico sospetto, e gli addon di terze parti incompatibili con la versione installata. Se usi un plugin firewall, la verifica più rapida è disattivarlo per due minuti e riaprire l’editor.
3. Le modifiche non si salvano
Clicchi Aggiorna, la rotellina gira e poi compare un errore, oppure non succede niente. Nella maggior parte dei casi la richiesta parte ma non arriva a destinazione.
Le cause tipiche sono tre: tempo di esecuzione PHP troppo basso per pagine pesanti, un firewall che blocca le richieste con molti dati, oppure una discrepanza tra l’indirizzo WordPress e l’indirizzo del sito nelle impostazioni generali, che manda le chiamate dell’editor a un URL diverso da quello atteso. Quest’ultima è rara ma diabolica, perché tutto il resto del sito continua a funzionare.
4. Il sito cambia aspetto dopo il salvataggio
Le modifiche ci sono nell’editor ma il sito pubblico le mostra male, oppure sparisce parte della formattazione. Elementor genera file CSS separati per ogni pagina, e quando quei file restano incompleti o obsoleti il risultato è esattamente questo.
La soluzione è in Elementor, Strumenti: rigenera CSS e dati. È un’operazione sicura, che ricostruisce i file di stile senza toccare i contenuti. Se dopo la rigenerazione il problema resta, il sospetto passa alla cache, e ne parlo tra due sezioni.
5. Il layout si rompe solo su mobile
Questo caso non è un guasto e va detto chiaramente, perché chi cerca un problema responsive di Elementor spesso sta cercando la soluzione sbagliata.
Elementor permette di impostare valori diversi per desktop, tablet e mobile su quasi ogni proprietà. Quando un elemento si comporta male sul telefono, quasi sempre è perché ha un valore fisso ereditato dal desktop: una larghezza in pixel invece che in percentuale, un padding pensato per uno schermo largo, un’altezza minima che su mobile taglia il contenuto.
Il metodo è entrare nella vista mobile dell’editor e correggere lì i valori, ricordando che le modifiche fatte in vista desktop scendono a cascata su tutti i dispositivi, mentre quelle fatte in vista mobile restano solo su mobile. È la logica che spiega il novanta per cento dei layout che saltano sul telefono.
Le due impostazioni che risolvono più casi di quanto sembri
Ci sono due comandi dentro Elementor che meritano di essere provati prima di qualunque disattivazione a tappeto.
Il primo è il metodo di caricamento dell’editor, in Elementor, Impostazioni, scheda Avanzate. Cambiando quell’opzione, Elementor carica l’editor in un modo alternativo che aggira una serie di conflitti con temi e server. È un interruttore, si prova in dieci secondi, e su un numero sorprendente di siti bloccati in caricamento è tutto quello che serve.
Il secondo è la rigenerazione di CSS e dati, in Elementor, Strumenti. Serve per i problemi di aspetto ma vale la pena eseguirla anche dopo aver risolto qualsiasi altra cosa, perché rimette in ordine file che potrebbero essere rimasti a metà.
Cloudflare e i plugin di ottimizzazione
Questa è la causa che quasi nessuno sospetta, e che sui siti curati bene è tra le più frequenti proprio perché quei siti hanno l’ottimizzazione attiva.
Elementor ha bisogno di caricare i propri script nell’ordine e nella forma in cui li ha scritti. Le funzioni che li riscrivono lo mandano in crisi. I responsabili tipici sono la minificazione e la combinazione dei file JavaScript nei plugin di cache, il caricamento differito degli script, e su Cloudflare la funzione Rocket Loader, che riordina l’esecuzione del JavaScript e blocca l’editor con una certa regolarità.
Il test è netto: svuota la cache, disattiva temporaneamente ottimizzazione e Rocket Loader, riapri l’editor. Se funziona, hai trovato il colpevole e da lì si lavora di esclusioni, escludendo le pagine dell’editor dall’ottimizzazione invece di rinunciarci del tutto.
Un dettaglio che fa perdere ore. Dopo aver disattivato la cache, ricarica l’editor con una finestra in incognito o svuota la cache del browser. Capita spesso di credere che il problema persista quando in realtà si sta guardando una copia vecchia della pagina.
Isolare il conflitto senza rompere il sito ai visitatori
Il metodo classico prevede di disattivare tutti i plugin e riattivarli uno alla volta. Funziona, ma mentre lo fai chi visita il sito lo vede incompleto.
Il plugin ufficiale Health Check & Troubleshooting risolve il problema: la sua modalità di risoluzione disattiva plugin e tema solo per la tua sessione del browser, lasciando il sito intatto per tutti gli altri. Ho spiegato come si usa nella guida sull’errore 500, e la procedura è identica anche qui.
Aggiungo un passaggio specifico per Elementor: nel test, passa temporaneamente al tema Hello Elementor. È il tema minimale sviluppato da Elementor stesso, senza stili né script propri, quindi esclude in un colpo solo tutte le interferenze del tema. Se con Hello l’editor funziona, sai dove guardare.
Quando il limite è il piano hosting
C’è uno scenario in cui puoi provare tutto quello che c’è scritto sopra senza risultato, perché il problema è a monte.
Il segnale è che l’editor funziona a volte sì e a volte no, o che si blocca solo sulle pagine più complesse. Elementor è un plugin esigente: costruisce l’anteprima, salva strutture di dati articolate e nel farlo consuma risorse. Su un piano condiviso entry level, dimensionato per siti vetrina, quelle risorse a volte non ci sono, e non c’è impostazione che le crei.
Se il valore della memoria non cambia nemmeno dopo aver modificato wp-config.php, il tetto è imposto dall’hosting e la decisione diventa un’altra. Nel confronto tra gli hosting condivisi per WordPress ho messo i criteri per capire se il piano attuale regge quello che il sito è diventato.
Discorso a parte per la lentezza. Se Elementor funziona ma il sito pubblico carica piano, non è un guasto: è il peso della struttura, e si affronta con la logica descritta nella guida su cosa rallenta davvero un sito WordPress.
Quando conviene fermarsi
Gran parte di questo percorso richiede pazienza più che competenze: alzare un limite, provare un interruttore, disattivare un plugin alla volta.
Due situazioni cambiano il conto. La prima è quando il sito è in produzione e genera contatti o vendite, perché ogni tentativo fatto sul sito vero è un rischio e andrebbe fatto su una copia. La seconda è quando il conflitto coinvolge codice personalizzato, un tema figlio o un addon fatto su misura, perché lì la disattivazione a tappeto non basta: serve leggere cosa sta succedendo.
Elementor continua a non partire?
Quando il sintomo non rientra in nessuno dei casi qui sopra, o quando torna dopo essere stato risolto, di solito significa che la causa è più a monte di Elementor. In quei casi conviene lavorare su una copia del sito e risalire con ordine invece di procedere per esclusione in produzione.
Domande frequenti
Devo disinstallare e reinstallare Elementor?
Quasi mai serve, e comporta un rischio inutile. Disinstallando il plugin i contenuti restano nel database, ma le pagine costruite con l’editor diventano temporaneamente illeggibili. Prima di arrivare a quel punto vale la pena provare la rigenerazione di CSS e dati e il cambio del metodo di caricamento.
Perché funzionava ieri e oggi no?
Nella maggior parte dei casi c’è stato un aggiornamento nel mezzo: di Elementor, di un addon, del tema o della versione di PHP lato hosting. Se hai accesso al registro degli aggiornamenti, guarda cosa è cambiato nelle ultime ventiquattro ore.
Gli addon di Elementor sono un problema?
Non in sé, ma sono la prima cosa da sospettare perché intervengono sullo stesso codice dell’editor. Averne tre o quattro attivi contemporaneamente moltiplica le possibilità di conflitto, soprattutto quando ognuno segue un proprio calendario di aggiornamenti.
Elementor rallenta il sito?
Aggiunge livelli di codice, quindi incide. Il punto è quanto: una pagina costruita in modo asciutto pesa poco più di una fatta a mano, una con dieci contenitori annidati dove ne bastavano tre pesa parecchio di più. La differenza la fa il modo in cui è costruita, non il plugin.
