O poveste despre utilizarea Composer într-un plugin WordPress

Această piesă a fost contribuită de autorul invitat Peter Suhm. Peter este un dezvoltator web din Țara Danezilor. El este creatorul WP Pusher și un mare dependent de călătorii, aducându-și munca împreună cu el pe măsură ce merge.

Zilele trecute am postat un avertisment despre utilizarea Composer în pluginurile WordPress pe blogul WP Pusher. Această postare a atras multă atenție și simt nevoia să clarific câteva puncte care nu au fost toate clare pentru toată lumea. Articolul a fost, de asemenea, puțin greoi pe chestii tehnice, așa că în această postare voi încerca să-mi clarific punctul principal, folosind o narațiune simplă pentru a-l ilustra.

O narațiune

Să ne imaginăm pentru o vreme că tu și cu mine suntem amândoi autori de pluginuri. Amandoi avem o idee grozava pentru un plugin pe care dorim sa il distribuim prin WordPress.org. Dorim să includem câteva funcții premium în pluginurile noastre pe care utilizatorii versiunii gratuite le pot debloca introducând o cheie de licență.

Avem nevoie de un cod care poate face față acestui proces. Amândoi ne dăm seama că probabil că această problemă a fost deja rezolvată de altcineva. Niciunul dintre noi nu este fan al reinventării roții, așa că mergem la Packagist și introducem „manager de licență”. Se pare că presupunerea noastră a fost justificată. Yoast are deja un pachet care se poate ocupa de asta. Amândoi decidem să facem un composer require yoast/license-manager . Ușor de gălăgie. Acum putem continua să lucrăm la ceva care contează cu adevărat - caracteristicile de bază ale pluginurilor noastre respective.

Înainte rapid, gata să vă lansați pluginul, vă dați seama de ceva: utilizatorul dvs. nu are neapărat Composer la îndemână când vă instalează pluginul de pe WordPress.org, așa că cum vor obține codul pentru managerul de licențe? Această situație este puțin enervantă, deoarece singura soluție pe care o vedeți cu adevărat este să trimiteți întregul director de vendor generat de Composer în plugin-ul dvs. și să îl trimiteți către WordPress.org. Știi că nu așa ar trebui să funcționeze Composer, ci orice. Nu prea ai alte variante.

Între timp, am ajuns la aceeași concluzie cu pluginul meu. Doar includeți codul de manager de licență și terminați cu el.

Înainte rapid încă o dată, ambele plugin-uri trăiesc acum în depozitul WordPress.org și, din când în când, cineva decide să facă upgrade la versiunile noastre premium. Totul pare să fie în regulă și amândoi suntem recunoscători că am putut doar să folosim codul pe care Yoast l-a oferit cu generozitate și nu a trebuit să reinventăm roata.

Într-o zi, primești un e-mail ciudat. Un client se confruntă cu un comportament cu adevărat ciudat atunci când încearcă să deblocheze funcțiile premium. Nu are sens pentru tine, pentru că nimeni altcineva nu a mai raportat asta. După ore întregi de depanare, îi ceri în sfârșit clientului să dezactiveze orice altceva, cu excepția pluginului tău și apoi: Funcționează! Hmm. Pluginul tău pare să fie cumva incompatibil cu un alt plugin. Pluginul meu.

Îți dai seama de asta după ore în care ai parcurs codul sursă al tuturor celorlalte plugin-uri instalate de client. Când îți dai seama că amândoi folosim managerul de licență, sună un clopoțel. Ar putea fi asta cu adevărat? Dacă da, de ce nu există fatal errors: cannot redeclare class a fost cauzată de PHP?

Cu o săptămână mai devreme, am transformat versiunea necesară a managerului de licențe din pluginul meu la cea mai recentă versiune, care includea câteva modificări (fictive) de neregulă. După și mai multe depanare și var_dump() 'ing, îți dai seama că versiunea mea a managerului de licențe este și versiunea încărcată de PHP în pluginul tău. Ti se pare cu adevărat ciudat, deoarece ai nevoie în mod special de o altă versiune a managerului de licențe cu Composer. Nu prea știi ce să faci în privința asta.

Pentru că într-adevăr nu poți face mare lucru în privința asta.

Ce s-a intamplat aici?

Acum că am văzut cu toții problema, să luăm un moment pentru a trece prin ceea ce sa întâmplat de fapt în narațiune. În primul rând, de ce PHP nu a provocat o eroare fatală când două clase aveau, evident, același nume, pe care amândoi am inclus managerul de licență?

Motivul pentru aceasta este că am folosit un autoloader generat de Composer. Acest autoloader scanează structura directoarelor dependențelor noastre și adaugă fiecare clasă la autoloader. Dacă o clasă a fost deja adăugată, Composer o va ignora. În tăcere. Am scris un mic exemplu de cod dacă vrei să-l vezi singur. Este pe GitHub.

De ce versiunea mea a managerului de licențe a fost inclusă înaintea ta?

Acest lucru s-a întâmplat deoarece pluginul meu avea un nume care a făcut ca acesta să fie încărcat înainte de al tău. Poate că, în viitor, vom numi cu toții pluginurile noastre „Aaaaaa My Plugin” pentru a fi încărcate mai întâi!

Deci, pentru a rezuma, principala problemă aici este că nu vom ști ce versiune a dependențelor noastre ne este disponibilă în ce moment. Pur și simplu depinde de factori pe care nu îi putem controla pe deplin ca dezvoltatori de pluginuri.

Este aceasta o problemă specifică Compozitorului?

Nu. Chiar nu este. WordPress nu are o modalitate de a trata codul terților în pluginuri sau teme. Aici este problema. Motivul pentru care vorbesc despre Composer este că acesta capătă multă acțiune în zilele noastre. Dacă dezvoltatorii WordPress doresc să folosească Composer în pluginuri lansate prin WordPress.org, acest lucru trebuie rezolvat cumva. În caz contrar, vom vedea un adevărat haos atunci când toate pluginurile vor începe să fie incompatibile între ele, deoarece folosesc versiuni diferite. Bun venit în iadul depanării.

Ce putem face în privința asta?

Cineva care a fost cu adevărat îngrijorat de acest lucru și a muncit din greu pentru a găsi o posibilă soluție este Coen Jacobs. Am decis să iau legătura cu Coen și să-l întreb dacă crede că putem face ceva în privința asta.

Mulți dezvoltatori includ deja codul terță parte în pluginurile lor. Este aceasta cu adevărat o problemă?

Da, aceasta este deja o problemă în ecosistemul de pluginuri. Va deveni și mai rău atunci când mai mulți oameni își vor da seama că este o idee bună să pună funcționalități comune în pachete separate. Aceste pachete pot fi apoi combinate cu mai multe plugin-uri și problema va apărea din ce în ce mai mult. Am vorbit cu câțiva dezvoltatori care au trecut deja prin iadul de depanare, încercând să afle ce cauzează această problemă.

Mergând mai departe, ați sugera dezvoltatorilor să nu mai includă codul terță parte în pluginurile lor?

Sunt un pic sfâșiat pe acest subiect. Din punctul de vedere al dezvoltatorilor, nu are sens să le spunem oamenilor să nu mai grupeze pachete partajate în pluginurile lor. Pe de altă parte, toată lumea își dorește cea mai bună experiență de utilizator posibilă pentru utilizatorii lor. Este o decizie grea de luat cu siguranță.

În acest moment, vreau să promovez dezvoltarea legată de WordPress. Doresc să partajez biblioteci și să folosesc biblioteci partajate de alții. Nimeni nu ar trebui să reinventeze roata din nou și din nou. Așa că mi-aș asum riscul de a întâlni astfel de probleme, rezolvând problemele pe măsură ce apar.

Acest lucru înseamnă, de asemenea, că voi face tot posibilul pentru a găsi o soluție pe termen lung pentru această problemă. Mai mulți oameni vor începe să folosească Composer, mai mulți oameni vor combina biblioteci cu pluginurile lor. Această problemă va apărea mai des, așa că este timpul să o remediați.

Ce pot face dezvoltatorii de pluginuri pentru a preveni această problemă?

Există o soluție pe care am văzut-o deja pe unii oameni. Practic, se reduce la mutarea dependenței dvs. în spațiul de nume al pluginului dvs. Danny van Kooten a făcut asta pentru unul dintre pluginurile sale. Totuși, acest lucru nu este ideal. De fiecare dată când își actualizează dependențele, trebuie să parcurgă toate fișierele și să schimbe din nou spațiile de nume. Acum, aceasta nu este o sarcină atât de mare pentru o bibliotecă relativ mică precum Pimple, ci o întreprindere masivă pentru bibliotecile mai mari.

Totuși, acest lucru se poate face numai cu spații de nume, așa că va trebui să faceți ca pluginul dvs. să necesite și PHP 5.3+. Nu o să mint, cred că fiecare plugin ar trebui să înceapă să facă asta mai devreme sau mai târziu, dar cu siguranță este ceva de care trebuie să iei în considerare atunci când te decizi să faci asta.

Care ar fi soluția ideală, dacă există?

Situația ideală ar fi folosirea unui fel de manager de dependență. Există desigur Composer, cel mai folosit manager de dependențe. Composer este foarte greu, dacă nu imposibil, de utilizat pentru marea majoritate a utilizatorilor WordPress. Până la urmă, este un instrument pentru dezvoltatori.

WordPress ar trebui să faciliteze acest lucru pentru utilizatorii săi finali, permițând totuși dezvoltatorilor să utilizeze aproape orice pachet doresc. Având în vedere acest gând, am început să pun împreună pluginul WordPress Composer Installer, care face toată munca grea Composer în timp ce oamenii instalează pluginuri așa cum au făcut-o întotdeauna. De îndată ce voi reuși să termin acest lucru, îl voi integra corect în întregul flux de instalare a pluginurilor.

Acum, poate într-o zi, acest lucru poate fi integrat în WordPress de bază. Mai are un drum lung de parcurs, dar dovada conceptului funcționează deja.

Concluzie

Dacă ați citit până aici, în primul rând: Vă mulțumesc. În al doilea rând, sper că acum vedeți cum este ceva care în cele din urmă va deveni o problemă. Situația noastră actuală este foarte frustrantă, pentru că pur și simplu nu avem instrumentele de care avem nevoie. Totuși, cred că este important să continuăm să vorbim despre asta și să ne asigurăm că noi toți, ca dezvoltatori WordPress, înțelegem potențialele probleme cauzate de dependențele conflictuale ale terților din codul nostru.

În cele din urmă, vreau să menționez încă o dată că aceasta nu este o problemă a Composer. Este o problemă cu WordPress.