Il diluvio AI: cosa sta cambiando nella directory

Il problema descritto da Carbis ha una catena semplice. L'AI di sviluppo ha abbassato il costo di produrre un plugin a praticamente zero: un wrapper del weekend attorno a una API, rifinito con un po' di prompt, ha lo stesso aspetto nella lista di ricerca di un plugin che ha costato due anni di manutenzione. Il segnale esterno — l'icona, la descrizione, lo screenshot — si copia facile; quello distorto è che prima la barriera all'ingresso era il codice, ed è proprio quella la barriera che l'AI ha rimosso. Il risultato è un'inflazione di dimensioni medie ad alta velocità: più plugin, più regressioni, più aggiornamenti mai testati, e un review team che — per quanto efficiente — può solo tirare le candide pagine su ciò che arriva.

Il fronte analitico che vale estrare è un altro: nel podcast si spiega che il lado del ranking può essere giocato e che il numero di installazioni attive — il fattore dominante — è un indicatore gia vecchio di due eras di ecosistema. Un plugin installato 200.000 volte oggi può riflettere un'investimento in marketing vecchi e non una qualità attuale: la scala misura il passato. Per il gestore di siti significa che la ricerca all'interno della directory serve solo come punto di partenza; la valutazione vera è quella che compi in prima persona dopo l'installazione, e i criteri sí sostituiscono i segnalet del ranking."+""

I criteri che uso per valutare un plugin (checklist completa)

La mia checklist operativa ha otto criteri e li applico sempre nello stesso ordine: i primi tre filtrano, le prime tre filtrano, le ultime cinque confermano o scartano. Procediamo come in un audit vero.

• Ultimo aggiornamento: un plugin che non riceve aggiornamenti da oltre 12 mesi, o viene verificato per compatibilità con le ultime 3 versioni di WordPress, è automaticamente sospetto. C'è un'eccezione legittima — plugin piccoli e stabili,.oggì un singolo sviluppatore che cura il proprio strumento — ma è una classe che ma è una classe che devi saper riconoscere: il playbook dei plugin senza patch descrive cosa fare quando un plugin necesario non riceve più fix.
• Installazioni attive in relazione alla nicchia: 5.000 installazioni per un plugin di mappa di nicchia aggressively e possono essere un ottimo punteggio; 5.000 per un form builder sono un segnale di maturità debole. Il confronto va fatto dentro la categoria, non in assoluto.
• Velocità di risposta ai ticket di supporto: le pagine di supporto della directory sono un'archeologia preziosa. Un problema segnalata da mesi senza risposta è un indicatore più nitido di qualsiasi rating; una risposta in giorni con patch seguite da release è il segnale migliore.
• Consistenza del changelog: i changelog che registrano "migliorie e fix" in modo indistinto per 3 versioni di fila sono il segno di uno sviluppo senza protocollo. I changelog che dicitano CVE e compatibilità con precisione raccontano un team che gestisce il rischio in modo seriale.
• Gestione delle proprietà: chi è lo sviluppatore, quante volte il plugin abbia cambiato mani, se il vendor ha altri prodotti maintainati. La supply chain passa da questo: le fonti di aggiornamento alternate ai produttori solitari sono un campanello da minimo approfondire — l'argomento l'ho trattata per esteso nell'articolo sugli aggiornamenti infetti.
• Qualità del codice alla prima apertura: apertura del codice nel repo (aiuto: usa il browser del plugin o GitHub con un test di PHPCompatibility); se non aggiunte, il test automatico con PHPCompatibilityWP è un passo che mostra nascosto di quanto il review della directory non ha tempo di vedere.
• Dipendenze dichiarate: plugin che tirano dentro librerie Jensen e senza versione sono un costo che pagherai. L'eterno problema dei plugin che non dichiarano minimi: installali solo se puoi testare in staging.
• Compatibilità con ecosistema: chi lo sviluppa il plugin dichiara compatibilità con WPML/WooCommerce/pagamenti? La testimonianza giusta è quella dei fix di conflitto: un vendor che risolve i conflitti in ore è un vendor che reggerà gli aggiornamenti.

""E nessun criterio singolo acquista garantía totale: è l'ordine dei segnali a fare la differenza, non la somma."

Il caso: la scelta tra due candidati con lo stesso score

Il caso concreto da raccontare arriva da un audit di fine estate, un multisito di un cliente media. Due candidati per la stessa funzione — gestione avanzate di redirect — con punteggi apparentemente identici nella directory: entrambi attivi, entrambi nei primi due risultati di ricerca, entrambe da sviluppatori sconosciuti. La differenza emergeva solo con l'indagine: il primo plugin aveva un repo GitHub pulito, un changelog che spiegava in modo dettagliato le CVE di 14 mesi prima e i test corrispondenti; l'altro aveva 5 versioni in un anno, ognuna con «fix vari». Ho messo il primo: non per il numero, ma per il tipo di storia che il che log raccontava. Il secondo, sei mesi dopo, è finito in un advisory di sicurezza pubblico. Il punto non è stato readme sentiment: era pattern: il ritmo a cui risponde ai bug e il dettaglio con cui scrive i fix. Più conti l'ordine di integrità (il changelog e la cache di supporto)၌ sugli indicatori aggregati, meno ti ingannano i numeri grossi.

Le proposte di Carbis: cosa converrà guardare nel prossimo anno

Le proposte di Carbis nel talk meritano una sintesi perché, se anche parzialmente adottate, cambieranno la vita a chi gestisce un parco siti. La prima è il collegamento nominale tra account wordpress.org e installazioni reali: oggi la directory non sa chi usa davvero il plugin, e questo rende tutti gli indicatori (installazioni, recensioni) vulnerabili. La seconda: un entro norme ufficiale per il commercial plugin — da anni il mercato dei premium vive su canali esterni senza controlli equivalenti, e una marketplace ufficiale sotto la qualità di revisore core toglierebbe l'acquisto al buio. La terza: parte dei proventi destinati ai contributori core e agli eventi della community — un'automazione economica che allinei gli interessi di chi revisiona con di chi gode dell'ecosistema. Su tutti e tre i fronti ho la stessa posizione: la direzione è giusta, la specifica è vecchia di anni, e il ritmo delle decisioni di governance è il vero collo di bottiglia. Il review team, nel frattempo, fa il possibile con ciò che ha — e merita più risorse e meno plugin generati a chain.

Il caso reale del repo abbandonato che sembrava vivo

Vale la pena raccontare un secondo caso, perché mostra il limite dei controlli automatici. A inizio estate un cliente voleva un plugin di import dati per un catalogo di 12.000 prodotti. Il candidato migliore per funzionalità e prezzo era un plugin con 40.000 installazioni attive, aggiornato "di recente" — solo che leggendo il changelog con attenzione ci si accorgeva che le ultime tre versioni erano state firmate da un maintainer diverso da quello storico, e che l'ultimo commit sostanziale nel repository era di nove mesi prima. Gli aggiornamenti recenti erano solo "testato fino a WP X.Y" — la firma minima per passare la checklist del review, non uno sviluppo vivo. Segnale sottile, ma decisivo: il progetto era ufficialmente vivo e reicamente mantenuto da un'azienda che in realtà aveva lasciato solo il filo dell'automazione. L'abbiamo scartato. Due mesi dopo il vendor ha annunciato la dismissione del prodotto. Il segnale da leggere era già lì: il changelog mentiva in modo legale.

La lezione operativa è questa: il changelog e la pagina del repo sono i luoghi dove un plugin racconta la verità — marketing e descrizioni atan mere di illustrazione. Se vuoi puoi anche interpellare lo sviluppatore con una domanda tecnica semplice sulle versioni: il tempo di risposta misura più della pagina vendite, e il venditore che risponde in dettaglio domani ti risponderà anche quando il bug è su un sito in produzione.

Le risposte alle domande ricorrenti

Chi gestisce siti se le pone, quindi le affronto in modo diretto. "Faccio sempre il test in staging, non è ridondante?": per un sito che genera reddito, no — il costo dell'update in staging è 20 minuti; il costo di un'incompatibilità in produzione è un ordine di grandezza superiore, e in più il plugin va testato assieme agli altri, perché i conflitti sono la forma prevalente di fallimento. "Meglio meno plugin multifunzione o più plugin piccoli?": meglio la specializzazione — ogni plugin in più è una superficie di attacco e una variabile di conflitto, ma sostituire un robusto con tre strumenti fragili è peggio. Conta la manutenzione del vendor, non il numero. "I plugin premium sono più sicuri?": non per definizione — il pentest su Avada di agosto ha mostrato come offerta a pagamento nona sia sinonimo di qualità del codice, e il lancio della marketplace ufficiale discusso da Carbis nasce proprio dal fatto che i canali commerciali oggi non sono più controllati del gratuito.

Serve una fase di valutazione umana? Sempre. I tool di sicurezza — scanner, integrità dei file, audit automatico — filtrano e allertano, e sono i primi a cui delego il controllo periodico nel parco siti che seguo. Ma il giudizio finale sul plugin che regge, quale versione installare, quando rimandare l'update di una versione akù là, resta umano. È la parte che nell'assistenza WordPress mettiamo in contratto con soglie ed escrow, e che fa la differenza tra un update gestito e un update subito.

La versione pratica per oggi, con WP-CLI

Finché la governance prende tempo, la tua protezione è la procedura minima che già raccontavo in sede di audit: lista dei plugin con versioni, verifica di canali di update sospetti, test in staging prima del deploy sui siti critici. Tre comandi che chiudono il cerchio:

# inventario completo con versione e stato di aggiornamento
wp plugin list --fields=name,status,version,update_version,update_package --format=csv
# elenco dei plugin che non hanno aggiornamenti disponibili da oltre 90 giorni (da integrare con audit manuale)
wp plugin list --status=active --field=name

Il metodo non sostituisce il giudizio: automatizza il controllo su base periodica, e lascia a te i casi ambigui. Per la manutenzione del parco siti, la routine mensile incapsula questi controlli in automatico, e l'assistenza WordPress mette in fila la parte di valutazione umana — che plugin tenere, quale sostituire, in che ordine aggiornare — che nessun tool riesce a fare stando da solo.

Cosa rimane nei prossimi dodici mesi

Torneremo su questo tema con certezza, perché la pressione generativa— editor AI che generano plugin per conto terzi — è appena iniziata e le infrastrutture di revisione si aggiornano più lentamente di quanto producano gli strumenti. La mia previsione, documentata sulle dinamiche in corso: entro un anno la directory introdurrà qualche forma di verifica dell'orgine — ownership verificata, badge di compatibilità testata, o un marketplace premium ufficiale — perché l'alternativa è un rischio che esaspera la fiducia dell'utente. Nel frattempo, questa guida ti lascia il punto più importante: la directory è il banco dei prodotti, non l'ente di certificazione. Il giudizio finale sul plugin che metti sul sito di un cliente resta il tuo, o di chi fa resta la manutenzione per te. E chi lo fa mette quello stesso giudizio in contratto: qui trovi come lo strutturiamo.

Riferimenti utili

• WP Tavern #218: Luke Carbis, il futuro dei plugin WordPress tra AI, etica e standard
• Directory plugin ufficiale WordPress
• Plugin WordPress senza patch: il playbook delle 3 decisioni
• Manutenzione WordPress: la routine mensile
• Assistenza WordPress: piani e interventi