Lecții învățate în timpul dezvoltării pluginurilor WordPress

Fiecare dezvoltator de pluginuri WordPress se luptă cu probleme grele și cu coduri greu de întreținut. Petrecem nopți târziu susținând utilizatorii noștri și ne rupem părul atunci când un upgrade ne distruge pluginul. Lasă-mă să-ți arăt cum să faci asta mai ușor.

În acest articol, îmi voi împărtăși cei cinci ani de experiență în dezvoltarea de pluginuri WordPress. Primul plugin pe care l-am scris a fost un simplu plugin de marketing. A afișat un buton de îndemn (CTA) cu expresia de căutare Google. De atunci, am mai scris 11 plugin-uri gratuite și le întrețin aproape pe toate. Am scris în jur de 40 de plugin-uri pentru clienții mei, de la cele cu adevărat mici la unul care a fost întreținut de peste un an.

Dezvoltarea și suportul bun duc la mai multe descărcări. Mai multe descărcări înseamnă mai mulți bani și o reputație mai bună. Acest articol vă va arăta lecțiile pe care le-am învățat și greșelile pe care le-am făcut, astfel încât să vă puteți îmbunătăți dezvoltarea pluginului.

1. Rezolvați o problemă

Dacă pluginul dvs. nu rezolvă o problemă, acesta nu va fi descărcat. E la fel de simplu.

Luați pluginul Advanced Cron Manager (8.000+ instalări active). Ajută utilizatorii WordPress care au dificultăți în depanarea cronului. Pluginul a fost scris dintr-o nevoie - aveam nevoie de ceva care să mă ajute. Nu a fost nevoie să-l comercializez pe acesta, pentru că oamenii deja aveau nevoie de el. Le-a zgâriat mâncărimea.

Pe de altă parte, există Bug — fly on the screen plugin (70+ instalări active). Simulează aleatoriu o muscă pe ecran. Nu rezolvă cu adevărat o problemă, așa că nu va avea o audiență uriașă. A fost un plugin distractiv de dezvoltat, totuși.

Concentrați-vă pe o problemă. Când oamenii nu văd că SEO funcționează bine, instalează un plugin SEO. Când oamenii doresc să-și accelereze site-ul, instalează un plugin de cache. Când oamenii nu pot găsi o soluție la problema lor, atunci găsesc un dezvoltator care scrie o soluție pentru ei.

După cum atestă David Hehenberger în articolul său despre scrierea unui plugin de succes, nevoia este un factor cheie în decizia utilizatorului WordPress de a instala un anumit plugin.

Dacă aveți ocazia să rezolvați problema cuiva, riscați.

2. Susțineți produsul dvs

„3 din 5 americani ar încerca o nouă marcă sau o companie nouă pentru o experiență de servicii mai bună. 7 din 10 au spus că sunt dispuși să cheltuiască mai mult cu companii despre care cred că oferă servicii excelente.”

— Nykki Yeager

Nu vă neglijați sprijinul. Nu o tratați ca pe o necesitate, ci mai degrabă ca pe o oportunitate.

Asistența de bună calitate este esențială pentru ca pluginul dvs. să crească. Chiar și un plugin cu cel mai bun cod va primi niște bilete de asistență. Cu cât mai mulți oameni vă folosesc pluginul, cu atât veți primi mai multe bilete. O experiență de utilizator mai bună vă va aduce mai puține bilete, dar nu veți ajunge niciodată la inbox 0.

De fiecare dată când cineva postează un mesaj într-un forum de asistență, primesc imediat o notificare prin e-mail și răspund cât de curând pot. Se plătește. Marea majoritate a recenziilor mele bune au fost câștigate datorită suportului. Acesta este un efect secundar: un sprijin bun se traduce adesea în recenzii de 5 stele.

Când oferiți asistență excelentă, oamenii încep să aibă încredere în dvs. și în produsul dvs. Și un plugin este un produs, chiar dacă este complet gratuit și open-source.

Sprijinul bun este mai complex decât scrierea unui răspuns scurt o dată pe zi. Când pluginul tău câștigă tracțiune, vei primi mai multe bilete pe zi. Este mult mai ușor de gestionat dacă ești proactiv și răspunzi la întrebările clienților chiar înainte ca aceștia să le întrebe.

Iată o listă cu câteva acțiuni pe care le puteți întreprinde:

• Creați o secțiune de întrebări frecvente în depozitul dvs.
• Fixați firul „Înainte să întrebați” în partea de sus a forumului dvs. de asistență, evidențiind sfaturile de depanare și Întrebările frecvente.
• Asigurați-vă că pluginul dvs. este simplu de utilizat și că utilizatorii știu ce ar trebui să facă după ce îl instalează. UX este important.
• Analizați întrebările de asistență și remediați punctele dureroase. Creați un forum în care oamenii să poată vota pentru funcțiile pe care le doresc.
• Creați un videoclip care arată cum funcționează pluginul și adăugați-l pe pagina principală a pluginului dvs. din depozitul WordPress.org.

Nu contează cu adevărat ce software utilizați pentru a vă susține produsul. Forumul de asistență oficial al WordPress.org funcționează la fel de bine ca e-mailul sau propriul sistem de asistență. Folosesc forumul WordPress.org pentru pluginurile gratuite și propriul meu sistem pentru pluginurile premium.

3. Nu folosi Composer

Composer este un software de gestionare a pachetelor. Un depozit de pachete este găzduit pe packagist.org și le puteți descărca cu ușurință în proiectul dvs. Este ca NPM sau Bower pentru PHP. Gestionarea pachetelor de la terțe părți așa cum o face Composer este o practică bună, dar nu o utilizați în proiectul dvs. WordPress.

Știu, am aruncat o bombă. Lasă-mă să explic.

Composer este un software grozav. Îl folosesc eu însumi, dar nu în proiecte publice WordPress. Problema constă în conflicte. WordPress nu are niciun manager global de pachete, așa că fiecare plugin trebuie să încarce propriile dependențe. Când două plugin-uri încarcă aceeași dependență, provoacă o eroare fatală.

Nu există cu adevărat o soluție ideală pentru această problemă, dar Composer o înrăutățește. Puteți grupa dependența în sursă manual și puteți verifica întotdeauna dacă sunteți în siguranță să o încărcați.

Problema Composer cu pluginurile WordPress încă nu este rezolvată și nu va exista nicio soluție viabilă la această problemă în viitorul apropiat. Problema a fost pusă în urmă cu mulți ani și, după cum puteți citi în articolul WP Tavern, mulți dezvoltatori încearcă să o rezolve, fără nici un fel de noroc.

Cel mai bun lucru pe care îl puteți face este să vă asigurați că condițiile și mediul sunt bune pentru a vă rula codul.

4. Sprijiniți în mod rezonabil versiunile PHP vechi

Nu acceptați versiuni foarte vechi de PHP, cum ar fi 5.2. Problemele de securitate și întreținerea nu merită și nu veți câștiga mai multe instalări din acele versiuni mai vechi.

Utilizați PHP 5.6 ca cerință minimă, chiar dacă suportul oficial va fi renunțat la sfârșitul anului 2018. WordPress în sine necesită PHP 7.2.

Există o mișcare care descurajează suportul pentru versiunile PHP vechi. Echipa Yoast a lansat biblioteca Whip, pe care o puteți include în pluginul dvs. și care afișează utilizatorilor informații importante despre versiunea lor PHP și de ce ar trebui să facă upgrade.

Spuneți-le utilizatorilor ce versiuni acceptați și asigurați-vă că site-ul lor nu se defectează după ce pluginul dvs. este instalat pe o versiune prea redusă.

5. Concentrați-vă pe codul de calitate

Scrierea unui cod bun este greu la început. Este nevoie de timp pentru a învăța principiile și modelele de design „SOLID” și pentru a schimba vechile obiceiuri de codare.

Odată mi-a luat trei zile să afișez un șir simplu în WordPress, când am decis să rescriu unul dintre pluginurile mele folosind practici de codare mai bune. A fost frustrant să știu că ar fi trebuit să dureze 30 de minute. Schimbarea mentalității a fost dureroasă, dar a meritat.

De ce a fost atât de greu? Pentru că începi să scrii cod care pare la început exagerat și nu foarte intuitiv. M-am tot întrebat: „Este cu adevărat nevoie de asta?” De exemplu, trebuie să separați logica în clase diferite și să vă asigurați că fiecare este responsabilă pentru un singur lucru. De asemenea, trebuie să separați clase pentru traducere, înregistrarea tipului de post personalizat, gestionarea activelor, gestionarea formularelor etc. Apoi, compuneți structurile mai mari din obiectele mici simple. Asta se numește injecție de dependență. Este foarte diferit de a avea clase „front end” și „admin”, în care îți înghesui tot codul.

Cealaltă practică contraintuitivă a fost păstrarea tuturor acțiunilor și filtrelor în afara metodei constructorului. În acest fel, nu invocați nicio acțiune în timp ce creați obiectele, ceea ce este foarte util pentru testarea unitară. De asemenea, aveți un control mai bun asupra metodelor care sunt executate și când. Mi-aș dori să știu asta înainte de a scrie un proiect cu o buclă infinită cauzată de acțiunile din metodele constructorului. Aceste tipuri de erori sunt greu de urmărit și greu de remediat. Proiectul trebuia refactorizat.

Cele de mai sus sunt doar câteva exemple, dar ar trebui să cunoașteți principiile SOLID. Acestea sunt valabile pentru orice sistem și orice limbaj de codare.

Când urmați toate cele mai bune practici, ajungeți la punctul în care fiecare caracteristică nouă pur și simplu se potrivește. Nu trebuie să modificați nimic sau să faceți excepții de la codul existent. Este uimitor. În loc să devină mai complex, codul tău devine mai avansat, fără a pierde flexibilitatea.

De asemenea, formatați codul în mod corespunzător și asigurați-vă că fiecare membru al echipei dumneavoastră respectă un standard. Standardele vă vor face codul previzibil și mai ușor de citit și testat. WordPress are propriile standarde, pe care le poți implementa în proiectele tale.

6. Testează-ți pluginul înainte de timp

Am învățat această lecție pe calea grea. Lipsa testării m-a determinat să lansez o nouă versiune a unui plugin cu o eroare fatală. De două ori. De ambele ori, am primit un rating de 1 stea, pe care nu l-am putut transforma într-o recenzie pozitivă.

Puteți testa manual sau automat. Travis CI este un produs de testare continuă care se integrează cu GitHub. Am construit o suită de teste foarte simplă pentru pluginul meu de notificare, care verifică doar dacă pluginul poate porni corect pe fiecare versiune PHP. În acest fel, pot fi sigur că pluginul nu conține erori și nu trebuie să acord multă atenție testării lui în fiecare mediu.

Fiecare test automat durează o fracțiune de secundă. 100 de teste automate vor dura aproximativ 10 minute, în timp ce testarea manuală necesită aproximativ 2 minute pentru fiecare caz.

Cu cât investiți mai mult timp în testarea pluginului dvs., cu atât mai mult vă va economisi pe termen lung.

Pentru a începe cu testarea automată, puteți utiliza comanda WP-CLI \\`wp scaffold plugin-test\\`, care instalează toată configurația de care aveți nevoie.

7. Documentați-vă munca

Este un clișeu că dezvoltatorilor nu le place să scrie documentație. Este cea mai plictisitoare parte a procesului de dezvoltare, dar puțin merge un drum lung.

Scrieți cod de auto-documentare. Acordați atenție numelor de variabile, funcții și clase. Nu faceți structuri complicate, cum ar fi cascade care nu pot fi citite ușor.

O altă modalitate de a documenta codul este să utilizați „blocul document”, care este un comentariu pentru fiecare fișier, funcție și clasă. Dacă scrieți cum funcționează funcția și ce face, va fi mult mai ușor de înțeles când va trebui să o depanați peste șase luni. Standardele de codare WordPress acoperă această parte forțându-vă să scrieți blocurile de documente.

Folosirea ambelor tehnici vă va economisi timpul de scriere a documentației, dar documentația codului nu va fi citită de toată lumea.

Pentru utilizatorul final, trebuie să scrieți articole de înaltă calitate, scurte și ușor de citit, care să explice cum funcționează sistemul și cum să-l folosească. Videoclipurile sunt și mai bune; mulți oameni preferă să urmărească un scurt tutorial decât să citească un articol. Nu se vor uita la cod, așa că ușurează-le viața. O documentare bună reduce, de asemenea, biletele de asistență.

Concluzie

Aceste șapte reguli m-au ajutat să dezvolt produse de bună calitate, care încep să fie o afacere de bază la BracketSpace. Sper că vă vor ajuta și în călătoria dvs. cu pluginurile WordPress.

Spune-mi în comentarii care este regula ta de aur de dezvoltare sau dacă ai găsit vreuna dintre cele de mai sus deosebit de utilă.