disinstallare un plugin WordPress correttamente richiede più di un semplice clic su Rimuovi. Se ti limiti a disattivare un’estensione e poi rimuoverla dall’interfaccia, rischi di lasciare dietro tabelle MySQL, opzioni in wp_options, attività CRON, file orfani, persino regole di cache e sicurezza che continuano a influire sulle prestazioni. Questo articolo va dritto al punto: come rimuovere un’estensione minimizzando i rischi, includendo la pulizia del database e mantenendo un piano di rollback solido.
Prima di toccare qualsiasi cosa: mettere in sicurezza il terreno
Il comune denominatore delle disinstallazioni andate male non è il plugin… ma l’assenza di una rete di sicurezza. Prima di qualsiasi operazione, prepara questi elementi. Ti faranno risparmiare ore se qualcosa rompe l’admin, la homepage o il checkout (WooCommerce).
1) Backup completo (file + database) e punto di ripristino
Richiedi un backup che includa:
– Il database (tutte le tabelle, non solo quelle di WordPress).
– I file (wp-content, ma anche wp-config.php, .htaccess, ecc.).
– La possibilità di ripristinare rapidamente (idealmente con un clic, o almeno tramite un pacchetto scaricabile).
2) Lavorare su un ambiente di staging quando possibile
Lo scenario ideale: riprodurre la disinstallazione in un ambiente di test. Identificate i residui, verificate l’impatto, poi riproducete in produzione. Se non avete uno staging, almeno effettuate l’operazione in un periodo di minima attività e avvisate le parti interessate (marketing, supporto, e‑commerce…).
3) Verificare che non sia già in corso una manutenzione
Un sito già instabile (aggiornamenti interrotti, cache aggressiva, modalità manutenzione bloccata) è un candidato perfetto per una disinstallazione che degenera. Se siete già bloccati su una schermata di manutenzione, risolvetela prima seguendo Bloccato in Modalità Manutenzione.
Disattivare, eliminare, poi verificare: la sequenza corretta lato WordPress
Per evitare errori, rispettate l’ordine: disattivazione → eliminazione → controllo. Un’estensione può inserire regole, impostare cron job o creare pagine/shortcode. La disattivazione è la fase in cui WordPress esclude l’estensione dal ciclo di esecuzione, limitando gli effetti collaterali durante l’eliminazione.
Disattivare correttamente prima di eliminare
Iniziate disattivando l’estensione da Plugin. Poi:
– Se l’estensione ha una schermata di impostazioni, cercate un’opzione del tipo Rimuovi i dati alla disinstallazione (a volte chiamata Remove data on uninstall). Attivatela solo se siete certi di non aver più bisogno delle impostazioni né dei dati funzionali (log, statistiche, tabelle dedicate, ecc.).
– Se il plugin offre uno strumento di esportazione, esportate ciò che deve essere salvato (es.: redirect, moduli, configurazioni, liste). Questo vi tutela se cambiate idea o migrate verso un altro strumento.
Rimuovere dall’interfaccia… ma non fermarsi qui
Rimuovere il plugin dall’interfaccia elimina i file dell’estensione, ma non garantisce la pulizia del database. Alcuni plugin lasciano intenzionalmente i dati per permettere una reinstallazione senza perdita.
Per un promemoria dei passaggi nella dashboard (e degli errori comuni), puoi consultare questa guida esterna: Come disinstallare correttamente un plugin WordPress.
Per saperne di più sui nostri servizi di manutenzione di siti WordPress
Il nocciolo della questione: pulire il database (senza rompere il sito)
Pulire il database è la fase che fa paura, e a ragione: una cancellazione troppo ampia può compromettere pagine, CPT (custom post types), campi o impostazioni usate altrove. L’obiettivo non è eliminare tutto, ma rimuovere ciò che è realmente orfano.
Capire dove un plugin memorizza i suoi dati
Le estensioni WordPress scrivono generalmente in:
– wp_options : impostazioni (options), cache interne, chiavi API, flag di attivazione, transients.
– wp_postmeta : metadati allegati a contenuti (pagine, articoli, prodotti…). Molto comune per i builder, la SEO, i campi personalizzati.
– Tabelle dedicate : alcune estensioni creano le proprie tabelle (es: wp_pluginname_*) per motivi di prestazioni o di struttura.
– wp_usermeta : preferenze utente, ruoli specifici, impostazioni del profilo legate all’estensione.
– wp_comments \/ wp_commentmeta : casi rari (recensioni, sistemi di valutazione, log di discussione, ecc.).
Fase 1 : individuare le tabelle dedicate lasciate indietro
Iniziate elencando le tabelle. Se avete accesso a phpMyAdmin, Adminer o WP-CLI, cercate le tabelle che riportano il prefisso del plugin (spesso lo slug). Per esempio: wp_rank_math_*, wp_wf*, wp_woocommerce_*, ecc.
Prima della cancellazione :
– Verificate che l’estensione sia effettivamente rimossa (file assenti) e non sostituita da una versione mu-plugin o da un modulo.
– Assicuratevi che nessun altro plugin dipenda da queste tabelle (alcune suite condividono un database comune).
– Effettuate un export SQL solo delle tabelle interessate (oltre al backup completo). È il vostro rollback chirurgico.
Per un approfondimento mirato sulla rimozione delle tabelle lasciate dai plugin, questo contenuto esterno può aiutare: Rimuovere dal database le tabelle delle estensioni ….
Fase 2: pulire wp_options (opzioni, transient, autoload)
wp_options è spesso la fonte di contaminazione più importante, in particolare tramite le voci autoload = yes che vengono caricate ad ogni richiesta. Una disinstallazione pulita deve quindi mirare a:
– Le opzioni del plugin (spesso con prefisso).
– I transient (_transient_* e _site_transient_*) associati.
– Le voci di autoload massive, se appartengono all’estensione rimossa.
Procedura consigliata :
– Eseguire una ricerca per prefisso (es.: option_name LIKE 'pluginprefix_%').
– Verificare la natura dei dati (valori serializzati, JSON, testo).
– Eliminare in batch coerenti, non a caso.
– Ricaricare il sito e monitorare gli errori.
Attenzione: alcuni plugin memorizzano impostazioni con nomi generici. In tal caso, la cancellazione deve essere guidata dalla cronologia (data di aggiunta se nota), dalla documentazione o dal confronto staging/production.
Fase 3: controllare postmeta/usermeta lasciati dall’estensione
I metadati orfani non causano sempre il crash di un sito, ma appesantiscono il database e le query, e complicano le esportazioni/migrazioni. Su wp_postmeta e wp_usermeta :
– Individuate le chiavi meta (meta_key) associate al plugin (spesso con prefisso).
– Verificate se sono ancora utilizzate da un tema o da un altro plugin (es: campi ACF, builder, SEO).
– Evitate di eliminare meta condivise (es: alcune chiavi di tracciamento possono essere riutilizzate).
Fase 4: rimuovere i job CRON e le attività pianificate
Alcuni plugin lasciano eventi CRON che continuano a scattare (o a tentare di farlo), generando rumore e talvolta errori. I sintomi:
– Log di errore che citano funzioni inesistenti.
– Attività che falliscono e intasano la coda del cron.
– Rallentamenti periodici.
Controllate l’elenco degli eventi pianificati (tramite uno strumento di diagnostica o WP-CLI). Rimuovete quelli che appartengono chiaramente al plugin rimosso. Anche in questo caso: backup prima, e rimozione mirata.
Fase 5: pulire i file orfani in wp-content
La rimozione tramite WordPress elimina la cartella principale del plugin, ma non sempre:
– Le cartelle di cache (es.: in wp-content/cache).
– I log (es.: wp-content/uploads/plugin-logs).
– I file generati (CSS/JS minificati, immagini, indicizzazioni, esportazioni).
– I mu-plugin posti da alcuni strumenti.
Ispezionate:
– wp-content/uploads (cartelle con il nome del plugin, o cartelle di generazione).
– wp-content/cache (cache specifiche).
– wp-content\/mu-plugins (moduli must-use).
Eliminate solo ciò che identificate chiaramente come appartenente all’estensione.
Trappole comuni (e come evitarle)
Confondere disattivazione e disinstallazione
Disattivare impedisce l’esecuzione, ma lascia tutto al suo posto (file + dati). Disinstallare rimuove generalmente i file, ma non necessariamente i dati. Molte guide lo ricordano; in aggiunta, potete leggere: Come Rimuovere Correttamente un Plugin WordPress?.
Rimuovere troppo in fretta tabelle che somigliano al plugin
Alcune tabelle possono condividere prefissi simili o essere create da una suite di strumenti. Esempio: un plugin di sicurezza e il suo modulo firewall, o un plugin e-commerce e la sua estensione di pagamento. Se eliminate una tabella ancora in uso, rischiate errori SQL, pagine bianche o dati mancanti.
Per saperne di più sui nostri servizi di manutenzione di siti WordPress
Dimenticare che alcuni plugin volutamente non puliscono
Non è sempre un bug: alcuni sviluppatori scelgono di conservare i dati per facilitare la reinstallazione. Altri temono perdite irreversibili se l’utente cancella per errore. Il risultato, però, è lo stesso: tocca a te decidere se assumerti la cancellazione totale.
Ne considerare il contesto: cache, CDN, ottimizzazioni
Dopo la cancellazione, svuota:
– Plugin di cache (se ne hai un altro).
– Cache server (Varnish, Nginx FastCGI cache).
– CDN.
Altrimenti potresti credere che tutto funzioni mentre servi ancora file vecchi, o al contrario pensare che tutto sia rotto a causa di una cache incoerente.
Controlli dopo la disinstallazione: verificare che sia tutto davvero pulito
Una volta rimosso il plugin e ripulito il database, esegui una checklist di convalida.
1) Verificare il front-end, i form e i percorsi critici
Testa:
– Pagina iniziale, pagine principali.
– Ricerca interna.
– Moduli (contatto, preventivo, newsletter).
– Account cliente / accesso.
– Checkout se e-commerce.
2) Monitorare gli errori PHP e i log del server
Gli errori tipici dopo la disinstallazione:
– Funzioni chiamate dal tema o shortcode rimasti nei contenuti.
– Hook/azioni ancora riferiti in un mu-plugin o in un tema child.
– Attività CRON che puntano a codice rimosso.
3) Controllare l’impatto sulle prestazioni
Una disinstallazione riuscita può ridurre il peso diautoload e il carico SQL, ma non è automatico. Se il tuo obiettivo è anche migliorare le prestazioni percepite e le metriche, tieni d’occhio gli indicatori chiave. Questa guida interna può servire da riferimento: Comprendere i Core Web Vitals per.
4) Riesaminare la pulizia complessiva (SEO, database, media)
La rimozione di un plugin è un buon momento per fare pulizia più a fondo: revisioni inutili, transients, tabelle orfane, media non utilizzati, reindirizzamenti, ecc. Per un quadro di pulizia orientato alla visibilità, vedi Pulire per Migliorare la SEO.
Casi particolari: sicurezza, page builder e plugin di sistema
Plugin di sicurezza e firewall
Possono lasciare:
– Regole in .htaccess o la conf del server.
– File di blocco, liste IP, regole WAF.
– Mu-plugin o file drop-in.
Prima della rimozione, annota le impostazioni di hardening che vuoi conservare. Se vuoi ridurre la dipendenza dai plugin per l’accesso admin, puoi applicare misure manuali tramite Proteggere l accesso a wp-admin senza.
Page builder e shortcode
Rimuovere un builder può rompere il layout se il contenuto si basa su shortcode. In tal caso:
– Identificate le pagine interessate.
– Migra i contenuti (esportazione HTML, blocchi nativi o un altro page builder).
– Pulisci poi il database (postmeta voluminosi, librerie, CSS generate).
Plugin e-commerce e dati critici
Un plugin e-commerce non è come gli altri. Disinstallare WooCommerce, per esempio, implica prodotti, ordini, tasse, clienti… Non si cancella per vedere. Qui, privilegia una strategia di conservazione dei dati o una migrazione controllata, e non eliminare tabelle se non dopo una decisione chiara (legale, contabile, GDPR, ecc.).
Approccio metodico: come decidere cosa eliminare nel database
Se sei indeciso, adotta questo metodo:
– Elenca ciò che vuoi conservare (es.: ordini, moduli inviati, reindirizzamenti).
– Elenca ciò che deve scomparire (impostazioni, cache, log, dati di test).
– Identifica dove risiedono questi dati (tabelle dedicate, opzioni, meta).
– Eliminate in più passaggi e testate tra una passata e l’altra.
Questo approccio progressivo evita una grande pulizia irreversibile.
Quando la disinstallazione deve anche pulire: aspettative vs realtà
Molti utenti si aspettano che un plugin cancelli tutto automaticamente. In pratica, il comportamento varia moltissimo a seconda degli editori e degli ecosistemi. Si riscontrano discussioni simili anche in altre piattaforme: «pulizia» alla disinstallazione di un plugin. La lezione da trarre: non presumete mai che una disinstallazione rimuova il database, verificate sistematicamente.
Prevenire è meglio che curare: limitare i guasti durante le disinstallazioni
I problemi spesso insorgono in un contesto già fragile: sito non aggiornato, conflitti latenti, hosting limitato, database gonfio o assenza di monitoraggio. Mettere in atto buone pratiche di prevenzione riduce il rischio che la semplice rimozione di un plugin scateni un incidente. Per strutturare il vostro approccio, basatevi su Come Anticipare i Guasti.
Per saperne di più sui nostri servizi di manutenzione di siti WordPress
Delegare o no? Il caso in cui la manutenzione diventa più conveniente dell’improvvisazione
Se gestite un sito critico (lead, e‑commerce, immagine del brand), la disinstallazione con pulizia DB può rapidamente superare il bricolage: backup, staging, query SQL mirate, svuotamento cache/CDN, controlli dei log, validazione funzionale… A un certo livello, esternalizzare evita errori costosi e libera tempo. Potete vedere le opzioni disponibili qui: Per saperne di più sui nostri servizi di manutenzione del sito.
Sommario operativo (check-list breve)
– Backup completo + esportazione mirata delle tabelle\/opzioni potenzialmente interessate.
– Disattivazione del plugin + eventuale attivazione dell’opzione elimina i dati se si assume la rimozione.
– Rimozione dei file del plugin (tramite WP o FTP se necessario).
– Pulizia database: tabelle dedicate → opzioni\/transients\/autoload → metas → CRON.
– Pulizia dei file orfani (uploads\/cache\/mu-plugins\/drop-ins).
– Svuotamento cache\/CDN + test funzionali + controllo dei log.
– Misurazione delle prestazioni e audit post-pulizia.
