JWC 2026, primo giorno: AI, sicurezza e un Joomla più accessibile

Una premessa: con quattro sale in parallelo ho seguito una sola delle due tracce in inglese, quindi questo è il racconto di una giornata possibile tra le tante. Il programma completo lo trovi sul sito della conferenza.

Apertura: "Get on the field"

Dopo il benvenuto di Sigrid Gramlinger, il primo keynote è di Elisa Foltyn, presidente di Open Source Matters (l'associazione che sta dietro al progetto Joomla). Il titolo era "It's all about the (YO)U" e il filo conduttore era un paragone che, lo ammetto, non mi aspettavo: una squadra di football di una cittadina tedesca da 40.000 abitanti che ha vinto più volte il campionato nazionale.

Come hanno fatto? Con le persone. Centinaia di volontari, famiglie e amici che lavorano e giocano insieme alla squadra. Joomla funziona allo stesso modo: è circondato da sistemi molto più grandi, gestiti da aziende con un sacco di soldi, eppure va avanti. Va avanti perché c'è gente che ci mette il proprio tempo.

Il messaggio finale era "Get on the field": scendi in campo, è ora di dare indietro a Joomla quello che Joomla ti ha dato in questi anni. We are Joomla. All together.

Penso sia un paragone calzante. Chi frequenta i Joomla User Group lo sa: il progetto è fatto da persone che non sono pagate e che ci credono.

Vitaly Friedman: come si progettano le interfacce complesse

Vitaly Friedman (quello di Smashing Magazine) era in collegamento online e ha parlato di design per interfacce complesse e di UX in ambito aziendale. Un talk pieno di link e strumenti, ma l'idea di fondo era semplice: quando parli con qualcuno attraverso un'interfaccia devi prima capire che lingua sta parlando. Serve un vocabolario comune, altrimenti ci si parla senza capirsi.

Qualche spunto pratico che mi sono segnato:

• La navigazione non è solo il menu. Tutto quello che porta l'utente da una schermata all'altra è navigazione: le azioni nelle tabelle, lo zoom, lo scorrimento, i drill-down.
• Paginazione con gli intervalli. Sotto i numeri di pagina indica cosa si trova in quella pagina (per esempio l'intervallo di prezzo), così l'utente sa dove sta andando prima di cliccare.
• Il tasto "escludi" nei filtri. Spesso l'utente vuole "tutto tranne questo", e una lista di checkbox non glielo permette.

Appena diventeranno pubbliche le slide e le registrazioni metterò qui in link alla sua gigantesca raccolta di tool frontend.

Nicholas Dionysopoulos: l'AI senza la "I"

Anche Nicholas Dionysopoulos (Akeeba) era collegato da remoto. Il suo talk si chiamava "Practical AI for Joomla Developers: Beyond the Hype and the Panic", e il titolo dice già tutto.

Ha cominciato con una panoramica storica: quando è nata l'AI, come è stata costruita, cosa è successo nel tempo. La conclusione è che è tutta matematica e gestione delle probabilità. Non c'è nessuna "I" in "AI": non esiste una vera intelligenza là dentro. E qui aggiungo io: la "I", nell'AI, ce la deve mettere l'utente.

Secondo punto: tutti usano l'AI, anche per cercare vulnerabilità sui nostri siti. Quindi usarla ha un costo, ma anche non usarla ha un costo, e al momento costa molto di più non usarla.

Terzo punto, come usarla bene. Prima si sceglie lo strumento giusto (chatbot o assistente per il codice), poi si "inserisce l'intelligenza" nell'AI con gli strumenti adatti: server MCP che la collegano a Joomla, comandi (prompt riutilizzabili con parametri), skill (procedure che scattano in base al contesto) e plugin (pacchetti di comandi e skill da attivare o disattivare in blocco). Un avvertimento che mi ha colpito: troppo contesto fa male quanto nessun contesto. Il codice che ha mostrato è sul suo GitHub: mcp4j, joomla-mcp-php, pm-skill-demo, devskills e jwc2026. Quest'ultimo, lo dice lui stesso, non sostituisce chi integra i siti né i page builder: crea un buon punto di partenza.

Poi la sicurezza. Nessuno si mette a scrivere software insicuro apposta: sono le piccole sviste che, una sopra l'altra, diventano buchi seri (il "modello del formaggio svizzero" degli incidenti). Quindi audit di sicurezza sempre, e sempre un controllo di compatibilità con la versione di Joomla, cercando deprecazioni e problemi come indicato nelle guide di migrazione del Joomla Manual.

Infine il vibe coding, con due slide molto chiare: una lista di cosa NON fare (costruire tutto con un prompt solo, fidarsi delle API che il modello si è inventato, saltare la documentazione, accettare codice che non sai leggere, insistere con i prompt su una base sbagliata, saltare la revisione di sicurezza) e una lista di cosa fare: costruisci a piccoli passi, un prompt per una sola parte dell'estensione; fidati ma verifica; dai all'AI le fonti ufficiali di Joomla e un'estensione scritta bene come esempio; rileggi il codice; torna indietro se la base è sbagliata invece di insistere; e soprattutto la revisione di sicurezza è obbligatoria, perché nessun modello scriverà mai codice sicuro da solo.

Ultima cosa, e anche qui sono pinamente d'accordo con lui: l'AI non sarà una bolla. A differenza di tante mode con grande hype degli ultimi dieci o vent'anni, questa ha un uso vero. Costerà di più di oggi, ma resterà, perché è una cosa che la gente ha davvero voglia di pagare.

Llewellyn van der Merwe: il problema non è scrivere il codice, è mantenerlo

Llewellyn van der Merwe è l'autore di Joomla Component Builder (JCB), e il suo talk partiva da un'idea che chiunque abbia scritto un'estensione conosce bene: cominciare non è il problema. Il problema è mantenere il codice nel tempo. JCB è nato per quello.

L'idea è che il "modello" dell'applicazione resti dentro JCB: la struttura (campi, viste), il comportamento (permessi, logica del progetto) e le integrazioni (viste API, plugin di routing). Da lì si genera il componente vero e proprio, e quando cambia qualcosa si rigenera.

Ha presentato anche JoomEngine, un server MCP che si collega alle estensioni fatte con JCB (e forse anche ad altre) per usarne le API attraverso l'AI. I prossimi passi: trasformare una conversazione in un blueprint, e dal blueprint arrivare al componente finito. Più la possibilità di gestire in automatico dei container Docker per installare e testare l'estensione.

David Jardin: un exploit al giorno

Il keynote del pomeriggio era di David Jardin, dello Strike Team, cioè il team di sicurezza di Joomla. E il dato di apertura fa impressione: nel 2026 sono state trovate più vulnerabilità che negli ultimi dieci anni messi insieme. Non solo in Joomla, ovunque: Microsoft, Debian e altri hanno rilasciato patch che chiudevano più di mille CVE in un colpo solo.

Tutto questo grazie, o per colpa, dell'AI. I problemi più comuni restano sempre quelli: controlli di accesso sbagliati, bypass dell'MFA, cross-site scripting.

Cosa fare, quindi? A novembre c'è un Security Sprint: si può aiutare a testare le estensioni. Chi sviluppa estensioni dovrebbe fare una revisione delle proprie. E bisogna essere trasparenti: non vergognarsi di dire che una release è una release di sicurezza, gli utenti devono saperlo.

Poi un tema che farà discutere: il Cyber Resilience Act europeo. In pratica gli aggiornamenti di sicurezza dovranno essere disponibili gratis per almeno cinque anni. Per chi vende estensioni è una bella gatta da pelare: come lo gestisci, se il tuo modello è l'abbonamento annuale? E mi chiedo anche quanto tocchi chi costruisce siti web per i clienti, non solo chi sviluppa estensioni. Di sicuro se ne parlerà ancora.

E aggiorna sempre, in fretta, perché si va sempre più veloci sia a scoprire le vulnerabilità sia a sfruttarle. La nota positiva: nell'ultimo anno sono stati sistemati bug che stavano lì da anni, in alcuni casi già sfruttati, e nessuno se ne era mai accorto. Se gestita bene, l'AI porterà a un Internet più sicuro.

Benjamin Trenkle: come funziona davvero il progetto Joomla!

Benjamin Trenkle ha spiegato come è fatto il progetto dall'interno: i tre dipartimenti (Production, Outreach, Operations), i ruoli del board (presidente, vicepresidente, segretario, tesoriere) e soprattutto il fatto che Joomla è un sistema bottom-up: parte dal basso, dalla community, ed è questo che lo definisce.

Interessante la parte su cosa fa concretamente un Release Manager per far uscire una versione: carica i file, firma con TUF, prepara la release su GitHub e pubblica. E se dopo il rilascio salta fuori un problema? Niente panico: esiste un sistema di valutazione del problema, con dei valori da compilare, e ci si muove di conseguenza. Sembra una banalità, ma rende tutto più professionale e toglie di mezzo l'errore emotivo, quello che ti fa agire d'impulso alle undici di sera.

Per la manutenzione del codice ci sono diversi gruppi: bug squad, maintenance team, accessibility team, enhancement team, security team, testing team, docs team, manual team. Lato Outreach: marketing, eventi, "Pizza, Bugs & Fun" e i Joomla User Group. Se ti è mai venuto il dubbio "dove potrei dare una mano?", la risposta è: in uno di questi.

Laura Gordon: un gestore di eventi con il core e i workflow

Un caso reale: come costruire un sistema di gestione eventi usando quasi solo il core di Joomla, con i campi personalizzati, gli articoli e i workflow. Le estensioni aggiunte sono poche: Latest News Enhanced Pro (di Olivier Buisard) per mostrare e filtrare gli eventi, i plugin per i template delle email di workflow di Wicked Software (Benjamin Trenkle e Martina Scholz), e il modulo calendario di Joomill.

La parte interessante è quello che si ottiene con i workflow: email automatiche a ogni transizione, template diversi per chi gestisce gli eventi e per chi li propone, note personalizzate dentro le email di approvazione o di richiesta modifica, l'articolo che cambia proprietario dopo l'approvazione e gli autori che non possono più modificarlo. Qui non ho ben capito quanto questo sia parte del core oppure frutto di un plugin custom, mi riservo di indagare e aggiornare :)

Il progetto Joomla accessibile

La giornata si è chiusa con il panel condotto da Sigrid Gramlinger sul Joomla Accessibility Project, con il team che ci sta lavorando. L'obiettivo è rendere Joomla accessibile a tutti, frontend e backend. Il progetto è partito il 1° luglio 2026, durerà 18 mesi ed è sostenuto dalla Sovereign Tech Agency, un'agenzia tedesca che si occupa di sovranità digitale, accessibilità compresa.

Le tappe sono dieci: audit, design system, template e frontend, un set di dati di esempio accessibile, form di inserimento configurabili nel backend, standardizzazione di batch e filtri nell'amministrazione, funzioni trasversali con audit e documentazione, test automatici di accessibilità in CI, documentazione per sviluppatori e infine un audit esterno.

L'idea è lavorare a livello di core, in modo che le modifiche siano il più possibile indipendenti dal template. La preoccupazione più grande, detta chiaramente dal team, è la retrocompatibilità per chi sviluppa estensioni: cambiare Bootstrap (anche nel backend) con qualcos'altro sarebbe un bel problema da gestire. L'obiettivo dichiarato è rendere il sistema più accessibile possibile cambiando il meno possibile le abitudini degli sviluppatori.

Ed è anche la mia preoccupazione. Che Joomla debba essere completamente accessibile è scontato, ma non ci si può permettere di perdere sviluppatori e utilizzatori per delle breaking change. Il team dovrà impegnarsi al massimo sulla retrocompatibilità.

Cosa mi porto a casa dal primo giorno

L'AI è al centro di quasi tutti i discorsi, come sempre ultimamente. Ma il filo conduttore della giornata mi sembra un altro: non bisogna averne paura, va considerata un'alleata, a patto di usarla bene. Vale per chi sviluppa, per chi gestisce un sito e per chi lo deve difendere.

Stasera cena, PPT-oke e J!Awards. Domani seconda giornata, con la roadmap di Joomla e le sessioni "Make it happen". A domani!