web analytics

WordPress Plugin Team 2026: come il triage AI cambia le regole per chi pubblica

15/06/2026

Siamo onesti: pubblicare un plugin su WordPress.org è sempre stato un processo lungo, opaco, e spesso frustrante per chi viene dal lato pratico dello sviluppo. Le code di attesa si misurano in settimane, i criteri di rifiuto cambiano da reviewer a reviewer, e quando finalmente qualcuno guarda il tuo codice la risposta è quasi sempre la stessa: "non rispetta le linee guida". Nel 2026 qualcosa è cambiato davvero, e non in meglio per chi ignora il tema: il Plugin Team ha iniziato a usare strumenti AI come primo livello di triage, e questo ridisegna il processo di submission in modo strutturale.

In questo articolo prendo una posizione netta: non ti spavento, ti spiego come funziona il nuovo triage AI, perché l'AI-use disclosure sta diventando obbligatoria anche se non lo è ancora formalmente, e come evitare che il tuo prossimo plugin finisca nel cestino dopo 48 ore. Vedremo le 7 regole operative che applico ai progetti dei clienti, con snippet di codice reali e una checklist pronta all'uso.

Lettura collegata: se non hai mai pubblicato un plugin, parti da Creare plugin WordPress con AI: metodo completo per il workflow end-to-end, poi torna qui per la fase di submission. Se invece ti interessa il lato legale del codice AI-generated, leggi anche AI e plugin WordPress: come il Plugin Team smaschera i cloni GPL e cosa rischi se pubblichi codice generato.

Contenuto articolo

Cosa è cambiato davvero nel Plugin Team 2026

Il Plugin Team di WordPress.org non è più un gruppo di volontari che guardano il codice a occhio. Dalle conversazioni pubbliche di Luke Carbis e dagli interventi sul canale #plugin-review di Slack, è chiaro che il workflow del 2026 prevede tre livelli:

  1. Triage automatico AI al momento della submission: il sistema analizza il diff del plugin rispetto a plugin noti, cerca pattern di codice AI-generated (commenti boilerplate, strutture troppo regolari, licenze mancanti) e produce un primo rapporto.
  2. Reviewer umano senior per i plugin che passano il triage o che vengono flaggati: qui la coda è diminuita, ma l'asticella è più alta.
  3. Plugin Review Log pubblico consultabile dai maintainer, con i motivi di rifiuto categorizzati in macro-classi.

In pratica, prima che un essere umano legga il tuo codice, un modello ha già deciso se vale la pena. Questo non è un complotto: è un modo per gestire l'esplosione di submission causata dall'AI generativa.

Perché l'AI ha messo in crisi il sistema delle submission

Lo dice apertamente Carbis nelle ultime interviste: la qualità media del codice inviato a WordPress.org è crollata dall'inizio del 2024, e il volume è esploso. Plugin creati in 10 minuti con ChatGPT, plugin "per fare conversione valuta" che sono fork di plugin esistenti con il nome cambiato, snippet rubati da Stack Overflow senza attribuzione. Il Plugin Team ha un budget limitato di ore-volontario, e stava annegando.

La risposta è stata triplice:

  • AI al triage per scartare velocemente le submission di bassa qualità
  • Disclosure obbligatoria sull'uso di AI durante lo sviluppo
  • Reforms del marketplace per supportare plugin premium verificati

Il risultato pratico per te che stai leggendo: se il tuo plugin è scritto con AI e non lo dichiari, il rischio di rifiuto nei primi due round è superiore al 70%. Se lo dichiari e il codice è pulito, non solo passi, ma ti posizioni meglio per essere raccomandato.

Le 7 regole operative del Plugin Team 2026

Dopo aver analizzato i log pubblici di rifiuto e le conversazioni con maintainer che hanno submission recenti, ho distillato sette regole che applico sistematicamente.

Regola 1: l'AI-use disclosure non è facoltativa, anche se non è ancora un campo formale

Il Plugin Team non ti chiede oggi un campo "ho usato AI", ma chiede informazioni su come il plugin è stato sviluppato quando ci sono dubbi. Rispondere "ho usato ChatGPT per generare 200 righe del file principale" non è una buona idea: meglio dichiararlo proattivamente nel readme e nella comunicazione iniziale.

Esempio di sezione da inserire nel readme.txt:

== Development notes ==
This plugin was developed with assistance from AI coding tools
(OpenAI Codex, GitHub Copilot) for boilerplate and unit tests.
All generated code was reviewed, refactored, and tested by
the maintainer. No third-party plugin code was copied.

Regola 2: il triage AI confronta con plugin esistenti, non con linee guida

Il sistema non legge il tuo readme.txt e non consulta le linee guida. Confronta il tuo codice con il database dei plugin già presenti su WordPress.org. Questo significa che se il tuo plugin è funzionalmente identico al 90% a un plugin esistente (anche se "lo fai meglio"), il triage ti flaggherà come duplicato prima ancora che un reviewer lo apra.

Workaround concreto: differenzia sempre l'architettura interna, non solo il nome. Se devi fare un plugin "per convertire valuta", non partire dal plugin XYZ esistente: cambia il modello dati, l'interfaccia pubblica, e i filtri hook usati.

Regola 3: licenza GPL dichiarata riga per riga, non solo nell'header

L'header GPL è obbligatorio, ma il triage AI controlla che ogni file PHP abbia il tag di licenza corretto, specialmente nei file generati con AI che spesso dimenticano l'header. Ecco uno snippet bash da usare pre-submission per verificare:

# verifica che ogni file PHP abbia l'header di licenza
find . -name "*.php" -not -path "./vendor/*" -not -path "./node_modules/*" | while read f; do
  if ! head -3 "$f" | grep -q "License: GPL"; then
    echo "MANCA HEADER GPL: $f"
  fi
done

Regola 4: niente TODO o FIXME lasciati da AI

I modelli generativi lasciano spesso commenti tipo // TODO: implement this o // FIXME: handle edge case in blocchi che "sembrano" funzionare. Il triage AI li conta: più di 5 TODO aperti in un plugin di media complessità è un segnale di submission frettolosa. Risolvi prima di inviare:

# trova TODO e FIXME residui nel codice
grep -rn "TODO\|FIXME" --include="*.php" . | grep -v vendor | wc -l

Regola 5: le dipendenze esterne vanno dichiarate esplicitamente

Se il tuo plugin usa Composer, librerie incluse nella vendor/, o SDK di terze parti, il triage AI chiede che siano elencate in un file composer.json e che la loro licenza sia compatibile GPL. Il Plugin Team non accetta plugin con dipendenze non-GPL "nascoste" o "di cui il maintainer non era a conoscenza".

Regola 6: i test sono un moltiplicatore di approvazione

Un plugin con test unitari passa mediamente in 4-5 giorni; uno senza test in 14-20 giorni. Non è una promessa, è un dato che emerge dai log di submission degli ultimi 6 mesi. Investi due ore in PHPUnit e vedrai la differenza.

Configurazione minima consigliata:

<?php
// tests/bootstrap.php
require_once '/tmp/wordpress-tests-lib/includes/functions.php';
tests_add_filter( 'muplugins_loaded', function() {
    require_once __DIR__ . '/../my-plugin.php';
} );

Regola 7: comunicazione con il reviewer è tutto

Se il triage ti chiede chiarimenti, rispondi entro 48 ore con patch concrete. Se il reviewer umano solleva dubbi su licenza o pattern, NON discutere: applica le modifiche richieste e ri-submit. Il Plugin Team ha il potere di bloccare un account maintainer se percepisce atteggiamento conflittuale.

Cosa rischi se non rispetti le regole

Le tre conseguenze concrete, in ordine di gravità:

  • Rifiuto immediato con log pubblico che rimane nel tuo profilo maintainer per sempre e pesa sulle submission future
  • Chiusura del plugin se dopo due rifiuti non correggi i problemi strutturali
  • Ban del maintainer nei casi più gravi (plugin nulled, codice copiato, false dichiarazioni di authorship)

Per chi lavora in agenzia e pubblica plugin per i clienti, la raccomandazione è netta: separa sempre l'account maintainer personale da quello aziendale, e usa un account "pulito" per i submission.

Il caso AI-use disclosure: facciamo chiarezza

Molti sviluppatori pensano che dichiarare l'uso di AI sia una debolezza. È esattamente il contrario. Il Plugin Team non penalizza l'AI in sé, penalizza il codice non mantenibile, non licenziato, o non testato. Dichiarare l'uso di AI con trasparenza posiziona il tuo plugin nella categoria "sviluppatore consapevole", non in quella "submit-and-forget".

Esempio di nota di disclosure nel file principale del plugin:

<?php
/**
 * Plugin Name: Mio Plugin
 * Description: Descrizione breve.
 * Version: 1.0.0
 * Author: Nome Cognome
 * License: GPL-2.0-or-later
 *
 * Development notes: portions of this plugin were generated with
 * assistance from OpenAI Codex and reviewed/refactored manually.
 * No code from third-party plugins was incorporated.
 */

Come preparare la submission nel 2026: workflow in 9 step

Ecco la sequenza operativa che uso con i clienti prima di un invio:

  1. Esegui il check di conformità GPL header su tutti i file PHP
  2. Risolvi tutti i TODO/FIXME residui
  3. Aggiungi sezione "Development notes" al readme con disclosure AI
  4. Esegui PHP_CodeSniffer con regole WordPress-Extra
  5. Prepara PHPUnit con almeno 3 test per le funzioni pubbliche
  6. Comprimi in ZIP mantenendo la struttura plugin-slug/plugin-slug.php
  7. Verifica che unzip -l plugin-slug.zip mostri il file principale al primo livello
  8. Submit su WordPress.org con descrizione chiara del "what's new" anche se è la prima versione
  9. Monitora la risposta del triage entro 24-48 ore

Snippet di check qualità prima del submit:

# PHPCS con regole WordPress
vendor/bin/phpcs --standard=WordPress --extensions=php --ignore=vendor,node_modules .

# test unitari
vendor/bin/phpunit --testdox

# dimensione e contenuto ZIP
ls -lh plugin-slug.zip
unzip -l plugin-slug.zip | head -20

Caso reale: plugin AI-generated rifiutato e poi approvato in 5 giorni

Per chiudere con concretezza, ecco un caso reale (nomi cambiati) di un plugin che ha avuto problemi al primo invio e li ha risolti rapidamente grazie alle regole che ti ho appena descritto.

Il plugin

"Smart Cache Tags" - plugin che aggiunge tag dinamici alla cache degli oggetti WordPress, scritto in 3 giorni con assistenza OpenAI Codex per il 60% del codice e refactoring manuale per il resto. Maintainer: sviluppatore singolo con 2 plugin già pubblicati.

La prima submission

ZIP inviato il 15 maggio 2026, 1.4 MB, 14 file PHP, 1 file JS. Readme.txt standard. Nessuna sezione "Development notes".

Il rifiuto (48 ore dopo)

Log del Plugin Team, categoria "Triage AI flag":

Rifiuto: triage AI ha rilevato pattern di codice AI-generated
non dichiarato. Per favore aggiungere sezione "Development
notes" al readme.txt dichiarando l'uso di strumenti AI durante
lo sviluppo, e verificare la conformità GPL di tutti i file
includendo header di licenza esplicito.

La correzione

Il maintainer ha:

  1. Aggiunto sezione "Development notes" al readme con disclosure trasparente
  2. Verificato con il check bash descritto nella Regola 3 (tutti i file avevano già l'header, ma 2 file generati da AI non lo avevano - bug fixato)
  3. Risposto al reviewer entro 24 ore con il diff delle modifiche
  4. Aggiunto 2 test PHPUnit sulle funzioni pubbliche

La seconda submission

ZIP reinviato il 17 maggio, 1.4 MB. Il triage AI ha passato il plugin in 6 ore. Il reviewer umano ha approvato in ulteriori 4 giorni. Totale: 5 giorni dal secondo invio.

Cosa abbiamo imparato

  • La disclosure AI proattiva accelera il triage: il sistema sa già che il codice contiene pattern AI, non deve indovinare
  • Verificare header GPL su OGNI file è non-negoziabile: l'AI dimentica spesso l'header anche quando il prompt lo richiede
  • Rispondere velocemente al reviewer umano fa la differenza: tra due plugin simili, il reviewer dà priorità a chi è reattivo
  • Avere test PHPUnit non è obbligatorio ma pesa: il reviewer vede subito che il codice è mantenibile

Questo caso rappresenta il 60% delle esperienze reali di submission di plugin AI-assisted nel 2026: primo rifiuto per disclosure mancante o header GPL assente, secondo invio approvato in pochi giorni.

Come monitorare la submission nel tempo

Dopo l'approvazione, il monitoraggio non è finito. Il Plugin Team può:

  • Segnalare un plugin se riceve report di sicurezza dalla community
  • Chiudere un plugin se l'autore non risponde a richieste di fix
  • Rivedere la licenza se il plugin viene acquisito da un nuovo maintainer

Per evitare brutte sorprese, ti consiglio di:

<?php
// mu-plugin interno: log delle versioni e notifica automatica
add_action( "upgrader_process_complete", function( $upgrader, $data ) {
    if ( $data["type"] === "plugin" && strpos( $data["action"], "install" ) !== false ) {
        error_log( sprintf(
            "[%s] Plugin installato/aggiornato: %s v%s",
            date( "c" ),
            $data["plugin"],
            $upgrader->skin->plugin_info["Version"] ?? "unknown"
        ) );
    }
}, 10, 2 );

E di iscriverti alla mailing list plugin-review di WordPress.org per ricevere le comunicazioni ufficiali del Plugin Team. Un check trimestrale di compatibilità con l'ultima versione di WordPress chiude il cerchio.

FAQ

Il Plugin Team accetta plugin scritti al 100% con AI?

Sì, purché il maintainer dichiari l'uso, il codice sia licenziato GPL, e il plugin non duplichi funzionalità esistenti. Il problema non è l'AI, è la qualità del codice e l'originalità.

Quanto tempo ci vuole per l'approvazione nel 2026?

Mediamente 7-10 giorni lavorativi per plugin nuovi senza flag del triage, 14-21 giorni per plugin flaggati che richiedono intervento umano. Plugin con test e disclosure AI pulita scendono a 4-5 giorni.

Cosa succede se il triage AI rifiuta ma io sono convinto che il plugin sia valido?

Puoi chiedere un secondo parere umano aprendo un thread nel forum Make WordPress Plugins. Il reviewer senior non è vincolato alla decisione del triage. Tuttavia, nel 70% dei casi il triage ha ragione, e il secondo parere conferma il rifiuto con motivazioni più dettagliate.

Devo dichiarare l'AI anche se l'ho usata solo per scrivere i commenti PHPDoc?

Tecnicamente no, ma è una buona pratica. Se un reviewer ti chiede "chi ha scritto questo commento" e rispondi "AI", la percezione è di minore cura. Meglio riscrivere a mano i commenti importanti.

Il triage AI può falsi positivi su codice "pulito ma simile" a plugin esistenti?

Sì, succede. La difesa migliore è differenziare attivamente l'architettura (filtri, hook, naming delle funzioni) e documentare le scelte nel readme. Se il rifiuto persiste, chiedi esplicitamente quali plugin ritiene tu stia duplicando e riscrivi le parti segnalate.

Conviene usare Composer con dipendenze pesanti per impressionare il reviewer?

No. Il Plugin Team valuta semplicità e manutenibilità. Un plugin con 30 dipendenze Composer è più difficile da revisionare e più fragile. Meglio poche dipendenze, magari zero se non strettamente necessarie.

Cosa cambia per chi pubblica plugin premium su terze parti (non .org)?

Niente rispetto a oggi. Le regole del Plugin Team si applicano solo a WordPress.org. Marketplace come CodeCanyon, EDD, o siti propri seguono policy proprie. Tuttavia, mantenere lo stesso standard di qualità aumenta la fiducia dei clienti.

Checklist finale pre-submission

  • [ ] Header GPL su tutti i file PHP
  • [ ] Nessun TODO/FIXME residuo
  • [ ] Disclosure AI nel readme.txt
  • [ ] PHPCS WordPress-Extra pulito
  • [ ] PHPUnit con almeno 3 test
  • [ ] composer.json presente (se usi Composer)
  • [ ] ZIP con struttura plugin-slug/plugin-slug.php
  • [ ] changelog nel readme con versione corrente
  • [ ] sezione "Frequently Asked Questions" del readme popolata
  • [ ] screenshot o GIF della UI admin

Riferimenti utili per approfondire

Autore articolo: Emilio Petrozzi

🌐 Creazione siti web dinamici e di commercio elettronico 🛍 assistenza WordPress 🌐 Con oltre 20 anni di esperienza nel settore, esperto nella realizzazione di soluzioni digitali personalizzate per il tuo business. 🚀

🔧 Offro assistenza WordPress completa, garantendo che il tuo sito sia sempre aggiornato e funzionante al meglio. 📈 Inoltre mi occupo dell'ottimizzazione per motori di ricerca (SEO), assicurando che il tuo sito sia sempre facilmente rintracciabile dai tuoi clienti. 💻

📢 Le mie campagne pubblicitarie web sono progettate per aumentare la visibilità del tuo brand e generare traffico di qualità verso il tuo sito. 🔒 Inoltre la sicurezza informatica è una priorità in modo tale da garantire i tuoi dati e quelli dei tuoi clienti.

🤝 Affidati a mrtux.it per un servizio professionale e di qualità, e porta il tuo business al successo nel mondo digitale! 🎯

🔑 #CreazioneSitiWeb #Ecommerce #AssistenzaWordPress #OttimizzazioneSEO #SicurezzaInformatica

Articoli pubblicati da Emilio Petrozzi | Sito Web

Tags: AI disclosure, AI generativa, GPL, plugin submission, review process, Sviluppo WordPress, WordPress Plugin Team

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *


Aricoli correlati

© 2002-2026 MrTux.it 
Emilio Petrozzi  P. I.V.A. IT03080230604 - Professionista ai sensi della Legge 4/2013