Share
Quando ti stai avvicinando al completamento del tuo plug-in WordPress, è il momento di iniziare a pensare di rilasciarlo al pubblico più ampio. Prepararsi per pubblicare un plug-in richiede molto lucidatura, test e messa a punto, ed è facile dimenticare alcuni passaggi del processo. Questo tutorial ti guiderà attraverso la pubblicazione del plug-in nella directory dei plug-in di WordPress e funzionerà come una check list per aiutarti ad assicurarti che il tuo plug-in sarà pronto per la prima volta nel momento in cui premi.
Alcuni passaggi, come l'impostazione del progetto, vengono eseguiti una volta nella vita di ogni plug-in, mentre molti sono importanti ogni volta che si rilascia una nuova versione del plug-in. Ecco perché può essere una buona idea aggiungere un segnalibro a questo tutorial e tornare ad esso quando è il momento di fare il tuo prossimo aggiornamento.
La directory dei plugin su WordPress.org è per WordPress che cos'è AppStore per iPhone: il modo più semplice e veloce per trovare i plugin per WordPress. Mentre è possibile pubblicare il tuo plug-in come file zip scaricato dal tuo sito web, ad ogni versione, l'integrazione tra WordPress e la sua directory di plugin diventa più stretta.
Rilasciando il tuo plug-in attraverso la directory dei plug-in, rendi più semplice per i tuoi potenziali utenti trovare il tuo plug-in e tenerlo aggiornato man mano che crei nuove versioni. Saranno in grado di installare il plug-in senza dover uscire dalla dashboard di amministrazione di WordPress e, naturalmente, la maggior parte degli utenti di WordPress conosce già la directory dei plug-in e la sfoglia quando cerca i plugin per soddisfare le loro esigenze. Tu, d'altra parte, riceverai statistiche di download, feedback dagli utenti attraverso la pagina del plugin nella directory dei plugin, e un repository di sovversione gratuito per l'archiviazione dei file del tuo plugin e della cronologia delle versioni.
C'è un motivo per non ospitare il tuo plugin nella directory dei plugin? Se il tuo plugin è commerciale, potresti volerlo ospitare altrove (il tuo sito o un mercato, come Codecanyon di Envato), poiché la directory dei plugin è aperta e non ha supporto per fare soldi con i tuoi plugin. Tutto ciò che viene pubblicato nella directory dei plugin di WordPress è liberamente scaricabile da tutti.
Ecco le regole per i plug-in ospitati nella directory, presi dalle istruzioni del Plugin Directory:
Ci sono solo alcune restrizioni:
Una volta deciso di ospitare il tuo plug-in nella directory dei plugin di WordPress, il primo passo è creare un account utente di WordPress.org. Per ottenerne uno, visita la directory dei plugin e fai clic su "Registrare" link nella parte superiore destra della pagina, proprio accanto al prompt di accesso.
Dopo aver registrato il tuo account utente, puoi richiedere a WordPress di aggiungere il tuo plug-in seguendo questo link che porta a una pagina simile allo screenshot qui sotto.
Compila il modulo e spiega brevemente di cosa tratta il tuo plugin. Sii il più specifico possibile mentre stai in una lunghezza ragionevole. Se il tuo plugin ha già un sito web, inserisci l'URL nel campo "URL del plugin".
Prima che il tuo progetto venga creato, qualcuno dello staff di WordPress leggerà la tua richiesta e la approverà. Mentre WordPress non promette quanto ci vorrà, dicendo che ti rispediranno in "un po 'di tempo vagamente definito", il tempo è calcolato in ore o giorni anziché settimane - molto probabilmente, avrai il tuo plugin impostare entro 24 ore dall'invio della richiesta.
Una volta che il tuo plugin è stato approvato, riceverai un'email con il tuo nuovo sito web del progetto e l'URL SVN al suo interno. Osserva l'URL del repository, poiché lo utilizzeremo pesantemente nei passaggi successivi.
Nei seguenti passaggi, supporrò che tu abbia almeno una certa dimestichezza con SVN, quindi se non hai idea di cosa sia SVN, sfoglia un tutorial prima di continuare con il passaggio successivo.
Su Mac e la maggior parte degli aromi (se non tutti) di Linux, un client SVN a linea di comando viene fornito con il sistema operativo. In Windows, puoi installare tu stesso il client della riga di comando o andare con un client grafico come Tortoise SVN. Su Mac, Versions è un client grafico molto carino.
Per ottenere il massimo dal repository SVN fornito da WordPress, lo configureremo in modo che la versione di sviluppo del plugin venga salvata in
La directory plugin legge il tag da cui dovrebbe essere distribuita la tua versione stabile corrente controllando il file readme.txt tronco. Tratterò questo argomento più dettagliatamente nel prossimo passaggio mentre esaminiamo i contenuti del readme.txt file che dovrebbe essere incluso con il plugin.
Prima, tuttavia, passiamo attraverso i comandi SVN che userete la maggior parte del tempo. Non preoccuparti se non ti piace scrivere comandi nel terminale, vai avanti e usa il tuo client SVN grafico preferito.
Iniziamo verificando il progetto da SVN. In questo momento, il progetto è ancora vuoto, quindi nulla al di fuori di una directory vuota viene aggiunta al tuo computer.
$ svn co http: //[email protected]/your-plugin/trunk local-path
Copia o sposta il codice del plugin in quella directory (percorso locale) creata dal comando svn e aggiungi i file in SVN. All'interno della directory, digitare:
$ svn aggiungi percorso file
percorso del file può essere un percorso per un file specifico o un carattere jolly come * .php. Questo segnerà i file da aggiungere al repository SVN nel prossimo svn commit - nulla è ancora impegnato. Se non sei sicuro di quali file hai già aggiunto, puoi controllare lo stato SVN di ogni file nella directory di lavoro corrente:
$ svn stato
Infine, quando tutto è pronto per essere inviato al repository SVN, impegnare i file. Non aver paura di commettere spesso: finché il "tag Stable" punta ad altre directory piuttosto che trunk, i tuoi commit non avranno alcun effetto sulla versione già pubblicata. In questo modo sei al sicuro in caso di perdita della copia locale del codice per qualche motivo.
$ svn commit -m "Una breve spiegazione di cosa è stato cambiato"
Prima che il tuo progetto possa essere mostrato nella directory dei plugin, dovrai comunque aggiungere il file readme.txt. Ma prima di approfondire, è tempo di testare il tuo plugin.
Anche se i tuoi utenti non pagano per usare il tuo plugin, il rilascio di un plug-in senza prima testarlo non è mai una buona idea. Nell'open source, la gente tollera qualche rilasci di tanto in tanto se risolvi i bug velocemente e sei pronto a rispondere alle loro segnalazioni di bug, ma se ogni singola release esce con degli errori gravi, prima o poi, i tuoi utenti passerà ad altri plugin simili.
Allo stesso tempo, dobbiamo tenere presente che, in qualità di unici sviluppatori o piccoli team, le nostre risorse per i test sono limitate. Se si è fortunati, è possibile che qualcuno al di fuori del team collauda il proprio plug-in, ma molto spesso, è solo lo sviluppatore a fare il test. Questo è il motivo per cui è importante creare un piano di test chiaro, semplice e attuabile.
Per crearne uno, segui i seguenti consigli e scegli i suggerimenti che funzionano per te e personalizzali in base alla tua esperienza e alle specifiche del plug-in che stai per rilasciare.
Sono il primo ad ammettere di non essere uno sviluppatore perfetto. Anche se conosco i miei punti deboli, tendo a ripetere i miei errori. Ecco perché, nella mia procedura di test, cerco di mantenere un elenco aggiornato dei tipi di bug che si verificano più spesso nel mio codice e test che devo fare prima di ogni rilascio per cogliere i miei errori più comuni.
Questo è chiamato test di regressione, ed è una delle forme più importanti di test: di solito, le nuove funzionalità vengono testate abbastanza bene mentre le sviluppi, ma allo stesso tempo potresti introdurre bug ad altre parti del codice che hai già considerato completo.
Per cogliere questi bug, crea un elenco di test per verificare le funzionalità principali del tuo plug-in e consulta l'elenco prima di ogni rilascio, anche se le tue modifiche non dovrebbero averli toccati.
Alcuni dei bug vengono visualizzati solo dai nuovi utenti che installano il plug-in per la prima volta, mentre altri si preoccupano solo degli utenti che eseguono l'aggiornamento da una versione precedente. Alcuni bug compaiono solo in un ambiente multiutente e così via.
Per essere sicuro di catturare il maggior numero possibile di problemi, è una buona idea creare diversi ambienti di test, almeno uno con una versione esistente del tuo plugin e l'altro una pulita installazione di WordPress.
Quando sai che il tuo prossimo rilascio crea nuove tabelle di database o cambia quelle esistenti, prova attentamente per vedere che il cambiamento che ti aspetti che accada in effetti lo fa e il database arriva allo stato finale corretto. La mia procedura di test dice sulla struttura del database:
Se la struttura del DB è cambiata:
- Verifica l'aggiornamento del database senza disattivare il plug-in
- Verifica l'aggiornamento del database con disattivazione / riattivazione
Si tratta di stati che non si notano se si esegue il plug-in semplicemente nel modo previsto, e quindi può richiedere molto tempo prima che si notino gli errori, a meno che non li si provi intenzionalmente.
Questo non è qualcosa che vuoi vedere in un pezzo di codice di gestione degli errori pensato per gestire il caso di errore con garbo:
Per assicurarti che il tuo plug-in funzioni con le modifiche introdotte nell'ultima versione di WordPress, è opportuno aggiornare sempre l'ambiente di test all'ultima versione prima di eseguire l'ultimo ciclo di test.
Passare attraverso il feedback degli utenti e vedere se ci sono bug che non hai ancora affrontato. Ignora le richieste di funzionalità per ora (ma scrivile in modo che tu possa usarle come input quando pianifichi la tua prossima versione) poiché non puoi comunque fare tutto in una versione. Credi sempre ai tuoi utenti quando dicono di aver trovato un bug, ma non aver paura di chiedere ulteriori informazioni per capirlo.
Se il tuo plug-in scrive HTML o CSS, decidi su un set di browser che supporti e testa il tuo plug-in su quei browser prima di ogni release.
Alcuni potenziali problemi sono più facili da trovare guardando il codice piuttosto che attraverso i test, quindi, ancora una volta, come nei test, è una buona idea tenere traccia dei punti deboli e scrivere un elenco di cose da verificare prima di pubblicare il plugin. Mentre rilasci più versioni, acquisisci più conoscenza su ciò che è importante testare in questo stesso progetto, quindi continua ad aggiornare l'elenco mentre impari, prendendo alcune cose e aggiungendo altre.
Ecco alcune idee da ricontrollare, raccolte dalla mia esperienza:
Quando gestisci i moduli inviati dall'utente, assicurati di convalidare correttamente gli attributi, nella sua forma più semplice usando il esc_attr metodo.
$ user_name = esc_attr ($ _ POST ["username"]);
se il tuo plugin non è scritto usando oggetti, ognuna delle tue funzioni si trova nello stesso spazio dei nomi con il resto del codice in WordPress e plugin installati. Per evitare che i nomi delle tue funzioni entrino in collisione con quelli di WordPress o altri plugin, inseriscili con un nome breve del plug-in.
function pluginname_print_error ($ message) ? // è più sicuro di: function print_error ($ message) ?
Passa attraverso tutti i tuoi commenti TODO o FIXME per vedere che non hai perso nulla su cui avevi pianificato di lavorare in seguito.
Se il tuo plugin supporta la localizzazione, prima di ogni versione, passa attraverso tutta la stringa del plugin per assicurarti che siano tutti marcati correttamente per la localizzazione. È facile dimenticarlo quando aggiungi nuove stringhe a un plug-in.
Accentsconagua
// usa $ text = __ ("Hello, world", "my_plugin"); // invece di solo $ text = "Hello, world" // e _e ("Hello!", "my_plugin"); // invece di echo "Hello!"; Nel codice WordPress, puoi trovare un documento che delinea lo stile di codifica da seguire nello sviluppo di plugin per la piattaforma WordPress. Anche se seguire questo documento non è obbligatorio, così facendo sarà più facile per altri sviluppatori aiutarvi con il plugin.
Controlla che ogni file nel tuo plugin contenga l'intestazione GPL e che license.txt della licenza GPL sia incluso nella cartella principale del tuo plugin.
/ * Copyright (c) 2011, il tuo nome. Questo programma è software libero; è possibile ridistribuirlo e / o modificarlo secondo i termini della GNU General Public License pubblicata dalla Free Software Foundation; la versione 2 della licenza o (a propria scelta) qualsiasi versione successiva. Questo programma è distribuito nella speranza che sia utile, ma SENZA ALCUNA GARANZIA; senza nemmeno la garanzia implicita di COMMERCIABILITÀ o IDONEITÀ PER UN PARTICOLARE SCOPO. Vedi la GNU General Public License per maggiori dettagli. Dovresti aver ricevuto una copia della GNU General Public License insieme a questo programma; in caso contrario, scrivere alla Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. * /
Ogni plugin impegnato nella directory dei plug-in di WordPress deve avere a readme.txt file formattato in base alle regole definite da questo modello. È importante seguire la formattazione come definita, quando si collega il plugin alla directory del plugin, questo file viene automaticamente convertito nella descrizione del plugin che si vede quando si sfogliano i plugin nella directory dei plugin.
Ad esempio, guarda come questo frammento dall'inizio del modello readme.txt viene convertito in informazioni presentate all'utente della directory del plugin:
=== Nome plugin === Collaboratori: markjaquith, mdawaffe (questo dovrebbe essere un elenco di userpress di wordpress.org) Link alla donazione: http://example.com/ Tags: commenti, spam Richiede almeno: 2.8 Testato fino a: 3.1.3 Tag stabile: 1_5_4
Copia il modello nella directory dei plug-in e inizia a modificarlo con informazioni specifiche per il tuo plug-in. Una volta che sei soddisfatto del tuo file readme.txt, testalo usando il validatore readme.txt fornito da WordPress prima di inviarlo a SVN.
Quando vedi questo nella parte superiore della pagina di convalida, sei pronto per eseguire il commit:
Ho menzionato il tag stable nel passaggio in cui abbiamo parlato del modo giusto di usare SVN nello sviluppo di plugin. Ora è il momento di iniziare a utilizzarlo: hai testato il tuo plug-in, hai ispezionato il tuo codice e hai scritto la documentazione. Non è rimasto nulla tranne il rilascio del plugin:
Cerca il file PHP principale del tuo plugin e aggiorna il commento inserendo il tuo numero di versione nel file "Versione:" campo:
/ * Nome plugin: A Plugin Version: 1.0 Plugin URI: http://wp.tutsplus.com Descrizione: My great plugin Autore: Jarkko Laine Autore URI: http://jarkkolaine.com * /
In readme.txt, ci sono due sezioni dedicate per documentare le modifiche alla tua versione: "changelog" e "Avviso di aggiornamento."Aggiungi una sezione per la tua nuova versione a Changelog, fornendo informazioni dettagliate su quali modifiche e correzioni di bug sono incluse in questa versione. Nota di aggiornamento è un breve (al massimo 300 caratteri) riassunto del motivo per cui vale la pena aggiornarlo a questa versione del plugin.
Ecco un esempio per una riga di log delle modifiche dal mio plug-in di donazione:
= 1.5.2 = * Correzione bug: risolto un bug di aggiornamento del database bug introdotto nella versione precedente * Correzione bug: risolto un bug relativo al passaggio della valuta selezionata a PayPal
Ancora dentro readme.txt, cerca la riga (quasi nella parte superiore del file) che dice "Tag stabile:"e aggiorna la riga con il nome del tag che utilizzerai per la tua prossima versione. La mia convenzione è stata quella di nominare il tag uguale al numero di versione con punti sostituiti da caratteri di sottolineatura (ad esempio il tag per la versione 1.0 sarebbe 1_0) Funziona piuttosto bene, ma è ancora meglio renderlo uguale al numero di versione:
Tag stabile: 1.0
In questo modo, quando qualcuno cerca una versione precedente del tuo plug-in nella pagina "Altre versioni", scoprirà facilmente quale tag appartiene a quale versione, come in questo esempio dal plug-in più popolare nella directory dei plug-in:
Applica le tue modifiche al file PHP principale del plugin e readme.txt. Quindi crea il tag che hai scelto per il tuo prossimo "tag stabile":
$ svn copia http: //[email protected]/your-plugin/trunk http: //[email protected]/your-plugin/tags/1.0 -m "Tagging una nuova versione "
Questo è: il readme.txt in tronco punta al tag corretto e tutto quello che devi fare è aspettare che il software automatico nella directory dei plugin noti le tue modifiche e aggiorni la directory. Ci vorrà circa mezz'ora prima che la nuova versione sia scaricabile dalla directory dei plugin e un paio d'ore in più prima che il tuo blog WordPress noti che è disponibile un aggiornamento per il plugin (se questo era un aggiornamento invece del primo commit).
Una volta che si nota l'aggiornamento nella directory dei plugin, scaricalo e prova ancora una volta solo per essere sicuro che ogni modifica e correzione siano state incluse correttamente nella versione corretta. Informa i tuoi amici e follower del plug-in, quindi attendi che il feedback si verifichi e guardi le tue statistiche di download.
Una volta che inizi a ricevere feedback, o se hai idee personali per migliorare il plugin, è bene continuare a distribuire nuove versioni ogni poche settimane circa. Questo mostrerà ai tuoi utenti che il tuo plug-in è ancora vivo e in fase di sviluppo attivo e li rende più propensi a investire il loro tempo in esso.
