Share
Når du kommer nær ved å fullføre WordPress-plugin-modulen, er det på tide å begynne å tenke på å slippe det ut til det bredere publikum. Å gjøre deg klar for å publisere et plugin krever mye polering, testing og finjustering, og det er lett å glemme noen skritt i prosessen. Denne opplæringen vil veilede deg gjennom publisering av plugin-modulen i WordPress-plugin-katalogen og fungerer som en sjekkliste for å hjelpe deg med at pluginet ditt er klart for topptid når du slår ut.
Noen av trinnene, for eksempel å sette opp prosjektet, gjøres en gang i hver plugins levetid, mens mange er viktige hver gang du slipper en ny versjon av plugin. Derfor kan det være lurt å bokmerke denne opplæringen og komme tilbake til det når det er på tide å gjøre din neste oppdatering.
Plugin katalogen på WordPress.org er å WordPress hva AppStore er for iPhone: Den enkleste og raskeste, innebygde måten å finne plugins for WordPress. Mens det er mulig å publisere plugin som en zip-fil som lastes ned fra ditt eget nettsted, blir integrasjonen mellom WordPress og dens plugin-katalog raskere.
Ved å slippe pluginet ditt gjennom plugin-katalogen, gjør det lettere for potensielle brukere å finne pluginet ditt og holde det oppdatert når du lager nye versjoner. De vil være i stand til å installere plugin-modulen uten å måtte gå ut av WordPress admin-dashbordet, og de fleste WordPress-brukere er selvsagt allerede godt kjent med plugin-katalogen og vil bla gjennom det når de ser etter plugins for å matche sine behov. Du vil derimot få nedlastingsstatistikk, tilbakemelding fra brukerne via plugin-siden i plugin-katalogen, og et gratis subversion-arkiv for lagring av pluginens filer og versjonshistorie.
Er det en grunn til ikke å være vert for plugin-modulen din i plugin-katalogen? Hvis pluginet ditt er kommersielt, kan du være vert for det andre steder (ditt eget nettsted eller et markedsplass, for eksempel Envato's Codecanyon) som plugin-katalogen er åpen og har ingen støtte for å tjene penger ut av pluginene dine. Alt som er lagt ut i WordPress-plugin-katalogen, kan lastes ned av alle.
Her er reglene for plugins hosted i katalogen, hentet fra Plugin Directory's instruksjoner:
Det er bare noen få restriksjoner:
Når du har bestemt deg for å være vert for plugin-modulen i WordPress-plugin-katalogen, er det første trinnet å opprette en WordPress.org-brukerkonto. For å få en, besøk plugin katalogen og klikk på "Registrere" lenke øverst til høyre på siden, rett ved siden av påloggingsprompten.
Etter å ha registrert brukerkontoen din, kan du be om at WordPress legger til plugin ved å følge denne lenken som fører til en side som ser ut som skjermbildet under.
Fyll ut skjemaet og forklar kort hva din plugin handler om. Vær så spesifikk du kan, mens du holder deg innenfor en rimelig lengde. Hvis din plugin allerede har et nettsted, skriv inn nettadressen i feltet "Plugin URL".
Før prosjektet ditt opprettes, vil noen fra WordPress-ansatte lese din forespørsel og godkjenne den. Mens WordPress ikke gir noen løfter om hvor lenge dette kan ta, sier de vil komme tilbake til deg i "litt vass definert tid", beregnes tiden i timer eller dager i stedet for uker - mest sannsynlig vil du ha pluginet ditt Sette opp innen 24 timer fra innsending av forespørselen.
Når pluginet ditt er godkjent, vil du motta en e-post med det nye prosjektets nettside og SVN-nettadressen i den. Legg merke til lagringsadressen, da vi vil bruke det tungt i de neste trinnene.
I de følgende trinnene vil jeg anta at du er minst kjent med SVN, så hvis du ikke har noen anelse om hva SVN er, skum gjennom en opplæring før du fortsetter til neste trinn.
På Mac og de fleste smaker (om ikke alle) av Linux, kommer en kommandolinje SVN-klient med operativsystemet. I Windows kan du enten installere kommandolinjeklienten selv, eller gå med en grafisk klient som Skildpadde SVN. På Mac er Versjoner en veldig fin grafisk klient.
For å få mest mulig ut av SVN-depotet som tilbys av WordPress, setter vi det opp slik at pluginets utviklingsversjon er lagret i
Plugin katalogen leser koden som din nåværende stabile utgivelse skal distribueres ved å sjekke filen readme.txt i stamme. Jeg vil dekke dette mer detaljert i neste trinn når vi går gjennom innholdet i readme.txt fil som skal inkluderes med plugin.
Først, men la oss gå gjennom SVN-kommandoene du vil bruke mesteparten av tiden. Ikke bekymre deg hvis du ikke liker å skrive kommandoer i terminalen, bare gå videre og bruk din favoritt grafiske SVN-klient i stedet.
La oss begynne med å sjekke ut prosjektet fra SVN. Akkurat nå er prosjektet fortsatt tomt, så det er ikke lagt til en tom mappe på datamaskinen din.
$ svn co http: //[email protected]/your-plugin/trunk lokalvei
Kopier eller flytt plugin-koden til den katalogen (lokal-sti) som er opprettet av svn-kommandoen, og legg til filene til SVN. Inne i katalogen, skriv inn:
$ svn legg til fil-bane
fil-banen kan være en bane til en bestemt fil, eller et jokertegn som * .php. Dette vil markere filene som skal legges til SVN-depotet i ditt neste svn-commit - ingenting er forpliktet ennå. Hvis du ikke er sikker på hvilke filer du allerede har lagt til, kan du sjekke SVN-statusen til hver fil i den nåværende arbeidskatalogen:
$ svn status
Til slutt, når alt er klart for å bli sendt til SVN-depotet, begår du filene. Ikke vær redd for å begå ofte: så lenge "Stabil-taggen" peker på en annen katalog enn trunk, vil dine forpliktelser ikke ha en effekt på den allerede publiserte versjonen. Ved å gjøre dette er du trygg i tilfelle du mister din lokale kopi av koden av en eller annen grunn.
$ svn commit -m "En kort forklaring på hva som ble endret"
Før prosjektet ditt kan vises i Plugin Directory, må du fortsatt legge til readme.txt filen. Men før vi går inn i det, er det på tide å teste pluginet ditt.
Selv om brukerne dine ikke betaler for å bruke pluginet ditt, er det aldri en god ide å slippe et plugin uten å teste det først. I åpen kildekode tolererer folk noen få buggy utgivelser nå og da hvis du løser feilene dine raskt og er raske til å svare på sine feilrapporter, men hvis hver eneste utgave går ut med alvorlige feil som er igjen i det, før eller senere, brukerne dine vil gå videre til andre lignende plugins.
Samtidig må vi huske at som eneste utviklere eller små lag er våre ressurser for testing begrenset. Hvis du er heldig, kan du noen utenfor laget for å teste pluginet ditt, men det er bare du som utvikleren gjør testingen. Derfor er det viktig å skape en klar og enkel, gjennomførbar testplan.
For å opprette en, gå gjennom følgende råd, og velg tipsene som fungerer for deg, og tilpass etter din egen erfaring og detaljene i pluginet du er i ferd med å slippe ut.
Jeg er den første til å innrømme at jeg ikke er en perfekt utvikler. Selv om jeg kjenner mine svake steder, pleier jeg å gjenta mine feil. Derfor prøver jeg å holde en oppdatert liste over bugtyper som forekommer oftest i min kode og tester som jeg må gjøre før hver utgivelse for å få de vanligste feilene mine.
Dette kalles Regresjonstesting, og det er en av de viktigste testtypene: Vanligvis blir nye funksjoner testet ganske bra når du utvikler dem, men samtidig kan du introdusere feil til andre deler av koden du allerede har sett fullstendig.
For å fange disse feilene, opprett en liste over tester for å sjekke kjernefunksjonaliteten til pluginet ditt, og gå gjennom listen før hver utgivelse, selv om endringene ikke burde ha rørt dem.
Noen av feilene ser bare ut til nye brukere som installerer plugin for første gang, mens andre bare plager brukerne som oppgraderer fra en tidligere versjon. Noen feil oppstår bare i et multi-user miljø, og så videre.
For å sikre at du tar så mange problemer som mulig, er det en god idé å lage forskjellige testmiljøer, minst en med en eksisterende versjon av pluginet ditt og den andre en ren WordPress-installasjon.
Når du vet at din neste utgivelse oppretter nye databasetabeller eller endrer eksisterende, test forsiktig for å se at endringen du forventer å skje, gjør faktisk, og databasen kommer til riktig sluttstat. Min testprosedyre sier om databasestrukturen:
Hvis DB-strukturen har endret seg:
- Test databaseoppgradering uten å deaktivere plugin
- Testdatabaseoppgradering med deaktivering / reaktivering
Dette er stater du ikke legger merke til om du bare kjører pluginet slik det var ment, og derfor kan det ta lang tid før du legger merke til feilene, med mindre du forsettlig tester for dem.
Dette er ikke noe du vil se i et stykke feilhåndterings kode som er ment å håndtere feilen tilfelle grasiøst:
For å være sikker på at pluginet ditt fungerer med endringer introdusert i den nyeste WordPress-versjonen, er det godt å alltid oppdatere testmiljøet til den nyeste versjonen før du gjør den siste testrunden.
Gå gjennom tilbakemelding fra brukerne og se om det er feil som du ikke har adressert ennå. Ignorer funksjonsforespørsler for nå (men skriv dem ned slik at du kan bruke dem som input når du planlegger neste utgave), siden du ikke kan gjøre alt i en utgave uansett. Tror alltid brukerne når de sier at de har funnet en feil, men vær ikke redd for å be om mer informasjon for å finne ut det.
Hvis pluginet ditt skriver ut noen HTML eller CSS, bestemmer du for et sett med nettlesere du støtter og tester pluginet på de nettleserne før hver utgivelse.
Noen potensielle problemer er enklere å finne ved å se på koden enn gjennom testing, så igjen, akkurat som i testing, er det en god ide å holde oversikt over dine svake flekker, og skrive ned en liste over ting å dobbeltsjekke før publisering av plugin. Når du slipper ut flere versjoner, får du mer kunnskap om hva som er viktig å teste i dette prosjektet, så fortsett å oppdatere listen mens du lærer, ta noen ting ut og legge til andre.
Her er noen ideer å dobbeltsjekke, samlet fra min egen erfaring:
Når du håndterer skjemaer som er oppført av brukeren, må du kontrollere at attributter er riktig, i sin enkleste form ved å bruke esc_attr metode.
$ user_name = esc_attr ($ _ POST ["brukernavn"]);
hvis plugin ikke er skrevet ved hjelp av objekter, er hver av funksjonene i samme navneområde med resten av koden i WordPress og installerte plugins. For å forhindre at funksjonsnavnene dine kolliderer med dem fra WordPress eller andre plugins, prefiks dem med et kort navn på plugin-modulen.
funksjon pluginname_print_error ($ message) ? // er tryggere enn: funksjon print_error ($ message) ?
Gå gjennom alle dine TODO eller FIXME kommentarer for å se at du ikke har gått glipp av noe du planla å jobbe med senere.
Hvis din plugin støtter lokalisering, før hver utgivelse, går du gjennom alle pluginens streng for å sikre at de er alle riktig merket for lokalisering. Det er lett å glemme dette når du legger til nye strenger i et plugin.
Accentsconagua
// bruk $ text = __ ("Hei, verden", "My_plugin"); // i stedet for bare $ text = "Hei, verden" // og _e ("Hei!", "my_plugin"); // i stedet for ekko "Hei!"; I WordPress Codex kan du finne et dokument som skisserer kodestilen som bør følges når du utvikler plugins for WordPress-plattformen. Selv om du følger dette dokumentet ikke er obligatorisk, gjør det det lettere for andre utviklere å hjelpe deg med plugin.
Kontroller at alle filer i plugin-modulen inneholder GPL-overskriften, og at GPL-lisensens lisens.txt er inkludert i hovedmappen til plugin-modulen.
/ * Copyright (c) 2011, Ditt Navn. Dette programmet er gratis programvare; Du kan omfordele den og / eller endre den i henhold til GNU General Public License som publisert av Free Software Foundation. enten versjon 2 av lisensen, eller (etter eget valg) enhver senere versjon. Dette programmet distribueres i håp om at det vil være nyttig, men UTEN NOGEN GARANTI; uten selv den underforståtte garantien om SALGBARHET eller EGNETHET TIL ET BESTEMT FORMÅL. Se GNU General Public License for mer informasjon. Du burde ha mottatt en kopi av GNU General Public License sammen med dette programmet; hvis ikke, skriv til Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. * /
Hver plugin som er forpliktet til WordPress-plugin-katalogen, må ha en readme.txt filen formatert i henhold til regler som er definert av denne malen. Det er viktig å følge formateringen som definert som når du forplikter pluginet til plugin-katalogen, konverteres denne filen automatisk til beskrivelsen av pluginet du ser når du leser plugins i plugin-mappen.
Se for eksempel hvordan denne koden fra begynnelsen av readme.txt-malen er omgjort til informasjon som presenteres for plugin-katalogbrukeren:
=== Pluginnavn === Bidragsytere: markjaquith, mdawaffe (dette burde være en liste over wordpress.org userid's) Donate link: http://example.com/ Merker: kommentarer, spam Krever minst: 2.8 Tested up to: 3.1.3 Stabil kode: 1_5_4
Kopier malen til plugin-katalogen din og begynn å redigere den med informasjon som er spesifikk for plugin-modulen din. Når du er fornøyd med readme.txt, test den ved hjelp av readme.txt-validatoren som tilbys av WordPress før du forplikter den til SVN.
Når du ser dette øverst på validatorsiden, er du klar til å begå:
Jeg nevnte den stabile taggen på trinnet der vi snakket om den riktige måten å bruke SVN i plugin utvikling. Nå er det på tide å begynne å bruke det: du har testet pluginet ditt, du har inspisert koden, og du har skrevet dokumentasjonen. Det er ingenting igjen, unntatt å slippe pluginet:
Se opp pluginets viktigste PHP-fil og oppdater kommentaren ved å skrive inn ditt versionsnummer til "Versjon:" felt:
/ * Plugin Name: En Plugin Version: 1.0 Plugin URI: http://wp.tutsplus.com Beskrivelse: My great plugin Forfatter: Jarkko Laine Forfatter URI: http://jarkkolaine.com * /
I readme.txt er det to seksjoner viet til dokumentasjon av versjonendringene: "endrings~~POS=TRUNC"og"Oppgraderingsmelding."Legg til en seksjon for den nye versjonen til Changelog, og gi detaljert informasjon om hvilke endringer og feilrettinger som er inkludert i denne versjonen. Oppgrader varsel er en kortere (maksimalt 300 tegn) oppsummering av hvorfor det er verdt å oppdatere til denne versjonen av plugin-modulen.
Her er et eksempel på en changelog rad fra min donasjons plugin:
= 1.5.2 = * Feilrettelse: Løst en feiloppdateringsbug som ble introdusert i forrige versjon * Feilrettelse: Løst en feil relatert til å sende den valgte valutaen til PayPal
Fortsatt i readme.txt, se opp raden (nesten på toppen av filen) som sier "Stabil tag:"og oppdater raden med navnet på taggen du vil bruke til din neste versjon. Min konvensjon har vært å navngi taggen den samme som versjonsnummeret med prikker erstattet av underskrifter (f.eks. taggen for versjon 1.0 ville være 1_0) . Dette fungerer ganske bra, men enda bedre er å bare gjøre det det samme som versjonsnummeret:
Stabil tag: 1.0
På denne måten, når noen søker etter en eldre versjon av pluginet ditt på siden "Andre versjoner", vil hun lett finne ut hvilken tag som tilhører hvilken versjon, som i dette eksemplet fra det mest populære pluginet i plugin-katalogen:
Forbind dine endringer i pluginets viktigste PHP-fil og readme.txt. Deretter oppretter du taggen du valgte for din neste "Stabile tag":
$ svn kopi http: //[email protected]/your-plugin/trunk http: //[email protected]/your-plugin/tags/1.0 -m "Merker en ny versjon "
Dette er det: readme.txt i stamme peker til riktig tag og alt du trenger å gjøre er å vente til den automatiske programvaren i plugin-katalogen merker endringene dine og oppdaterer katalogen. Det tar omtrent en halv time før den nye versjonen kan lastes ned fra plugin-katalogen og et par timer før WordPress-bloggen oppdager at det er en oppdatering tilgjengelig for plugin-modulen (hvis dette var en oppdatering i stedet for den første plikten).
Når du legger merke til oppdateringen i plugin-katalogen, laster du ned den og tester en gang til for å være sikker på at alle endringer og reparasjoner ble inkludert korrekt i utgivelsen på riktig måte. Fortell vennene dine og følgere om pluginet, så vent på tilbakemelding å rulle inn og se at nedlastingsstatistikken din vokser.
Når du begynner å motta tilbakemelding, eller hvis du har egne ideer for å forbedre pluginet, er det godt å fortsette å rulle ut nye versjoner noen få uker eller så. Dette vil vise brukerne at pluginet ditt fortsatt er i live og i aktiv utvikling, og gjør dem mer sannsynlig å investere sin tid i den.
