Migrazione da Joomla 3 a Joomla 6 con T3 e Purity III: caso reale
- Joomla
- 9 settembre 2026
Indice dei contenuti
Un sito Joomla 3 con un template ancora adatto alle esigenze dell’attività deve necessariamente essere rifatto per poter essere aggiornato? In questo intervento è stato possibile completare la migrazione da Joomla 3 a Joomla 6 mantenendo Purity III di JoomlArt e aggiornando T3 Framework, senza ricostruire completamente il frontend.
Il lavoro più impegnativo è stato capire quali dipendenze impedissero al sito di funzionare sulle versioni successive. Un framework molto vecchio, plugin accumulati negli anni e componenti non più utilizzati hanno richiesto diagnosi distinte, con verifiche prima di ogni nuovo passaggio.
Racconto il caso senza riferimenti al committente o al sito. Il percorso mostra come sono stati affrontati i problemi di questa installazione: non è una sequenza di operazioni da replicare automaticamente su qualsiasi Joomla 3.
Migrazione Joomla 3: perché lavorare prima in staging
Il punto di partenza era un’installazione Joomla 3 con Purity III, una versione molto datata di T3 Framework e numerose estensioni stratificate nel tempo. Tra queste erano rimasti anche elementi dell’ecosistema RocketTheme, che il sito non utilizzava più per il frontend.
L’obiettivo era aggiornare il CMS conservando, dove possibile, la struttura grafica esistente. Per valutare se fosse fattibile ho lavorato in staging, cioè su una copia separata, lasciando intatto il sito di produzione. Questo ha permesso di disabilitare componenti e cambiare temporaneamente template senza coinvolgere i visitatori del sito pubblico.
La preparazione ha compreso:
- backup prima delle operazioni;
- aggiornamento dell’installazione Joomla 3;
- controllo delle estensioni tramite Pre-Update Check;
- aggiornamento del template Purity III;
- analisi della compatibilità di T3 Framework.
Il controllo pre-aggiornamento era un punto di partenza per l’analisi. I test successivi avrebbero mostrato il comportamento effettivo delle estensioni installate.
Per chi deve ancora ricostruire lo stato del proprio progetto, i controlli iniziali su un sito Joomla non aggiornato aiutano a raccogliere le informazioni prima dell’intervento. La possibilità di clonare Joomla per testare gli aggiornamenti serve poi a separare questa fase dal funzionamento quotidiano del sito.
Aggiornare Joomla 3 a Joomla 4 con un vecchio T3 Framework
Durante il primo passaggio a Joomla 4 mi sono trovato davanti a un errore che poteva far pensare a un aggiornamento del core non riuscito. Il problema era invece nel vecchio T3 Framework, che utilizzava ancora chiamate alle API di Joomla 3 non più disponibili nel nuovo contesto, come:
$app->isAdmin()
Le API sono le funzioni attraverso cui un’estensione interagisce con Joomla. Se il framework richiama un metodo che il CMS non mette più a disposizione, l’esecuzione può interrompersi e impedire la corretta visualizzazione delle pagine.
Un errore comparso durante l’aggiornamento non identifica automaticamente un difetto del core. In questo caso era necessario separare lo stato dell’installazione dal codice incaricato di produrre il frontend.
Ho quindi disabilitato temporaneamente T3 e utilizzato Cassiopeia come template provvisorio. In questa configurazione è stato possibile verificare che Joomla 4 fosse effettivamente installato e funzionante.
Cassiopeia ha avuto una funzione diagnostica: togliendo temporaneamente la dipendenza dal vecchio framework, potevo controllare il CMS e affrontare il problema del template separatamente. Non era ancora il momento di decidere se abbandonare Purity III.
PHP e compatibilità durante la migrazione Joomla
Nel corso della stabilizzazione di Joomla 4, con PHP 7.4 comparivano diversi notice relativi al sistema Language di Joomla. Dopo il passaggio a PHP 8.1, il sito ha iniziato a funzionare senza quegli avvisi.
Questo è il comportamento osservato nell’ambiente del caso. Non significa che ogni notice del sistema Language abbia la stessa causa o che cambiare PHP risolva qualsiasi errore di migrazione. Senza analizzare il singolo messaggio e il codice coinvolto, una conclusione del genere sarebbe troppo ampia.
L’episodio mostra però perché PHP debba essere considerato parte integrante dell’aggiornamento Joomla. Il CMS, il framework grafico e i plugin vengono eseguiti nello stesso ambiente: aggiornare soltanto uno di questi elementi può lasciare incompatibilità negli altri.
PHP 8.1 è stato un passaggio intermedio del percorso raccontato, non la configurazione da proporre per Joomla 6. La guida ufficiale al passaggio da Joomla 5 a Joomla 6 indica PHP 8.3 come requisito minimo. Per un nuovo intervento vanno verificati i requisiti della versione di destinazione insieme a quelli delle estensioni, senza riprodurre alla cieca l’ambiente usato in una fase precedente.
Da Joomla 4 a Joomla 5: stabilizzare prima di continuare
Una volta ottenuto un Joomla 4 funzionante, il lavoro è proseguito verso Joomla 5. Anche questa fase ha richiesto aggiornamento del core, controlli del frontend e del backend, aggiornamento di T3 e aggiornamento di Purity III.
Quando necessario, Cassiopeia è rimasto il template temporaneo per isolare i problemi. Questo riferimento permetteva di distinguere un malfunzionamento legato al frontend personalizzato da uno presente anche con il template standard.
Il criterio era verificare ogni fase prima di passare alla successiva. Accumulare più cambiamenti su un sito già in errore avrebbe reso più difficile attribuire i problemi: core, PHP, framework e plugin avrebbero potuto produrre sintomi sovrapposti.
Per un responsabile aziendale questa distinzione ha una conseguenza concreta. Vedere una pagina aprirsi dopo un aggiornamento è un primo riscontro, ma la decisione di proseguire richiede anche controlli nell’amministrazione e sulle funzioni effettivamente usate.
Joomla 6 e Behaviour - Backward Compatibility
In preparazione al passaggio da Joomla 5 a Joomla 6, il controllo pre-aggiornamento richiedeva di disattivare il plugin Behaviour - Backward Compatibility. Disabilitandolo compariva questo errore:
Class "JPlugin" not found
Il messaggio indicava che del codice cercava ancora la vecchia classe JPlugin. Il livello di retrocompatibilità aveva consentito a estensioni legacy di continuare a funzionare; rimuovendolo, la dipendenza diventava visibile.
La distinzione fra i plugin di compatibilità conta: quello senza numero nel nome, oggetto di questo errore, deve essere disabilitato prima dell’aggiornamento a Joomla 6. È diverso da Behaviour - Backward Compatibility 6, previsto per il passaggio successivo fra le API di Joomla 5 e Joomla 6. La documentazione ufficiale distingue i due plugin e indica Joomla 5.4.x come versione di partenza per l’aggiornamento a Joomla 6. Riferimento Joomla sui plugin di retrocompatibilità.
Nel caso in esame, per proseguire occorreva individuare chi dipendesse ancora da JPlugin. Limitarsi a mantenere attivo il vecchio plugin avrebbe lasciato irrisolta la causa del blocco.
Come ho individuato i plugin Joomla legacy
Ho eseguito una ricerca globale nei file del progetto della stringa:
extends JPlugin
Questa espressione identifica codice che dichiara una classe derivata dalla vecchia JPlugin. La ricerca ha permesso di individuare diversi residui da esaminare, invece di procedere soltanto in base al nome delle estensioni mostrate nel pannello.
| Elemento individuato | Verifica nel caso |
|---|---|
| RokNavMenu di RocketTheme | Non più utilizzato nel sito basato su JoomlArt/T3 |
Vecchi plugin del gruppo search | Residui del precedente sistema di ricerca Joomla |
| JW Simple Image Gallery | Controllo dell’uso nei contenuti prima della rimozione |
La presenza della stringa era un indizio da collegare alle estensioni e al loro utilizzo, non un’autorizzazione a cancellare tutti i file trovati. Allo stesso modo, non trovare extends JPlugin non dimostra da solo la compatibilità con Joomla 6: altre dipendenze legacy possono usare forme diverse.
Per JW Simple Image Gallery ho verificato anche il database, cercando negli articoli tag come {gallery}. Un plugin di contenuto può sembrare inutilizzato nella navigazione e servire invece a trasformare un richiamo testuale in una galleria.
Nel caso analizzato non risultava utilizzato, quindi è stato possibile disabilitarlo e rimuoverlo. Se quei richiami fossero stati presenti, sarebbe stato necessario valutare come conservare o sostituire le gallerie prima di eliminare il plugin.
La domanda utile è «che cosa dipende ancora da questa estensione?». L’età del pacchetto, da sola, non risponde. È lo stesso criterio descritto nell’audit delle estensioni prima della migrazione Joomla: verificare funzioni e contenuti prima di decidere cosa aggiornare, sostituire o rimuovere.
Dopo la rimozione o disattivazione delle estensioni obsolete, Behaviour - Backward Compatibility ha potuto essere disabilitato mantenendo funzionanti frontend e backend. Il blocco che impediva di proseguire era stato risolto.
T3 Framework e Purity III su Joomla 6: il risultato
Il passaggio a Joomla 6 è stato completato. Il risultato dell’intervento è stato:
- Joomla 6 funzionante;
- template Purity III mantenuto;
- T3 Framework aggiornato;
- nessuna necessità di rifare completamente il template;
- rimozione di componenti e plugin legacy accumulati negli anni.
L’installazione risultava quindi più pulita rispetto al punto di partenza. Il frontend è stato conservato aggiornando le sue dipendenze e togliendo quelle che non servivano più.
La possibilità di mantenere Purity III è coerente anche con la pagina ufficiale JoomlArt del template, che lo presenta come disponibile per Joomla 6 e basato su T3 Framework. Questa disponibilità non garantisce però che qualsiasi vecchia installazione o personalizzazione sia compatibile senza interventi: rimane necessario verificare il progetto concreto.
Il caso dimostra che un rifacimento completo non era necessario per questo sito. Su un’altra installazione, override, estensioni indispensabili o modifiche al framework potrebbero portare a una scelta diversa.
Cosa insegna questa migrazione da Joomla 3 a Joomla 6
Il lavoro decisivo è stato attribuire ogni errore alla dipendenza corretta: prima T3, poi il comportamento nell’ambiente PHP, infine le estensioni che continuavano a richiamare API legacy.
Lavorare in staging ha consentito di procedere per esclusione. Cassiopeia ha aiutato a verificare il core separatamente dal frontend. La ricerca nel codice ha individuato i plugin da analizzare, mentre il controllo dei contenuti ha evitato di rimuovere un’estensione senza sapere se fosse ancora necessaria.
Una migrazione Joomla importante è soprattutto un lavoro di analisi delle dipendenze, della compatibilità e del codice legacy. Il pulsante di aggiornamento esegue una parte del percorso; le decisioni su cosa conservare e i test intermedi determinano se il sito può affrontare il passaggio successivo.
Se gestisci un vecchio sito Joomla e non sai se il template sia recuperabile, con un intervento di assistenza Joomla posso individuare cosa aggiornare, cosa rimuovere e quali parti richiedono un lavoro specifico. Puoi contattarmi per valutare la migrazione del tuo sito prima di decidere se rifare il frontend.
