Share
Când vă apropiați de completarea pluginului dvs. WordPress, este timpul să începeți să vă gândiți să îl eliberați publicului larg. Pregătirea pentru publicarea unui plugin necesită o mulțime de lustruire, testare și reglaj fin și este ușor să uitați niște pași în acest proces. Acest tutorial vă va ghida prin publicarea plugin-ului în directorul plugin-ului WordPress și va funcționa ca o listă de verificare pentru a vă asigura că plugin-ul dvs. va fi gata pentru prima dată până când veți da publicitate.
Câțiva pași, cum ar fi instalarea proiectului, se realizează o singură dată în viața fiecărui plugin, în timp ce mulți sunt importanți de fiecare dată când lansați o nouă versiune a pluginului. De aceea poate fi o idee bună să marcați acest tutorial și să vă întoarceți când este timpul să faceți următoarea actualizare.
Directorul plugin-ului de pe WordPress.org este WordPress ce AppStore este pentru iPhone: cel mai simplu și cel mai rapid, încorporat mod de a găsi plugin-uri pentru WordPress. În timp ce este posibil să publicați plugin-ul ca fișier zip descărcat de pe propriul dvs. site web, cu fiecare versiune, integrarea între WordPress și directorul plugin-ului devine mai strânsă.
Prin lansarea plug-in-ului prin directorul plugin-ului, îi ușurați pe potențialii utilizatori să găsească plugin-ul dvs. și să îl actualizeze pe măsură ce creați versiuni noi. Ei vor putea să instaleze plugin-ul fără a trebui să părăsească tabloul de bord al administratorului WordPress și, desigur, majoritatea utilizatorilor WordPress sunt deja conștienți de directorul plugin-ului și îl vor naviga atunci când caută plugin-uri pentru a se potrivi nevoilor lor. Pe de altă parte, veți obține statistici de descărcare, feedback de la utilizatori prin pagina pluginului din directorul plugin și un depozit gratuit de subversiune pentru stocarea fișierelor și istoricului versiunii pluginului.
Există un motiv pentru a nu găzdui pluginul în directorul plugin? Dacă plugin-ul dvs. este comercial, vă recomandăm să îl găzduiți în altă locație (site-ul dvs. propriu sau pe o piață, cum ar fi Codecanyon Envato), deoarece plugin-ul este deschis și nu are suport pentru a face bani din pluginurile dvs. Totul postat în directorul plugin WordPress este gratuit descarcat de toată lumea.
Iată regulile pentru pluginurile găzduite în director, preluate din instrucțiunile directorului Plugin:
Există doar câteva restricții:
După ce v-ați decis să vă găzduiți pluginul în directorul plugin WordPress, primul pas este să creați un cont de utilizator WordPress.org. Pentru a obține unul, vizitați directorul plugin și faceți clic pe "Inregistreaza-te" în partea dreaptă sus a paginii, chiar lângă promptul de conectare.
După înregistrarea contului dvs. de utilizator, puteți solicita WordPress să vă adauge plugin-ul urmând acest link care duce la o pagină care arată ca imaginea de mai jos.
Completați formularul și explicați pe scurt ce este plugin-ul dvs. Fiți la fel de specifici pe măsură ce vă aflați într-o perioadă rezonabilă de timp. Dacă plugin-ul dvs. are deja un site web, introduceți adresa URL în câmpul "Adresa URL a pluginului".
Înainte de a crea proiectul dvs., cineva de la personalul WordPress vă va citi solicitarea și vă va aproba. În timp ce WordPress nu promite cât de mult s-ar putea să ia acest lucru, spunând că ei se vor întoarce la tine "într-o anumită perioadă de timp definită vag", timpul este calculat în ore sau zile, mai degrabă decât săptămâni - cel mai probabil, în termen de 24 de ore de la depunerea cererii.
Odată ce plugin-ul dvs. este aprobat, veți primi un e-mail cu site-ul web al noului dvs. proiect și adresa URL SVN în el. Observați adresa URL a repozitorului, deoarece o vom folosi foarte mult în pașii următori.
În următorii pași, voi presupune că sunteți cel puțin familiarizat cu SVN, deci dacă nu aveți nicio idee despre ceea ce este SVN, treceți prin un tutorial înainte de a continua la pasul următor.
Pe Mac și cele mai multe arome (dacă nu toate) de Linux, un client de linie SVN vine cu sistemul de operare. În ferestre, puteți instala clientul liniei de comandă sau puteți merge cu un client grafic, cum ar fi Tortoise SVN. Pe Mac, Versiuni este un client grafic foarte frumos.
Pentru a profita la maxim de depozitul SVN furnizat de WordPress, îl vom configura astfel încât versiunea de dezvoltare a pluginului să fie salvată în
Directorul plugin-ului citește eticheta de la care va fi distribuită versiunea curentă stabilă, verificând fișierul readme.txt din trompă. Voi face acest lucru în detaliu în pasul următor, pe măsură ce vom trece prin conținutul readme.txt fișier care ar trebui să fie inclus în plugin.
În primul rând, totuși, să trecem prin comenzile SVN pe care le veți folosi de cele mai multe ori. Nu vă faceți griji dacă nu vă place să scrieți comenzi în terminal, doar mergeți mai departe și utilizați în schimb clientul grafic preferat SVN.
Să începem prin verificarea proiectului de la SVN. În acest moment, proiectul este încă gol, astfel încât pe computerul dvs. nu este adăugat altceva decât un director gol.
$ svn co http: //[email protected]/your-plugin/trunk Căi locale
Copiați sau mutați codul pluginului în acel director (cale locală) creat de comanda svn și adăugați fișierele la SVN. În interiorul directorului, tastați:
$ svn adăugați calea fișierului
fișier-cale poate fi o cale spre un anumit fișier, sau un wildcard cum ar fi * .php. Acest lucru va marca fișierele care urmează să fie adăugate la depozitul SVN în următoarea comandă svn - nimic nu este încă angajat. Dacă nu sunteți sigur care fișiere pe care le-ați adăugat deja, puteți verifica starea SVN a fiecărui fișier din directorul curent de lucru:
$ svn status
În cele din urmă, când totul este gata să fie trimis la depozitul SVN, comiteți fișierele. Nu vă fie frică să vă comiteți adesea: atâta timp cât "eticheta stabilă" indică un alt director decât trunchiul, comitetele dvs. nu vor avea efect asupra versiunii deja publicate. Făcând acest lucru, sunteți sigur că veți pierde o copie locală a codului din anumite motive.
$ svn commit -m "O scurtă explicație a ceea ce sa schimbat"
Înainte ca proiectul dvs. să poată fi afișat în directorul Plugin, va trebui în continuare să adăugați fișierul readme.txt. Dar înainte de a intra în asta, este timpul să vă testați pluginul.
Chiar dacă utilizatorii dvs. nu plătesc să utilizeze plugin-ul dvs., eliberarea unui plugin fără a încerca mai întâi nu este o idee bună. În open source, oamenii tolerează câteva versiuni bug-uri din când în când, dacă vă reparați bug-urile rapid și sunteți rapid pentru a răspunde la rapoartele lor de erori, dar dacă fiecare lansare va ieși cu bug-uri serioase rămase în ea, mai devreme sau mai târziu, va trece la alte pluginuri similare.
În același timp, trebuie să ținem cont de faptul că, ca dezvoltatori singuri sau echipe mici, resursele noastre pentru testare sunt limitate. Dacă ești norocos, poți să-ți testezi pluginul pe cineva din afara echipei, dar destul de des, ești doar tu, dezvoltatorul care efectuează testarea. Acesta este motivul pentru care este important să creați un plan clar și simplu de testare.
Pentru a crea unul, treceți prin următoarele sfaturi și alegeți sfaturile care funcționează pentru dvs. și personalizați în funcție de experiența proprie și de specificul pluginului pe care urmează să îl lansați.
Sunt primul care admite că nu sunt un dezvoltator perfect. Chiar dacă știu punctele mele slabe, am tendința să repet greșelile mele. De aceea, în procedura mea de testare, încerc să păstrez o listă actualizată a tipurilor de bug-uri care apar cel mai adesea în codul meu și testele pe care trebuie să le fac înainte de fiecare lansare pentru a-mi prinde cele mai frecvente greșeli.
Aceasta se numește regresie, și este una dintre cele mai importante forme de testare: De obicei, noile caracteristici sunt testate destul de bine pe măsură ce le dezvoltați, dar în același timp este posibil să introduceți erori în alte părți ale codului pe care le-ați considerat deja complete.
Pentru a prinde aceste erori, creați o listă de teste pentru a verifica funcționalitatea principală a plugin-ului dvs. și treceți prin listă înainte de fiecare lansare, chiar dacă modificările dvs. nu ar fi trebuit să le atingă.
Unele dintre erorile apar doar utilizatorilor noi care instalează pluginul pentru prima dată, în timp ce alții îi deranjează pe utilizatorii care upgradează de la o versiune anterioară. Unele bug-uri apar doar într-un mediu cu mai mulți utilizatori și așa mai departe.
Pentru a vă asigura că prindeți cât mai multe probleme posibil, este o idee bună să creați medii de testare diferite, cel puțin una cu o versiune existentă a pluginului dvs., iar cealaltă o instalare curată WordPress.
Când știți că următoarea versiune creează noi tabele de baze de date sau modificări ale celor existente, verificați cu atenție pentru a vedea că schimbarea pe care o așteptați să se întâmple de fapt are loc și baza de date ajunge la starea finală corectă. Procedura mea de testare spune despre structura bazei de date:
Dacă sa modificat structura DB:
- Examinați actualizarea bazei de date fără a dezactiva pluginul
- Testați actualizarea bazei de date cu dezactivare / reactivare
Acestea sunt stări pe care nu le observați dacă rulați pluginul așa cum a fost intenționat și, prin urmare, poate dura mult timp înainte de a observa erorile dacă nu le testezi în mod intenționat.
Acest lucru nu este ceva pe care doriți să îl vedeți într-o bucată de cod de manipulare a erorilor, menită să o gestioneze cu grație:
Pentru a vă asigura că plugin-ul dvs. funcționează cu modificările introduse în ultima versiune WordPress, este bine să vă actualizați întotdeauna mediul de testare la cea mai recentă versiune înainte de a efectua runda finală de testare.
Treceți prin feedback-ul utilizatorului și vedeți dacă există erori pe care nu le-ați adresat încă. Ignorați cererile de caracteristici pentru acum (dar le scrieți în jos pentru a le putea utiliza ca intrare la planificarea următoarei versiuni), deoarece nu puteți face totul într-o singură versiune oricum. Întotdeauna credeți utilizatorii dvs. atunci când spun că au găsit un bug, dar nu vă fie frică să cereți mai multe informații pentru a vă da seama.
Dacă pluginul dvs. scrie orice cod HTML sau CSS, decideți cu privire la un set de browsere pe care îl susțineți și vă testați pluginul în aceste browsere înainte de fiecare lansare.
Unele probleme potențiale sunt mai ușor de găsit prin analizarea codului decât prin testare, așa că din nou, la fel ca și în teste, este o idee bună să țineți evidența punctelor slabe ale dvs. și să scrieți o listă de lucruri pentru a verifica dublu înainte de a publica pluginul. Pe măsură ce lansați mai multe versiuni, veți obține mai multe cunoștințe despre ceea ce este important pentru a testa în acest proiect, așa că continuați să actualizați lista pe măsură ce învățați, luând câteva lucruri și adăugând altele.
Iată câteva idei de verificare dublă, colectate din experiența mea:
Când gestionați formularele postate de utilizator, asigurați-vă că validați atributele în mod corespunzător, în forma sa cea mai simplă, utilizând esc_attr metodă.
$ user_name = esc_attr ($ _ POST ["nume de utilizator"]);
dacă plugin-ul dvs. nu este scris folosind obiecte, fiecare dintre funcțiile dvs. se află în același spațiu de nume cu restul codului din WordPress și pluginurile instalate. Pentru a împiedica numele dvs. de funcții să se ciocnească cu cele din WordPress sau alte pluginuri, prefixați-le cu un nume scurt al pluginului.
funcția pluginname_print_error ($ message) ? // este mai sigur decât: funcția print_error ($ message) ?
Treceți prin toate comentariile dvs. TODO sau FIXME pentru a vedea că nu ați pierdut nimic la care ați planificat să lucrați mai târziu.
Dacă pluginul dvs. acceptă localizarea, înainte de fiecare lansare, treceți prin întregul șir de plugin-uri pentru a vă asigura că toate sunt corect marcate pentru localizare. Este ușor să uitați acest lucru atunci când adăugați șiruri noi unui plugin.
Accentsconagua
// folosiți $ text = __ ("Bună ziua, lumea", "my_plugin"); // în loc de doar $ text = "Bună ziua, lumea" // și _e ("Hello!", "my_plugin"); // în loc de ecou "Bună ziua!"; În Codul WordPress, puteți găsi un document care conturează stilul de codare care ar trebui urmat la dezvoltarea pluginurilor pentru platforma WordPress. În timp ce urmăriți acest document nu este obligatoriu, acest lucru va face mai ușor pentru alți dezvoltatori să vă ajute cu pluginul.
Verificați că fiecare fișier din pluginul dvs. conține antetul GPL și că fișierul license.txt al licenței GPL este inclus în dosarul principal al pluginului dvs..
/ * Drepturi de autor (c) 2011, numele tau. Acest program este software liber; îl puteți redistribui și / sau modifica în conformitate cu termenii Licenței Publice Generale GNU publicate de Fundația pentru Software Liber; fie versiunea 2 a Licenței, fie (la alegere) orice versiune ulterioară. Acest program este distribuit în speranța că va fi util, dar FĂRĂ NICI O GARANȚIE; fără nici măcar garanția implicită de VANDABILITATE sau de FITNESS PENTRU UN SCOP SPECIC. Pentru mai multe detalii, consultați Licența publică generală GNU. Ar fi trebuit să fi primit o copie a Licenței Publice Generale GNU împreună cu acest program; dacă nu, scrieți la Free Software Foundation, Inc., 51 Franklin Street, Etajul cinci, Boston, MA 02110-1301, SUA. * /
Fiecare plugin dedicat directorului de plugin WordPress trebuie să aibă un readme.txt fișier formatat în conformitate cu regulile definite de acest șablon. Este important să urmați formatul așa cum a fost definit ca atunci când comiteți plugin-ul dvs. în directorul plugin, acest fișier este automat convertit în descrierea pluginului pe care îl vedeți când navigați prin plugin-uri în directorul plugin-ului.
De exemplu, vedeți modul în care acest fragment de la începutul șablonului readme.txt este convertit în informațiile prezentate utilizatorilor din directorul plugin:
=== Nume Plugin === Contribuitori: markjaquith, mdawaffe (aceasta ar trebui să fie o listă a userului lui wordpress.org) Donate link: http://example.com/ Tag-uri: comentarii, spam Necesită cel puțin: 2.8 Testați până la: 3.1.3 Etichetă stabilă: 1_5_4
Copiați șablonul în directorul plugin și începeți să îl editați cu informații specifice pluginului. Odată ce sunteți mulțumit de textul readme.txt, îl testați utilizând validatorul readme.txt furnizat de WordPress înainte de ao comite la SVN.
Când vedeți acest lucru în partea de sus a paginii validator, sunteți gata să vă angajați:
Am menționat eticheta stabilă la pasul în care am vorbit despre modul corect de utilizare a SVN în dezvoltarea plugin-urilor. Acum, este timpul să începeți să o utilizați: ați testat pluginul, ați inspectat codul și ați scris documentația. Nu a mai rămas nimic decât lansarea pluginului:
Căutați fișierul PHP principal al pluginului și actualizați comentariul introducând numărul versiunii dvs. la "Versiune:" camp:
/ * Plugin Name: A Plugin Versiune: 1.0 Plugin URI: http://wp.tutsplus.com Descriere: Pluginul meu minunat Autor: Jarkko Laine Autor URI: http://jarkkolaine.com * /
În textul readme.txt, există două secțiuni dedicate pentru documentarea modificărilor versiunii: "changelog" și "Notificare privind actualizarea."Adăugați o secțiune pentru noua dvs. versiune în Changelog, furnizând informații detaliate despre ce modificări și remedierile de eroare sunt incluse în această versiune. Notă privind actualizarea este un rezumat mai scurt (de cel mult 300 de caractere) de ce merită actualizarea la această versiune a pluginului.
Iată un exemplu pentru un rând de variabile din plugin-ul meu de donare:
= 1.5.2 = * Fixarea bug-urilor: Bug fixed bug-ul de actualizare a bug-urilor introdus în versiunea anterioară * Fixarea bug-urilor: Fixarea unei erori legată de trecerea monedei selectate în PayPal
Inca inauntru readme.txt, căutați rândul (aproape în partea de sus a fișierului) care spune "Etichetă stabilă:"și actualizați rândul cu numele etichetei pe care o veți folosi pentru următoarea versiune. Convenția mea a fost de a numi eticheta la fel ca numărul versiunii cu puncte înlocuite cu subliniere (de exemplu, eticheta pentru versiunea 1.0 ar fi 1_0) .Aceasta functioneaza destul de bine, dar chiar mai bine este sa o faceti la fel ca numarul versiunii:
Etichetă stabilă: 1.0
În acest fel, când cineva caută o versiune mai veche a plug-in-ului dvs. pe pagina "Alte versiuni", va găsi cu ușurință ce etichetă aparține versiunii, ca în acest exemplu, din plugin-ul cel mai popular din directorul plugin:
Acordeți-vă modificările fișierului principal al fișierului PHP și readme.txt. Apoi creați eticheta pe care ați ales-o pentru următoarea "etichetă stabilă":
$ svn copy http: //[email protected]/your-plugin/trunk http: //[email protected]/your-plugin/tags/1.0 -m "Etichetarea unei noi versiuni "
Acesta este: readme.txt în trompă indică eticheta corectă și tot ce trebuie să faceți este să așteptați până când software-ul automat din directorul plugin-ului vă avertizează despre modificări și actualizează directorul. Va fi nevoie de aproximativ o jumătate de oră pentru ca noua versiune să poată fi descărcată din directorul plugin-ului și cu câteva ore mai mult înainte ca blogul dvs. WordPress să anunțe că există o actualizare disponibilă pentru plugin (dacă aceasta a fost o actualizare în loc de primul comitet).
După ce observați actualizarea în directorul plugin-ului, descărcați-o și testați-o din nou doar pentru a vă asigura că fiecare modificare și remediere au fost incluse corect în versiune corectă. Spuneți-le prietenilor și adepților despre plugin, așteptați ca feedbackul să apară și să vizionați creșterea statisticilor de descărcare.
Odată ce începeți să primiți feedback sau dacă aveți idei proprii pentru îmbunătățirea pluginului, este bine să continuați să lansați versiuni noi la fiecare câteva săptămâni. Acest lucru va arăta utilizatorilor dvs. că plugin-ul dvs. este încă în viață și în curs de dezvoltare activă, și de a le face mai probabil să-și investească timpul în ea.
