In attesa
Il tuo plugin WordPress è in attesa: cosa significa davvero ogni motivo di rifiuto
L'email del team di revisione è breve e vaga di proposito. Ecco cosa significa davvero ogni motivo, cosa lo innesca e cosa sblocca sul serio.
Hai inviato un plugin a wordpress.org. Due settimane dopo arriva un'email da plugins@wordpress.org che dice che il tuo plugin è stato trattenuto per i seguenti motivi, seguita da tre o quattro paragrafi brevi che sembrano spiegarsi da soli e non lo fanno.
Quell'email l'ho ricevuta. Due volte, sullo stesso plugin, per due motivi diversi. Quello che segue è ciò che ogni motivo significa davvero — compresi i due errori che ho commesso e pagato in settimane di attesa.
Non sollecitarli
La loro email lo dice, ed è vero: le richieste di stato rallentano la coda. Una revisione richiede da una a sei settimane. Non esiste alcuna corsia veloce.
Non discutere
Il team di revisione non è un'assistenza con cui trattare. Ogni minuto speso a spiegare perché il tuo caso è diverso è un minuto non speso a correggere.
Incolla l'email che hai ricevuto.
Il team di revisione scrive in inglese qualunque sia la tua lingua. Incolla il loro messaggio: questa pagina ti dice a quale dei sette motivi hai davvero a che fare — e cosa ciascuno si aspetta da te.
Tutto avviene nel tuo browser. Niente viene inviato da nessuna parte, niente viene conservato, dietro non c'è alcun server.
Prima di tutto, come funziona davvero la revisione
- 01
Riesaminano tutto ogni volta
Non confrontano il nuovo invio con la versione precedente. Un problema non citato la prima volta può emergere al secondo giro — e un changelog dettagliato nella tua risposta è fatica sprecata.
- 02
Leggono il codice sorgente
Non solo il readme, non solo gli header. Spostare un controllo in un punto meno visibile o rinominare una funzione non funziona, e trasforma un'obiezione tecnica in un problema di fiducia.
- 03
La loro email è scarna di proposito
Gestiscono una coda enorme con volontari. Ogni frase pesa: rileggi la loro email come un passaggio a sé, frase per frase, quando pensi di aver finito.
I sette motivi
Scegli quello che corrisponde alla tua email. Ogni scheda porta a cosa lo innesca e a cosa passa.
Guideline 5, il «trialware»
Un plugin non può limitare funzionalità che vengono eseguite interamente sull'installazione dell'utente.
Cosa lo innesca
- Una funzione che gira interamente sul server dell'utente, limitata artificialmente, con un piano a pagamento per sbloccarla
- Il caso da manuale: una modalità «usa la tua chiave API» limitata a N usi al mese — la chiave la mette l'utente, il fornitore lo paga l'utente, il calcolo non ti costa nulla
- Nota cosa non è il problema: far pagare è consentito, avere una versione Pro è consentito
Cosa passa
- Togliere il limite da tutto ciò che gira in locale
- Spostare la funzione lato server, a tue spese — così il limite riflette una spesa reale, e la Guideline 6 lo consente esplicitamente
- Vendere assistenza, aggiornamenti o un servizio ospitato — tutto tranne lo sblocco di codice che gira già sulla macchina dell'utente
Cosa ha funzionato davvero, e mi ha sorpreso
La mia prima correzione teneva la modalità locale togliendole solo il tetto, accanto a un nuovo servizio gestito. Era conforme. Era anche fragile da spiegare, perché lasciava a un revisore due percorsi di codice da valutare e la mia parola su quale si applicasse il prezzo.
La versione che è passata eliminava del tutto la modalità locale. Se non c'è codice locale, la Guideline 5 non si applica affatto. Una posizione di conformità semplice batte una difendibile.
Ordine di grandezza: non è una toppa. Per me ha voluto dire cancellare un'intera modalità, montare un Cloudflare Worker con la mia chiave API, collegare i webhook di licenza con validazione della firma, aggiungere le quote per installazione e riscrivere l'intera catena di generazione. Conoscere la risposta è costato un'ora. Consegnarla, giorni.
Collisione di nome e marchio
non solo nel nome — comprende … gli URL di questo plugin
Cosa lo innesca
- Il nome visualizzato, lo slug, il text domain, il Plugin URI, ogni link nella tua interfaccia di amministrazione, il readme, l'utente contributore e il dominio stesso
- Un conflitto fuori da WordPress: progetti tecnologici estranei, GitHub, npm, prodotti SaaS, registri di marchi
- Un nome sostitutivo che non è dimostrabilmente tuo — il permesso dell'altro titolare non risolve nulla
Cosa passa
- Un nome puramente descrittivo non può collidere con il marchio di nessuno
- La mossa più sicura: prendere la metà descrittiva del nome che suggeriscono loro e togliere l'identificativo — l'hanno scritto loro, difficilmente lo diranno ingannevole
- Metti il ripiego nella stessa email, altrimenti ti compri un altro giro da una a sei settimane
- Verificare che uno slug sia libero: api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=IL-TUO-SLUG restituisce «Plugin not found.» quando è disponibile
Tre rinomine sopravvissute a un grep che avevo dichiarato pulito
Il nome spezzato da un tag HTML. Il logo del mio sito era scritto Plug<span class="dot">Forge</span>. Nessuna ricerca sul nome intero lo trova — ed era l'elemento più visibile di ogni pagina.
Uno slug ancora più vecchio. Decine di link puntavano ancora al primo nome del plugin, abbandonato due rinomine prima, incluso il pulsante principale. Cerca tutti i nomi morti, non solo l'ultimo.
Ciò che esce sulla rete. Un worker in background inviava il vecchio nome nel suo User-Agent a ogni sito terzo che toccava. Invisibile a schermo, del tutto reale per i server che lo ricevevano.
La riga Contributors
Cosa lo innesca
- Il titolare dell'account wordpress.org che invia il plugin non compare nella riga Contributors: del readme
- Sfugge spesso proprio perché la riga esiste già con altri nomi dentro — l'autore di un framework, un SDK di fatturazione — e quindi non sembra vuota
Cosa passa
- Aggiungi l'identificativo dell'account che invia in Contributors:
- Se stai risolvendo anche una questione di marchio, controlla quella riga: un contributore costruito sul nome rifiutato contraddice l'intera rinomina
Plugin URI rotto
Cosa lo innesca
- L'URL restituisce un 404 — correzione tecnica
- L'URL contiene ancora il nome in conflitto — è un problema di marchio, vedi il motivo 02
- L'URL punta alla home della tua agenzia invece che a questo plugin in particolare
Cosa passa
- Verificalo dal vivo, non nel file: un URL corretto nei sorgenti ma mai pubblicato resta un motivo di rifiuto
- Prima di rispondere, apri davvero ogni URL contenuto nella tua proposta
Servizi esterni non documentati
Cosa lo innesca
- Una chiamata in uscita non documentata in una sezione External Services del readme: cosa viene inviato, quando e a quale fornitore
- Una descrizione che non corrisponde più al codice inviato — peggio di nessuna descrizione, perché si legge come occultamento e non come svista
Cosa passa
- Scrivi quella sezione per ultima, quando l'architettura ha smesso di muoversi
- Controlla che l'informativa sulla privacy che colleghi da lì dica la stessa cosa
- Nomina ogni endpoint che il plugin chiama davvero, sul dominio che chiama davvero
Quella che è quasi passata
La mia informativa sulla privacy diceva ancora che il plugin inviava l'URL di un'immagine, molto dopo che il codice era passato a inviare l'immagine stessa. Due documenti ufficiali che si contraddicono su cosa esce dal server dell'utente sono esattamente il tipo di discrepanza per cui questa sezione esiste. L'ho trovato un'ora prima di reinviare, in un ultimo passaggio, quando tutto il resto era già stato dichiarato pulito.
Un segreto spedito nello ZIP pubblico
Cosa lo innesca
- Alcuni SDK di licenza scrivono un segreto in chiaro nel file principale — il codice generato a volte lo dice, in un commento
- Un archivio montato a mano invece che con lo strumento di build dell'SDK, che rimuove il segreto automaticamente
Cosa passa
- Se costruisci l'archivio da solo, scompattalo e fai un grep prima di caricare
- Dieci secondi di verifica contro un guasto definitivo una volta pubblicato
«Questa categoria è affollata»
Cosa lo innesca
- Un'osservazione sulla saturazione della tua categoria — non è un punto di conformità e da sola non blocca l'approvazione
Cosa passa
- Rispondi con una differenza tecnica verificabile, non con un argomento di marketing
- Resisti al «meglio di X»: è infalsificabile, e un team di revisione che lo legge si fiderà meno del resto della tua proposta
Come rispondere
La loro indicazione va seguita alla lettera: sii breve e non elencare le modifiche. Riesaminano tutto da zero, quindi un changelog è solo rumore.
- La conferma di ciò che è cambiato, in una o due frasi — la posizione, non il diff
- In caso di rinomina, una richiesta esplicita di riservare il nuovo slug — non lo fanno da soli
- La tua opzione di ripiego, se resta qualche dubbio
Carica la versione corretta dalla pagina «Add your plugin», con l'account che ha inviato — non come allegato di un'email. Una pagina di make.wordpress.org del 2015 dice il contrario; non è aggiornata. L'avviso «Text Domain» al caricamento è normale finché non riservano il tuo slug.
La lista che scorro prima di reinviare
Ogni riga nasce da un punto che ho sbagliato. Spuntale: il browser se ne ricorda.
L'ultima riga è quella che ha contato di più: tredici passaggi di rilettura sul mio codice non hanno visto tre bug bloccanti, e ognuno è emerso nei primi cinque minuti di esecuzione reale. Si legge il codice per trovare ciò che è sbagliato. Lo si esegue per trovare ciò che manca.
Quanto costa davvero
Per una correzione di conformità semplice — documentazione, header, contributors, URL — qualche ora è realistico.
Per la Guideline 5, sii onesto con te stesso: stai cambiando il modello di business del prodotto e probabilmente costruendo infrastruttura lato server che non avevi. Tra il primo rifiuto e il reinvio finale sono passati nove giorni, due nomi rifiutati, un Cloudflare Worker, un'integrazione di webhook e tre bug emersi solo quando ho smesso di leggere e ho iniziato a eseguire.
Le linee guida non sono arbitrarie, e una volta visto lo schema dietro sono coerenti: la directory ospita software libero che funziona, e tutto è giudicato in base a questo.
Lo faccio per altri autori di plugin: ogni punto dell'email di rifiuto affrontato, verificate anche le linee guida non ancora sollevate, e la risposta scritta perché tu debba solo inviarla.