Share
När du närmar dig att slutföra ditt WordPress-plugin är det dags att börja tänka på att släppa det till den bredare allmänheten. Att vara redo för att publicera ett plugin kräver mycket polering, testning och finjustering, och det är lätt att glömma några steg i processen. Denna handledning guidar dig genom att publicera plugin-programmet i WordPress-pluginkatalogen och fungera som en checklista som hjälper dig att se till att din plugin är klar för prime tiden när du slår publicera.
Några av stegen, som att ställa in projektet, görs en gång i varje plugins livstid, medan många är viktiga varje gång du släpper ut en ny version av ditt plugin. Därför kan det vara en bra idé att bokmärke denna handledning och komma tillbaka till den när det är dags att göra din nästa uppdatering.
Pluginkatalogen på WordPress.org är att WordPress vad AppStore är för iPhone: den enklaste och snabbaste inbyggda vägen för att hitta plugin för WordPress. Medan det är möjligt att publicera din plugin som en zip-fil som hämtas från din egen webbplats, med varje release blir integrationen mellan WordPress och dess plugin-katalog stramare.
Genom att släppa din plugin via plugin-katalogen, gör det lättare för dina potentiella användare att hitta ditt plugin och hålla det uppdaterat när du skapar nya versioner. De kommer att kunna installera plugin-enheten utan att behöva lämna WordPress admin-instrumentpanelen och naturligtvis är de flesta WordPress-användare redan medvetna om plugin-katalogen och kommer att bläddra i det när de letar efter plugins som matchar deras behov. Däremot kommer du att få nedladdningsstatistik, återkoppling från användarna via pluginens sida i plugin-katalogen och ett gratis subversion-arkiv för lagring av pluginfiler och versionshistorik.
Finns det något skäl för att inte vara värd för din plugin i plugin-katalogen? Om ditt plugin är kommersiellt kan du vara värd det på andra håll (din egen webbplats eller en marknadsplats, till exempel Envato's Codecanyon) eftersom plugin-katalogen är öppen och har inget stöd för att tjäna pengar ur dina pluginprogram. Allt som läggs ut i WordPress plugin-katalogen är gratis nedladdningsbart av alla.
Här är reglerna för plugins som finns i katalogen, taget från Plugin Directorys instruktioner:
Det finns bara några begränsningar:
När du väl har bestämt dig för att vara värd för din plugin i WordPress-plugin-katalogen, är det första steget att skapa ett WordPress.org användarkonto. För att få en, besök plugin katalogen och klicka på "Registrera" länken längst upp till höger på sidan, bredvid inloggningsprompten.
Efter att du har registrerat ditt användarkonto kan du begära att WordPress lägger till ditt plugin genom att följa den här länken vilket leder till en sida som ser ut som skärmbilden nedan.
Fyll i formuläret och förklara kort vad din plugin handlar om. Var lika specifik som du kan medan du vistas inom rimlig tid. Om ditt plugin redan har en webbplats anger du webbadressen i fältet "Plugin URL".
Innan ditt projekt skapas, kommer någon från WordPress-personalen att läsa din förfrågan och godkänna den. Medan WordPress inte ger några löften om hur lång tid det kan ta och säger att de kommer att komma tillbaka till dig i "viss vagt definierad tid", beräknas tiden i timmar eller dagar i stället för veckor - sannolikt kommer du att ha din plugin inrättas inom 24 timmar efter att ha lämnat in begäran.
När din plugin har godkänts kommer du att få ett mail med ditt nya projekt webbplats och SVN url i den. Lägg märke till förvarets webbadress, eftersom vi använder det kraftigt i nästa steg.
I följande steg antar du att du är minst lite bekant med SVN, så om du inte har någon aning om vad SVN är, skumma igenom en handledning innan du fortsätter till nästa steg.
På Mac och de flesta smakerna (om inte alla) av Linux, kommer en kommandorad SVN-klient med operativsystemet. I Windows kan du antingen installera kommandoradsklienten själv eller gå med en grafisk klient som Sköldpadda SVN. På Mac är Versions en mycket fin grafisk klient.
För att få ut det mesta av SVN-förvaret som tillhandahålls av WordPress ställer vi in det så att pluginens utvecklingsversion sparas i
Pluginkatalogen läser taggen från vilken din nuvarande stabila utgåva ska distribueras genom att kontrollera filen readme.txt i trunk. Jag kommer att beskriva detta mer i detalj i nästa steg när vi går igenom innehållet i readme.txt fil som ska ingå i plugin.
Först, men låt oss gå igenom SVN-kommandon som du kommer att använda mest av tiden. Oroa dig inte om du inte gillar att skriva kommandon i terminalen, fortsätt bara och använd din favorit grafiska SVN-klient istället.
Låt oss börja med att kolla in projektet från SVN. Just nu är projektet fortfarande tomt, så inget annat än en tom katalog läggs till på din dator.
$ svn co http: //[email protected]/your-plugin/trunk local-path
Kopiera eller flytta din plugin-kod till den katalogen (lokala sökvägen) skapad av svn-kommandot, och lägg till filerna till SVN. Inne i katalogen skriver du:
$ svn lägg till fil-sökväg
sökväg kan vara en sökväg till en specifik fil, eller ett jokertecken som * .php. Detta kommer att markera filerna som ska läggas till SVN-förvaret i ditt nästa svn commit - inget har åtagits än. Om du inte är säker på vilka filer du redan har lagt till kan du kontrollera SVN-status för varje fil i den aktuella arbetsmappen:
$ svn status
Slutligen, när allt är klart att skickas till SVN-arkivet, begår du filerna. Var inte rädd för att begå ofta: så länge som den "stabila taggen" pekar på någon annan katalog än stammen, kommer dina förpliktelser inte att påverka den redan publicerade versionen. Genom att göra detta är du säker om du förlorar din lokala kopia av koden av någon anledning.
$ svn commit -m "En kort förklaring av vad som ändrades"
Innan ditt projekt kan visas i Plugin Directory behöver du fortfarande lägga till readme.txt-filen. Men innan vi går in i det är det dags att testa ditt plugin.
Även om dina användare inte betalar för att använda ditt plugin, är det aldrig en bra idé att släppa ett plugin utan att testa det först. I öppen källkod tolererar människor en del buggy-utgåvor nu och då om du fixar dina buggar snabbt och snabbt kan svara på deras buggrapporter, men om varje enskild utgåva går ut med allvarliga buggar kvar i det, förr eller senare, kommer dina användare kommer att gå vidare till andra liknande plugins.
Samtidigt måste vi komma ihåg att vi som utvecklare eller små team är begränsade för våra resurser för testning. Om du har tur kan du någon utanför teamet testa din plugin, men det är bara du som utvecklaren gör testningen. Därför är det viktigt att skapa en tydlig och enkel, genomförbar testplan.
För att skapa en, gå igenom följande råd och plocka de tips som fungerar för dig och anpassa efter din egen erfarenhet och specifika för plugin du är på väg att släppa.
Jag är den första som medger att jag inte är en perfekt utvecklare. Trots att jag känner till mina svaga fläckar, tenderar jag att upprepa mina misstag. Det är därför som jag försöker hålla en uppdaterad lista över de typer av fel som oftast förekommer i min kod och test som jag måste göra före varje utgåva för att fånga de vanligaste misstagen.
Det här kallas regressionstestning, och det är en av de viktigaste formerna för testning. Vanligtvis blir nya funktioner testade ganska bra när du utvecklar dem, men samtidigt kan du införa buggar till andra delar av koden som du redan ansett vara komplett.
För att fånga dessa buggar, skapa en lista med tester för att kontrollera kärnfunktionaliteten i ditt plugin och gå igenom listan före varje release, även om dina ändringar inte borde ha berört dem.
Några av buggarna visas bara för nya användare som installerar plugin för första gången, medan andra bara stör användarna som uppgraderar från en tidigare version. Vissa fel visas bara i en miljö med flera användare, och så vidare.
För att du ska fånga så många problem som möjligt är det en bra idé att skapa olika testmiljöer, minst en med en befintlig version av din plugin och den andra en ren WordPress-installation.
När du vet att din nästa release skapar nya databastabeller eller ändrar befintliga, test försiktigt för att se till att den förändring du förväntar sig hända gör faktiskt och databasen kommer till rätt slutligt tillstånd. Mitt testförfarande säger om databasstruktur:
Om DB-strukturen har ändrats:
- Testdatabasuppgradering utan att inaktivera plugin
- Testdatabasuppgradering med avaktivering / reaktivering
Det här är stater du inte märker om du bara kör plugin så som det var tänkt och det kan därför ta lång tid innan du märker felen om du inte avsiktligt testa för dem.
Det här är inte något du vill se i en bit av felhanteringskod som är avsedd att hantera felfallet graciöst:
För att säkerställa att plugin fungerar med ändringar som introducerades i den senaste WordPress-versionen, är det bra att alltid uppdatera din testmiljö till den senaste versionen innan du gör den sista testrundan.
Gå igenom användaråterkoppling och se om det finns fel som du inte har tagit upp än. Ignorera funktionsförfrågningar för nu (men skriv ner dem så att du kan använda dem som inmatning när du planerar din nästa release) eftersom du inte kan göra allt i ett släpp ändå. Tro alltid dina användare när de säger att de har hittat ett fel, men var inte rädd för att fråga om mer information för att räkna ut det.
Om ditt plugin skriver ut någon HTML eller CSS, bestäm du om en uppsättning webbläsare som du stöder och testa ditt plugin på dessa webbläsare före varje release.
Vissa potentiella problem är lättare att hitta genom att titta på koden än genom testning, så igen, precis som i testning, är det en bra idé att hålla reda på dina svaga fläckar och skriva ner en lista över saker att dubbelkontrollera innan du publicerar plugin. När du släpper ut fler versioner får du mer kunskap om vad som är viktigt att testa i det här projektet, så fortsätt att uppdatera listan när du lär dig, ta bort saker och lägga till andra.
Här är några idéer att dubbelkontroll, samlad ur min egen erfarenhet:
När du hanterar formulär som läggs ut av användaren ska du kontrollera att attributen är korrekt, i dess enklaste form genom att använda esc_attr metod.
$ user_name = esc_attr ($ _ POST ["användarnamn"]);
Om ditt plugin inte är skrivet med objekt, har alla funktioner i samma namnrymd med resten av koden i WordPress och installerade plugin. För att förhindra att dina funktionsnamn kolliderar med dem från WordPress eller andra plugins, prefixa dem med ett kort namn på pluginprogrammet.
funktion pluginname_print_error ($ message) ? // är säkrare än: funktion print_error ($ message) ?
Gå igenom alla dina TODO eller FIXME kommentarer för att se att du inte har missat något du planerade att arbeta på senare.
Om ditt plugin stöder lokalisering, före varje release, gå igenom alla plugins sträng för att se till att de är alla korrekt markerade för lokalisering. Det är lätt att glömma detta när du lägger till nya strängar till ett plugin.
Accentsconagua
// använd $ text = __ ("Hej världen", "my_plugin"); // istället för bara $ text = "Hej världen" // och _e ("Hej!", "my_plugin"); // istället för att echo "Hej!"; I WordPress Codex kan du hitta ett dokument som beskriver den kodande stilen som ska följas när du utvecklar plugins för WordPress-plattformen. Medan du följer detta dokument är det inte obligatoriskt, så gör det det lättare för andra utvecklare att hjälpa dig med plugin.
Kontrollera att varje fil i plugin innehåller GPL-rubriken och att GPL-licensens licens.txt ingår i pluginens huvudmapp.
/ * Copyright (c) 2011, Ditt Namn. Detta program är fri programvara; Du kan omfördela den och / eller ändra den enligt villkoren i GNU General Public License som publiceras av Free Software Foundation. antingen version 2 i Licensen eller (eventuellt) någon senare version. Programmet distribueras i hopp om att det kommer att vara användbart, men UTAN NÅGOT GARANTI. utan ens den underförstådda garantin om SÄLJBARHET eller EGNETHET FÖR ET SÄRSKILT SYFTE. Se GNU General Public License för mer information. Du borde ha fått en kopia av GNU General Public License tillsammans med det här programmet. om inte, skriv till Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. * /
Varje plugin som är kopplad till WordPress-pluginkatalogen måste ha en readme.txt filen formaterad enligt regler som definieras av denna mall. Det är viktigt att följa formateringen som definierad som när du pluggar plugin till plugin-katalogen konverteras den här filen automatiskt till beskrivningen av det plugin du ser när du surfar pluggar i plugin-katalogen.
Se till exempel hur detta stycke från början av readme.txt-mallen konverteras till information som presenteras för plugin-kataloganvändaren:
=== Pluginnamn === Bidragsgivare: markjaquith, mdawaffe (detta ska vara en lista med wordpress.org userid s) Donera länk: http://example.com/ Tags: comments, spam Kräver åtminstone: 2.8 Testade upp till: 3.1.3 Stabil etikett: 1_5_4
Kopiera mallen till din plugin-katalog och börja redigera den med information som är specifik för din plugin. När du är nöjd med din readme.txt, testa den med hjälp av readme.txt-validatorn som tillhandahålls av WordPress innan du förbinder den med SVN.
När du ser detta överst på validatorsidan är du redo att begå:
Jag nämnde den stabila taggen vid steget där vi pratade om rätt sätt att använda SVN i pluginutveckling. Nu är det dags att börja använda det: du har testat ditt plugin, du har inspekterat din kod och du har skrivit dokumentationen. Det finns inget kvar utom att släppa plugin:
Leta upp pluginets huvudsakliga PHP-fil och uppdatera kommentaren genom att ange ditt versionsnummer till "Version:" fält:
/ * Plugin Name: En Plugin Version: 1.0 Plugin URI: http://wp.tutsplus.com Beskrivning: Min stora plugin Författare: Jarkko Laine Författare URI: http://jarkkolaine.com * /
I readme.txt finns det två avsnitt som ägnas åt att dokumentera dina versionsändringar: "Ändringslogg"och"Uppgraderingsmeddelande."Lägg till en sektion för din nya version till Changelog, som ger detaljerad information om vilka ändringar och buggfixar som ingår i den här versionen. Uppgraderingsmeddelandet är en kortare (högst 300 tecken) sammanfattning av varför det är värt att uppdatera till den här versionen av pluginprogrammet.
Här är ett exempel på en changelograd från min donationsplugin:
= 1.5.2 = * Buggfix: Fixat en buggdatabasuppgraderingsfel introducerad i tidigare version * Buggfix: Fixat ett fel relaterat till att den valda valutan skickas till PayPal
Fortfarande inne readme.txt, kolla upp raden (nästan högst upp i filen) som säger "Stabil tagg:"och uppdatera raden med namnet på taggen som du ska använda för din nästa version. Min konvention har varit att namnge taggen samma som versionsnumret med prickar ersatt med understreck (t.ex. taggen för version 1.0 skulle vara 1_0) . Det fungerar ganska bra, men ännu bättre är att bara göra det samma som versionsnumret:
Stabil etikett: 1.0
På det här sättet, när någon söker efter en äldre version av ditt plugin på sidan "Andra versioner", kommer hon enkelt att ta reda på vilken tagg som tillhör vilken version som i det här exemplet från det mest populära pluginet i plugin-katalogen:
Förbind dina ändringar till pluginets huvudsakliga PHP-fil och readme.txt. Skapa sedan taggen du valde för din nästa "stabila tagg":
$ svn kopia http: //[email protected]/your-plugin/trunk http: //[email protected]/your-plugin/tags/1.0 -m "Märkning av en ny version "
Det här är det: readme.txt in trunk pekar på rätt tagg och allt du behöver göra är att vänta tills den automatiska programvaran i plugin-katalogen meddelar dina ändringar och uppdaterar katalogen. Det tar ungefär en halvtimme för den nya versionen att hämtas från pluginkatalogen och ett par timmar mer innan din WordPress-blogg noterar att det finns en uppdatering tillgänglig för pluginet (om det här var en uppdatering istället för den första commit).
När du märker uppdateringen i plugin-katalogen, ladda ner den och testa en gång för att vara säker på att alla ändringar och korrigeringar har inkluderats korrekt i utgåvan korrekt. Berätta för dina vänner och följare om pluginet, vänta sedan på feedback för att rulla in och se din nedladdningsstatistik växa.
När du börjar få feedback, eller om du har egna idéer för att förbättra pluginet, är det bra att fortsätta att rulla ut nya versioner med några veckor eller så. Det här visar dina användare att ditt plugin fortfarande lever och i aktiv utveckling, och gör dem mer benägna att investera sin tid i den.
