Audit delle estensioni prima di migrare da Joomla 3 a Joomla 5 o 6
- Joomla
- 4 settembre 2026
Indice dei contenuti
Prima di migrare un sito Joomla 3 non basta controllare se esiste una versione più recente del CMS. Il vero perimetro del progetto comprende componenti, moduli, plugin, template, override e personalizzazioni accumulati negli anni.
Una sola estensione incompatibile può bloccare l’aggiornamento, produrre errori nel frontend o rendere inutilizzabile una funzione amministrativa. L’audit serve a stabilire che cosa può essere aggiornato, che cosa deve essere sostituito e quali parti richiedono uno sviluppo specifico prima di intervenire sul sito.
Questo approfondimento affianca la guida alla migrazione da Joomla 3 a Joomla 5 e Joomla 6, concentrandosi sulla fase decisionale che precede i test tecnici.
Perché le estensioni determinano la complessità della migrazione Joomla
Joomla fornisce il nucleo del sito, ma molte funzioni operative dipendono da estensioni di terze parti o codice sviluppato su misura. Un catalogo, un form complesso, un sistema di ricerca, un’area riservata o un’integrazione esterna possono avere dipendenze differenti.
Durante il passaggio fra versioni principali cambiano anche requisiti PHP, API, eventi, librerie e modalità con cui il codice interagisce con il CMS. La disponibilità di un pacchetto installabile non garantisce che tutte le funzioni e i dati del progetto siano compatibili.
L’audit deve rispondere a domande concrete:
- l’estensione è ancora mantenuta?
- esiste una versione compatibile con la destinazione prevista?
- l’aggiornamento conserva struttura e dati?
- sono presenti addon o plugin collegati?
- il template contiene override relativi all’estensione?
- esistono modifiche applicate direttamente ai file?
- la funzione può essere sostituita senza cambiare il processo aziendale?
Senza queste risposte, il preventivo e la sequenza di migrazione si basano su ipotesi.
Come creare l’inventario di componenti, moduli e plugin Joomla
L’inventario non dovrebbe limitarsi alla schermata principale delle estensioni. Joomla può contenere pacchetti, librerie, plugin di sistema, plugin di autenticazione, moduli duplicati e componenti che non producono elementi visibili nel frontend.
Per ogni elemento è utile registrare:
- nome ed elemento tecnico;
- tipologia: componente, modulo, plugin, template, libreria o pacchetto;
- versione installata;
- produttore e canale ufficiale di aggiornamento;
- stato attivo o disattivato;
- funzione svolta nel sito;
- dipendenze da altre estensioni;
- presenza di dati da conservare;
- compatibilità dichiarata con PHP, database e Joomla di destinazione.
Un’estensione disattivata non è automaticamente irrilevante. Può contenere dati storici, essere richiamata da un task oppure essere stata disattivata temporaneamente. Prima di rimuoverla bisogna verificare perché è presente.
Anche il database può conservare tabelle di componenti non più installati. La loro esistenza non autorizza una cancellazione automatica: occorre attribuirle con certezza e stabilire se contengano informazioni da migrare o archiviare.
Verificare se un’estensione Joomla è davvero compatibile
La compatibilità va verificata attraverso il produttore, la documentazione e una prova sul progetto. Le indicazioni nel sistema di aggiornamento aiutano a individuare nuove versioni e requisiti, ma non possono conoscere le personalizzazioni presenti sul singolo sito.
Una verifica attendibile considera:
- versione esatta dell’estensione;
- percorso di aggiornamento supportato;
- versione PHP richiesta;
- database e versione supportati;
- dipendenze da framework o librerie esterne;
- eventuali passaggi intermedi documentati;
- modifiche alla struttura dei dati;
- stato degli addon collegati.
La frase “compatibile con Joomla 5” può riferirsi alla versione più recente del prodotto, non necessariamente a quella installata. Può inoltre richiedere un abbonamento attivo, una migrazione dei dati o la sostituzione di template e plugin complementari.
Per Joomla 6 la valutazione deve essere ripetuta sulla destinazione effettiva. Non è corretto dedurre la compatibilità soltanto perché un’estensione funziona su Joomla 5.
Template Joomla, override e framework grafici
Il template è spesso una delle parti più sottovalutate. Può includere framework, builder, posizioni modulo, file JavaScript e override HTML che modificano l’output del core o di altre estensioni.
L’audit dovrebbe individuare:
- versione e stato di manutenzione del template;
- compatibilità del framework grafico;
- override presenti nella cartella
html; - modifiche dirette ai file del template;
- dipendenze da moduli e plugin;
- codice JavaScript o CSS legato a markup non più prodotto;
- layout personalizzati e campi dinamici.
Un override può non generare un errore evidente e produrre comunque HTML incompleto, pulsanti mancanti o viste amministrative non coerenti. Per questo la verifica deve includere le pagine che usano davvero quel layout.
Quando il template non è aggiornabile, le opzioni possono essere adattarlo, ricostruire gli override oppure sostituirlo. La scelta dipende dalla qualità del codice, dal design da conservare e dal costo di manutenzione futuro.
Estensioni abbandonate: sostituire, riscrivere o eliminare
Se un componente non è più mantenuto, l’audit deve prima chiarire quale funzione svolga e quali dati possieda. Installare un’alternativa non trasferisce automaticamente record, categorie, relazioni e URL.
Le possibilità sono:
- eliminare la funzione se non è più utilizzata;
- sostituirla con un’estensione mantenuta;
- migrare i dati verso una nuova struttura;
- ricostruire soltanto la parte realmente necessaria;
- mantenere temporaneamente il vecchio sistema in un ambiente separato.
La sostituzione va valutata anche dal punto di vista SEO. Se il componente genera pagine pubbliche, un cambio di routing può modificare gli URL. Prima della migrazione occorre mappare gli indirizzi da conservare o reindirizzare.
Un caso reale con componenti non più disponibili e dati problematici è descritto nel case study sulla migrazione da Joomla 3 a Joomla 5.
Plugin di sistema e ordine di esecuzione
I plugin di sistema possono intervenire in molte richieste, comprese quelle amministrative. Un errore in questa fase può impedire l’accesso al backoffice o interrompere la procedura di aggiornamento.
Vanno controllati con particolare attenzione plugin per:
- autenticazione e utenti;
- editor e filtri dei contenuti;
- cache e ottimizzazione;
- sicurezza e firewall;
- redirect e URL SEF;
- integrazioni API;
- gestione multilingua;
- page builder e framework.
Disattivare tutto indiscriminatamente non è sempre una soluzione: alcune estensioni partecipano alla migrazione dei propri dati oppure sono necessarie per mantenere accessibile l’ambiente di test. La sequenza deve essere stabilita in base alla documentazione e verificata su una copia.
Audit del database e delle personalizzazioni Joomla
Una migrazione può fallire anche quando l’elenco delle estensioni sembra compatibile. Tabelle modificate, colonne con dati inattesi, caratteri non coerenti o patch applicate direttamente al core possono emergere soltanto durante i test.
L’audit deve cercare personalizzazioni nei punti in cui possono sopravvivere senza essere documentate:
- file modificati nel core o nelle estensioni;
- plugin custom;
- override di template;
- script esterni richiamati dal sito;
- task pianificati;
- integrazioni che leggono direttamente il database;
- regole nel file
.htaccesso nella configurazione del server.
Il confronto con una distribuzione pulita e la revisione del codice aiutano a distinguere file originali, modifiche legittime e residui non utilizzati. Non tutte le differenze devono essere trasferite: alcune possono essere vecchie correzioni già incluse nelle versioni recenti.
Provare la migrazione Joomla in un ambiente di test
L’audit produce ipotesi tecniche che devono essere confermate da una migrazione di prova. La copia deve essere abbastanza completa da riprodurre template, dati, utenti e integrazioni rilevanti, ma isolata per non inviare email o dati verso sistemi reali senza controllo.
Il test dovrebbe verificare almeno:
- completamento della sequenza di aggiornamento prevista;
- accesso al backend;
- pagine e voci di menu principali;
- form, ricerca e autenticazione;
- contenuti generati dalle estensioni;
- URL, redirect e metadati;
- log PHP e messaggi del CMS;
- task e integrazioni esterne controllabili;
- comportamento su mobile e browser principali.
Un backup è utile soltanto se può essere ripristinato. Prima dell’intervento in produzione bisogna conoscere tempi, passaggi e condizioni del rollback, senza dedurli dal solo esito positivo del test.
Cosa deve contenere il report dell’audit Joomla
Il risultato dell’audit dovrebbe trasformare l’inventario in decisioni. Per ogni estensione servono uno stato e un’azione proposta, per esempio:
- aggiornabile direttamente nel percorso previsto;
- aggiornabile dopo un passaggio intermedio;
- da sostituire;
- da migrare con procedura dedicata;
- da riscrivere in parte;
- da eliminare perché non utilizzata;
- da approfondire perché mancano informazioni verificabili.
Il report dovrebbe inoltre evidenziare dipendenze, rischi sugli URL, dati da conservare e test di accettazione. In questo modo la migrazione non è una successione di tentativi, ma un progetto con un perimetro leggibile.
Quando richiedere assistenza per una migrazione Joomla
Un sito semplice, costruito quasi interamente con il core e un template aggiornato, può avere un percorso lineare. Serve maggiore cautela quando sono presenti componenti obsoleti, ecommerce, aree riservate, molti override o integrazioni sviluppate negli anni.
In questi casi l’audit permette di stimare il lavoro prima di toccare la produzione e di separare gli aggiornamenti ordinari dalle parti che richiedono una soluzione personalizzata.
Se devi aggiornare un sito Joomla 3, posso analizzare estensioni, template, override e dati per costruire un piano di migrazione verificabile. Il servizio di assistenza Joomla può partire dall’audit senza presumere che tutto debba essere sostituito.
