Share
Wanneer u bijna klaar bent met het voltooien van uw WordPress-plug-in, wordt het tijd om na te denken over het vrijgeven ervan aan een breder publiek. De voorbereiding voor het publiceren van een plug-in vereist veel polijsten, testen en afstemmen, en het is gemakkelijk om enkele stappen in het proces te vergeten. Deze zelfstudie helpt je bij het publiceren van de plug-in in de WordPress plugin-directory en werkt als een checklist om ervoor te zorgen dat je plug-in klaar is voor de beste tijd tegen de tijd dat je publiceert..
Sommige stappen, zoals het opzetten van het project, worden een keer in de levensduur van elke plug-in gedaan, terwijl veel ervan belangrijk zijn telkens wanneer u een nieuwe versie van uw plug-in uitbrengt. Daarom kan het een goed idee zijn om deze zelfstudie aan favorieten toe te voegen en er later op terug te komen wanneer het tijd is om je volgende update uit te voeren.
De plugin-directory op WordPress.org is naar WordPress wat AppStore voor de iPhone is: de gemakkelijkste en snelste ingebouwde manier om plug-ins voor WordPress te vinden. Hoewel het mogelijk is om uw plug-in te publiceren als een zip-bestand gedownload van uw eigen website, bij elke release, wordt de integratie tussen WordPress en de plugin-map steeds krapper.
Door uw plug-in via de plugin-directory vrij te geven, maakt u het voor uw potentiële gebruikers gemakkelijker om uw plug-in te vinden en bij te houden wanneer u nieuwe versies maakt. Ze kunnen de plug-in installeren zonder het WordPress-beheerdersdashboard te hoeven sluiten, en natuurlijk zijn de meeste WordPress-gebruikers al goed op de hoogte van de plugin-directory en zullen ze doorbladeren wanneer ze zoeken naar plug-ins die aan hun behoeften voldoen. Aan de andere kant krijg je downloadstatistieken, feedback van de gebruikers via de pagina van de plug-in in de plugin-directory en een gratis subversion-repository voor het opslaan van de bestanden en versiegeschiedenis van je plug-in.
Is er een reden om uw plug-in niet te hosten in de plugin-directory? Als uw plug-in commercieel is, wilt u hem misschien elders hosten (uw eigen site of een marktplaats, zoals Envato's Codecanyon), omdat de plugin-map open is en geen ondersteuning biedt om geld te verdienen met uw plug-ins. Alles wat in de WordPress plugin-directory staat, kan door iedereen vrij worden gedownload.
Hier volgen de regels voor plug-ins die in de directory worden gehost, ontleend aan de instructies van de plugin-directory:
Er zijn slechts een paar beperkingen:
Nadat u hebt besloten om uw plug-in te hosten in de plug-in WordPress-map, is de eerste stap het maken van een WordPress.org-gebruikersaccount. Om er een te krijgen, bezoek de plugin-map en klik op de "Registreren" link in de rechterbovenhoek van de pagina, direct naast de aanmeldingsprompt.
Nadat u uw gebruikersaccount hebt geregistreerd, kunt u WordPress vragen om uw plug-in toe te voegen door deze link te volgen, die leidt naar een pagina die lijkt op de onderstaande schermafbeelding.
Vul het formulier in en leg in het kort uit waarover uw plug-in gaat. Wees zo specifiek mogelijk terwijl je binnen een redelijke lengte blijft. Als uw plug-in al een website heeft, voert u de URL in het veld 'Invoeg-URL' in.
Voordat uw project wordt aangemaakt, zal iemand van de WordPress-medewerkers uw verzoek lezen en goedkeuren. Terwijl WordPress geen beloftes doet over hoe lang dit zou kunnen duren, en zegt dat ze je in "een vaag gedefinieerde hoeveelheid tijd" terug zullen komen, wordt de tijd berekend in uren of dagen in plaats van weken - waarschijnlijk heb je je plugin opgezet binnen 24 uur na het indienen van het verzoek.
Zodra uw plug-in is goedgekeurd, ontvangt u een e-mail met daarin de website van uw nieuwe project en de SVN-URL. Let op de URL van de repository, omdat we deze in de volgende stappen zwaar zullen gebruiken.
In de volgende stappen zal ik veronderstellen dat je op zijn minst enigszins bekend bent met SVN, dus als je geen idee hebt wat SVN is, doorloop je een zelfstudie voordat je doorgaat naar de volgende stap.
Op Mac en de meeste smaken (zo niet alle) van Linux komt een SVN-client met opdrachtregel bij het besturingssysteem. In Windows kunt u de opdrachtregelclient zelf installeren of met een grafische client zoals Tortoise SVN. Op Mac is Versions een erg mooie grafische client.
Om het maximale uit de SVN-repository van WordPress te halen, zullen we het zo instellen dat de ontwikkelversie van de plug-in wordt opgeslagen in
De plugin-map leest de tag waaruit uw huidige stabiele release moet worden gedistribueerd door het bestand readme.txt in te schakelen romp. Ik zal dit in de volgende stap in meer detail bespreken terwijl we de inhoud van de readme.txt bestand dat bij de plug-in moet worden gevoegd.
Laten we echter eerst de SVN-opdrachten doornemen die u de meeste tijd zult gebruiken. Maakt u zich geen zorgen als u geen opdrachten in de terminal schrijft, ga gewoon door en gebruik in plaats daarvan uw favoriete grafische SVN-client.
Laten we beginnen met het uitchecken van het project van SVN. Op dit moment is het project nog steeds leeg, dus niets dan een lege map is toegevoegd aan je computer.
$ svn co http: //[email protected]/your-plugin/trunk local-path
Kopieer of verplaats uw plug-incode naar die map (lokaal pad) die met de opdracht svn is gemaakt en voeg de bestanden toe aan SVN. Typ in de directory:
$ svn voeg een bestandspad toe
bestandspad kan een pad naar een specifiek bestand zijn, of een wildcard zoals * .php. Dit markeert de bestanden die moeten worden toegevoegd aan de SVN-repository in uw volgende svn-commit - er is nog niets vastgelegd. Als u niet zeker weet welke bestanden u al hebt toegevoegd, kunt u de SVN-status van elk bestand in de huidige werkdirectory controleren:
$ svn-status
Eindelijk, als alles gereed is om naar de SVN-repository te worden verzonden, commit de bestanden. Wees niet bang om vaak te committen: zolang de "Stable tag" verwijst naar een andere directory dan trunk, zullen je commits geen effect hebben op de reeds gepubliceerde versie. Door dit te doen bent u veilig in het geval u om de een of andere reden uw lokale exemplaar van de code verliest.
$ svn commit -m "Een korte uitleg van wat er is veranderd"
Voordat uw project in de Plugin-directory kan worden getoond, moet u nog steeds het bestand readme.txt toevoegen. Maar voordat we daar ingaan, is het tijd om je plug-in te testen.
Hoewel uw gebruikers niet betalen om uw plug-in te gebruiken, is het nooit een goed idee om een plug-in vrij te geven zonder deze eerst te testen. In open source tolereren mensen zo nu en dan een paar buggy-releases als je je bugs snel repareert en snel reageert op hun bugrapporten, maar als elke afzonderlijke release eruit gaat met serieuze bugs, vroeg of laat, laten je gebruikers zal doorgaan naar andere vergelijkbare plug-ins.
Tegelijkertijd moeten we in gedachten houden dat onze middelen voor testen als enige ontwikkelaars of kleine teams beperkt zijn. Als je geluk hebt, kun je iemand buiten het team testen om je plug-in te testen, maar heel vaak is het alleen jij die de ontwikkelaar test. Daarom is het belangrijk om een duidelijk en eenvoudig uitvoerbaar testplan te maken.
Om een account aan te maken, doorloop je het volgende advies en kies je de tips die voor jou werken, en pas je het aan volgens je eigen ervaring en de details van de plug-in die je gaat publiceren..
Ik ben de eerste om toe te geven dat ik geen perfecte ontwikkelaar ben. Hoewel ik mijn zwakke plekken ken, heb ik de neiging om mijn fouten te herhalen. Daarom probeer ik in mijn testprocedure een up-to-date lijst bij te houden van de soorten fouten die het vaakst voorkomen in mijn code en tests die ik moet uitvoeren vóór elke release om mijn meest voorkomende fouten te vangen.
Dit heet regressie testen, en het is een van de belangrijkste vormen van testen: meestal worden nieuwe functies vrij goed getest terwijl je ze ontwikkelt, maar tegelijkertijd introduceer je bugs in andere delen van de code die je al als compleet beschouwde.
Om deze bugs te vangen, maakt u een lijst met tests om de kernfunctionaliteit van uw plug-in te controleren en doorloopt u de lijst vóór elke release, zelfs als uw wijzigingen ze niet hadden aangeraakt.
Sommige bugs verschijnen alleen voor nieuwe gebruikers die de plug-in voor de eerste keer installeren, terwijl anderen alleen de gebruikers storen die een upgrade uitvoeren van een vorige versie. Sommige fouten verschijnen alleen in een omgeving met meerdere gebruikers, enzovoort.
Om er zeker van te zijn dat u zoveel mogelijk problemen oplost, is het een goed idee om verschillende testomgevingen te maken, ten minste één met een bestaande versie van uw plug-in en de andere een schone WordPress-installatie.
Wanneer u weet dat uw volgende release nieuwe databasetabellen maakt of bestaande tabellen wijzigt, test u zorgvuldig om te zien of de wijziging die u verwacht te doen in feite wel werkt en of de database de juiste eindstatus bereikt. Mijn testprocedure zegt over de databasestructuur:
Als de DB-structuur is gewijzigd:
- Test database-upgrade zonder de plug-in te deactiveren
- Test database-upgrade met deactivering / reactivering
Dit zijn toestanden die u niet opmerkt als u de plug-in uitvoert zoals deze bedoeld was, en daarom kan het lang duren voordat u de fouten opmerkt, tenzij u opzettelijk test voor deze fouten.
Dit is niet iets dat u wilt zien in een stukje foutafhandelingscode die bedoeld is om de foutcasus op een elegante manier af te handelen:
Om ervoor te zorgen dat uw plug-in werkt met wijzigingen die zijn geïntroduceerd in de nieuwste WordPress-versie, is het goed om altijd uw testomgeving bij te werken naar de nieuwste versie voordat u de laatste testronde doet.
Bekijk de feedback van gebruikers en kijk of er fouten zijn die u nog niet hebt aangepakt. Negeer de functie-aanvragen voor nu (maar schrijf ze op, zodat u ze als invoer kunt gebruiken bij het plannen van uw volgende release), omdat u toch niet alles in één release kunt doen. Geloof uw gebruikers altijd wanneer ze zeggen dat ze een fout hebben ontdekt, maar wees niet bang om meer informatie te vragen om erachter te komen.
Als uw plug-in HTML of CSS opschrijft, beslis dan een aantal browsers die u ondersteunt en test uw plug-in in die browsers voor elke release.
Sommige mogelijke problemen zijn gemakkelijker te vinden door naar de code te kijken dan door te testen, dus net als bij het testen is het een goed idee om je zwakke plekken bij te houden en een lijst met zaken op te schrijven die je moet controleren voordat je de plug-in publiceert. Naarmate je meer versies uitbrengt, krijg je meer kennis over wat belangrijk is om te testen in ditzelfde project, dus blijf de lijst updaten terwijl je leert, dingen uitdeelt en anderen toevoegt.
Hier zijn enkele ideeën om dubbel te controleren, verzameld uit mijn eigen ervaring:
Wanneer u formulieren verwerkt die door de gebruiker zijn geplaatst, moet u ervoor zorgen dat u de kenmerken correct valideert, in de eenvoudigste vorm met behulp van de esc_attr methode.
$ user_name = esc_attr ($ _ POST ["gebruikersnaam"]);
als uw plug-in niet is geschreven met behulp van objecten, bevinden al uw functies zich in dezelfde naamruimte met de rest van de code in WordPress en geïnstalleerde plug-ins. Om te voorkomen dat uw functienamen botsen met die van WordPress of andere plug-ins, geeft u ze een prefix met een korte naam van de plug-in.
function pluginname_print_error ($ message) ? // is veiliger dan: function print_error ($ message) ?
Bekijk al je TODO- of FIXME-opmerkingen om te zien dat je niets gemist hebt waar je later aan wilde werken.
Als uw plug-in de lokalisatie ondersteunt, doorloopt u voor elke release alle plugins om er zeker van te zijn dat ze allemaal correct zijn gemarkeerd voor lokalisatie. Het is gemakkelijk om dit te vergeten bij het toevoegen van nieuwe strings aan een plug-in.
Accentsconagua
// gebruik $ text = __ ("Hello, world", "my_plugin"); // in plaats van alleen $ text = "Hello, world" // en _e ("Hello!", "my_plugin"); // in plaats van echo "Hallo!"; In de WordPress Codex kunt u een document vinden met de coderingsstijl die moet worden gevolgd bij het ontwikkelen van plug-ins voor het WordPress-platform. Hoewel het volgen van dit document niet verplicht is, maakt dit het voor andere ontwikkelaars gemakkelijker om u te helpen met de plug-in.
Controleer of elk bestand in uw plug-in de GPL-header bevat en of de license.txt van de GPL-licentie is opgenomen in de hoofdmap van uw plug-in.
/ * Copyright (c) 2011, uw naam. Dit programma is gratis software; je kunt het herdistribueren en / of wijzigen onder de voorwaarden van de GNU General Public License zoals gepubliceerd door de Free Software Foundation; ofwel versie 2 van de Licentie, of (naar uw keuze) een latere versie. Dit programma wordt verspreid in de hoop dat het nuttig zal zijn, maar ZONDER ENIGE GARANTIE; zonder zelfs de impliciete garantie van VERKOOPBAARHEID of GESCHIKTHEID VOOR EEN BEPAALD DOEL. Zie de GNU General Public License voor meer details. Je zou samen met dit programma een kopie van de GNU General Public License moeten hebben ontvangen; zo niet, schrijf dan naar de Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, VS. * /
Elke plugin die is toegewezen aan de WordPress plugin-directory, moet een readme.txt bestand geformatteerd volgens regels die door deze sjabloon zijn gedefinieerd. Het is belangrijk om de opmaak te volgen zoals gedefinieerd, wanneer u uw plug-in in de plugin-directory commit, wordt dit bestand automatisch geconverteerd naar de beschrijving van de plug-in die u ziet bij het bladeren door plug-ins in de plugin-directory.
Zie bijvoorbeeld hoe dit fragment vanaf het begin van de readme.txt-sjabloon wordt geconverteerd naar informatie die wordt aangeboden aan de gebruiker van de plugin-directory:
=== Plugin Name === Medewerkers: markjaquith, mdawaffe (dit zou een lijst moeten zijn van wordpress.org userid's) Doneer link: http://example.com/ Tags: comments, spam Vereist ten minste: 2.8 Getest tot: 3.1.3 Stabiel label: 1_5_4
Kopieer de sjabloon naar uw plugin-map en begin deze te bewerken met informatie die specifiek is voor uw plug-in. Zodra u tevreden bent met uw readme.txt, test u het met de Readme.txt-validator van WordPress voordat u het naar SVN gaat.
Als u dit bovenaan de validatorpagina ziet, bent u klaar om te commiten:
Ik noemde de stabiele tag bij de stap waar we het hadden over de juiste manier om SVN te gebruiken in de ontwikkeling van plug-ins. Nu is het tijd om het te gebruiken: je hebt je plug-in getest, je hebt je code geïnspecteerd en je hebt de documentatie geschreven. Er is niets over, behalve het vrijgeven van de plug-in:
Zoek het belangrijkste PHP-bestand van je plug-in op en update de opmerking door je versienummer in te voeren in de "Versie:" veld:
/ * Plugin Name: A Plugin Version: 1.0 Plugin URI: http://wp.tutsplus.com Beschrijving: My great plugin Auteur: Jarkko Laine Auteur URI: http://jarkkolaine.com * /
In readme.txt zijn er twee secties gewijd aan het documenteren van uw versiewijzigingen: "changelog"en"Upgrade Notice."Voeg een sectie voor uw nieuwe versie toe aan Changelog, met gedetailleerde informatie over welke wijzigingen en bugfixes in deze versie zijn opgenomen. Upgrade-kennisgeving is een kortere (maximaal 300 tekens) samenvatting van waarom het de moeite waard is om deze versie van de plug-in bij te werken.
Hier is een voorbeeld voor een rij changelog van mijn donatie-plugin:
= 1.5.2 = * Bugfix: een bug voor het verhelpen van bug-database-upgrades hersteld die in de vorige versie was geïntroduceerd * Bugfix: een bug opgelost met betrekking tot het doorgeven van de geselecteerde valuta aan PayPal
Nog steeds binnen readme.txt, zoek de rij op (bijna bovenaan het bestand) die zegt:Stabiele tag:"en werk de rij bij met de naam van de tag die je gaat gebruiken voor je volgende versie. Mijn conventie was om de tag hetzelfde te noemen als het versienummer met punten vervangen door underscores (de tag voor versie 1.0 zou bijvoorbeeld 1_0 zijn) Dit werkt best goed, maar nog beter is om het net zo te maken als het versienummer:
Stabiel label: 1.0
Op deze manier, wanneer iemand op zoek is naar een oudere versie van uw plug-in op de pagina "Andere versies", zal zij gemakkelijk uitvinden welke tag bij welke versie hoort, zoals in dit voorbeeld van de populairste plug-in in de plugin-map:
Breng uw wijzigingen aan in het belangrijkste PHP-bestand van de plug-in en readme.txt. Maak vervolgens de tag die u heeft gekozen voor uw volgende "stabiele tag":
$ svn kopie http: //[email protected]/your-plugin/trunk http: //[email protected]/your-plugin/tags/1.0 -m "Een nieuwe versie taggen "
Dit is het: de readme.txt in romp wijst naar de juiste tag en het enige wat u hoeft te doen is te wachten tot de automatische software in de plugin-map uw wijzigingen opmerkt en de directory updatet. Het duurt ongeveer een half uur voordat de nieuwe versie kan worden gedownload vanuit de plugin-directory en een paar uur voordat uw WordPress-blog merkt dat er een update beschikbaar is voor de plug-in (als dit een update was in plaats van de eerste commit).
Zodra u de update in de plugin-map opmerkt, downloadt u deze en test u nog een keer om er zeker van te zijn dat elke wijziging en oplossing correct in de release is opgenomen. Vertel je vrienden en volgers over de plug-in en wacht vervolgens op feedback om je in te laden en je downloadstatistieken te laten groeien.
Zodra je feedback begint te ontvangen, of als je zelf ideeën hebt om de plug-in te verbeteren, is het goed om elke paar weken nieuwe versies uit te rollen. Dit zal uw gebruikers laten zien dat uw plug-in nog steeds in leven is en zich in actieve ontwikkeling bevindt, en ervoor zorgen dat ze meer tijd investeren in het programma.
