Perchè il passaggio da Joomla 3 a Joomla 4 è stato epocale

AlanT

Il passaggio dalla versione 3 alla versione 4 di Joomla ha segnato un confine che per certi versi non tutti hanno compreso fino in fondo. Molti utenti hanno sperimentato la delusione nello scoprire che molte estensioni che funzionavano per Joomla 3 non siano state aggiornate per la versione 4 e in seguito siano state abbandonate. Mi è capitato spesso negli ultimi due anni di leggere commenti tra il deluso e l’arrabbiato e altrettanto spesso qualcuno arrivare alla facile conclusione che questo sia un sintomo del fatto che Joomla sia un progetto destinato all’abbandono.
Io non posso prevedere il futuro ovviamente, ma posso dirvi qual’è stata la mia esperienza in prima persona su questo passaggio epocale e provare a spiegarvi alcune cose dal mio punto di vista di sviluppatore.

Partiamo dai fondamentali. Joomla (come Wordpress) funziona solo se installato in un server in cui è presente PHP e un sistema di database (tipicamente MySQL, ma non sempre). Se per esempio caricate il pacchetto di file di Joomla in un server configurato per il Python non funzionerà. Questo aspetto molti di noi lo danno per scontato, ma non lo è perché di fatto crea l’ecosistema in cui poter realizzare il nostro sito web. Joomla è egli stesso un ecosistema, realizzato e pensato appositamente per essere scalabile, cioè diventare quel che si vuole, in base alle esigenze di chiunque per mezzo degli strumenti nativi e delle estensioni. Le estensioni sono l’anello più centrale, devono quindi rispettare sia i paradigmi di Joomla, sia quelli di PHP+database.

Come tutti i linguaggi di programmazione anche PHP evolve, sia per poter migliorare le sue performance sia per diventare più sicuro e veloce. Se PHP evolve, anche l’ecosistema di Joomla DEVE evolvere seguendone i paradigmi. E se Joomla evolve per adattarsi ai suoi paradigmi anche le estensioni al suo interno devono farlo. Se mi avete seguito fino qui avrete forse compreso che l’adattamento delle estensioni avviene su due livelli: quello verso Joomla e quello verso PHP.
E cosa è successo nel passaggio J3/J4?
Proverò a fare tre macro esempi senza entrare troppo nel tecnico.

Namespaces
Tra le feature introdotte con Joomla 4, quella che singolarmente ha impattato maggiormente sullo sviluppo delle estensioni probabilmente è l’utilizzo dei namespace a tutti i livelli, dal core alle estensioni. I namespace non sono un concetto nuovo e hanno iniziato ad essere inseriti già con Joomla 3.3, ma la grossa differenza è che fino alla v 3.9 le estensioni potevano funzionare anche senza. Dopo no. I namespace sono uno strumento potentissimo che permettono allo sviluppatore di crearsi uno spazio proprio e popolarlo con delle entità a proprio uso e consumo evitando i conflitti con tutto il resto e richiamando entità esterne in altre estensioni. Avere un’architettura con i namespace rende molto più efficiente lo sviluppo... il problema nasce quando hai un’architettura che è stata creata senza i namespace e devi riscriverla con i namespace. Molto spesso significa dover riprogettare tutto.

Router
Su questo capitolo potrei scrivere un romanzo. Gli utenti considerano il router di Joomla sono nel suo aspetto più semplice: la costruzione degli url degli articoli. Ebbene, sappiate che il sistema di routing di un CMS è una delle cose più complesse che esistano e che influenza pesantemente lo sviluppo di un’estensione. Il core di Joomla non può sapere com’è fatta la struttura logica di un’estensione e quindi nella fase di sviluppo è necessario compilare il router (dell’estensione) in modo che istruisca il core. Joomla 4 ha definitivamente abbracciato un nuovo sistema di routing che esisteva già dalla versione 3.5. È molto più rigido rispetto al precedente in cui era ammesso un metodo “legacy” che permetteva anche alle vecchie versioni di Joomla di funzionare. Con il passaggio alla versione 4 questo metodo è stato abbandonato. Cambiare il sistema di routing di un’estensione già installata può comportare che le voci di menu che un utente ha creato con la versione precedente smettano di funzionare o generino errori (ecco perché nel pannello di gestione dei menu esiste la voce “Rigenera”), si tratta quindi di un processo molto delicato.

Chiamate Database
Ogni volta che richiamate, create, modificate o eliminate una cosa qualunque all’interno di Joomla (un articolo, un utente, un tag ecc) fate un’operazione basata su una chiamata al database. In gergo si chiamano query e Joomla le fa per voi. Cioè voi cliccate “Salva” e Joomla elabora una query per voi. Joomla 4 ha introdotto i prepared statements nelle query e ha modificato l'oggetto che si occupa di gestirle.

// Joomla 3.x
$db = JFactory::getDbo();

//Joomla 4.x
$db = Factory::getContainer()->get('DatabaseDriver');

Solo che il sistema che funziona per Joomla 4 non può essere usato su Joomla 3 e questo crea un ENORME problema perchè se qualcuno installa l'ultima release di un'estensione su Joomla 3 va a rompere tutte le chiamate al db. Questa è una delle ragioni per cui alcuni sviluppatori hanno creato una major release dell'estensione per Joomla 4 e mantenuto aggiornate ancora per un po' quelle per Jooma 3.

vedi ad esempio il caso akeeba.com - https://www.akeeba.com/compatibility.html#akeeba-backup-compatibility

Tutto questo, per farla breve, si è tradotto in una mole di lavoro straordinariamente alta per gli sviluppatori. Lavoro che si è dovuto aggiungere a quello che già si svolge quotidianamente (aggiornamenti regolari, supporto ai clienti, nuove feature ecc) e non con la prospettiva di aumentare le entrate, ma in realtà con la sola speranza di riuscire a mantenere quelle attuali (e con l'ansia crescente che i clienti si stancassero prima di aspettare...). Questo scenario ha portato probabilmente molti a farsi due conti in tasca e domandarsi se ne valesse la pena. E la scelta fatta da molti l'abbiamo avuta sotto i nostri occhi.

E Joomla 5 e Joomla 6?
Guardando al presente e al futuro più vicino, Joomla oggi è un CMS con delle caratteristiche molto migliori di quelle che avevamo prima. Il prezzo da pagare è stato alto, ma è stata fatta una scelta per certi versi epocale e ora la cosa saggia è guarda avanti. Joomla 5 è l'evoluzione del paradigma nato con Joomla 4 e con Joomla 6 diventerà definitivo (molti dei warning che oggi vengono visualizzati come DEPRECATE su J4/J5 con J6 diventeranno bug a tutti gli effetti). Nel frattempo vengono realizzate nuove feature e il core viene costantemente migliorato.
Quindi chi ha timore che Joomla sia un relitto abbandonato si ricreda: da un punto di vista tecnico in realtà Joomla è molto migliore oggi di quanto non lo fosse ieri. Ma servono sviluppatori che portino nuove estensioni, con il giusto approccio manageriale per mantenerle nel lungo termine. Serve una community correttamente informata, con un occhio attento e che esca dal concetto "tutto gratis, tutto subito, tutto perfetto" perchè quello al massimo è uno slogan, ma non la realtà. Serve tanto lavoro, tanta fatica, tanta dedizione.
Come sempre del resto.
Buon Joomla a tutti.

jabba

Amen

Post interessantissimo che spiega chiaramente tutto quello che ci sta sotto e tutto quello che è successo nel passaggio tra J3 e J4 e che ha portato scompiglio, frustrazione e sconforto nel cuore di utenti e sviluppatori.

Non sono sviluppatore di estensioni ma conosco PHP e cerco di studiarmi, per quanto possibile, come "funzionano" le estensioni che installo. Cerco di farlo per tutti i CMS che uso e mi è capitato di farlo anche con WP. Non voglio essere il solito fondamentalista ma è innegabile che il codice che fa girare WP sia enormemente più caotico e pesante (e datato a livello logico) rispetto a J!, ma sono anche conscio che sia stata una scelta progettuale ben definita per evitare problemi di retrocompatbilità.
Ricordo ancora i casini che successero quando (nella versione 4.5? non ricordo) introdussero una nuova versione di JQuery che rase al suolo metà dei template in circolazione, oppure le sommosse popolari quando venne introdotto Gutenberg.
Per non parlare del caotico sistema di hook e functions.php rispetto all'elegante MVC di Joomla e della triade componenti/plugin/moduli.

Quindi penso che sia stato deliberatamente scelto di tenere un codice "datato" per agevolare la retrocompatibilità, al contrario del progetto Joomla! che ha sempre preferito la novità al "benessere" di utenti e sviluppatori (se non erro fu addirittura deciso di adottare Bootstrap 5 invece che Bootstrap 4 quando Joomla4 era già in dirittura d'arrivo...).

La domanda, da avvocato del diavolo, a questo punto è: chi ha avuto ragione? E' meglio tenere buoni utenti e sviluppatori a discapito di un codice vecchio, bucabile minimale (e che quindi ti obbliga ad un plugin per letteralmente QUALSIASI cosa) o è meglio andare allo scontro ma presentarsi con un codice sempre pulito, moderno e funzionale?

Visti i numeri la risposta parrebbe scontata ma sinceramente non ne sono così sicuro. Mi piacerebbe aprire una discussione a riguardo
Grazie ancora per questo post super interessante.

ramses_2th

Gran bell'articolo, molto interessante. Complimenti!