Apăsați aceasta: Enigma de compatibilitate inversă cu WP-CLI cu Alain Schlesser

Bun venit la Press This, podcastul comunității WordPress de la WMR. Aici gazda David Vogelpohl se așează cu invitații din întreaga comunitate pentru a vorbi despre cele mai mari probleme cu care se confruntă dezvoltatorii WordPress. Următoarea este o transcriere a înregistrării originale.

Produs de RedCircle

David Vogelpohl: Salutare tuturor și bine ați venit la Press This podcasturile comunității WordPress pe WMR. Acesta este gazda dvs., David Vogelpohl, susțin comunitatea WordPress prin rolul meu la WP Engine și îmi place să vă aduc tot ce este mai bun din comunitate să vă auziți în fiecare săptămână la presa aceasta ca un memento, mă puteți găsi pe Twitter @wpdavidv , sau vă puteți abona pentru a apăsa pe iTunes, iHeartRadio, Spotify sau puteți descărca cele mai recente episoade de pe wmr.fm. În acest episod, vom vorbi despre conectorul de compatibilitate compatibil cu WP CLI. Și ni se alătură pentru această conversație cineva care știe destul de multe despre WP CLI. Suntem colaboratori pentru WP CLI al XMPP. Aș dori să-i urez bun venit lui Alain Schlesser. Alain, bine ai venit la Press This.

Alain Schlesser: David. Buna ziua. Grozav să fiu aici.

DV: Mă bucur să te am. Este cel puțin a doua oară când participi la această emisiune. V-am pus întrebări despre WP CLI de-a lungul anilor și îmi place foarte mult să vă am. Pentru cei care ascultă. WP CLI este o parte critică a ecosistemului WordPress, în special în ceea ce privește automatizarea și fluxurile de lucru și alte aspecte ale versiunilor WordPress și ceea ce vom acoperi astăzi este împreună cu gândurile despre ceea ce s-a realizat cu BPCL AI în ultimul an. Ce schimbări de compatibilitate inversă se așteaptă. Știi că compatibilitatea inversă este o mare parte a beneficiului WordPress, dar și a provocării dezvoltatorilor de software și, desigur, cum sunt abordate aceste provocări și partea leului despre modurile în care poți contribui la WP CLI până la sfârșit. Așa că aștept cu nerăbdare interviul. Așa că vă voi pune aceeași întrebare pe care o pun fiecărui oaspete și v-am mai întrebat asta, dar vreau să o spuneți din nou dacă puteți. Ați putea să-mi spuneți despre povestea dvs. despre originea WordPress? Când ați folosit prima dată WordPress?

AS: Da, așa că povestea mea de origine este ca și cum majoritatea poveștilor WordPress încep cu un ocol mai mic. Am lucrat ca agent guvernamental în Luxemburg. Și la un moment dat chiar m-am săturat de politica tuturor. Am vrut să fac altceva cu viața mea și să încerc o altă carieră. Și am decis să fac dezvoltare freelancer, pentru că deja făcusem dezvoltare înainte, dar nu am făcut-o niciodată ca freelancer. Și când a venit timpul să mă hotărăsc pe ce să mă concentrez, m-am uitat doar la ce era acolo și la ce avea cea mai mare cotă de piață la un moment dat. S-a întâmplat să fie WordPress, așa cum știm cu toții. Și tocmai am început cu dezvoltarea WordPress pentru că m-am gândit că ar fi cel mai ușor să obții clienți ca un freelancer proaspăt care începe de la 0.

DV: Am ales WordPress ca platformă de alegere din același motiv pentru care îmi amintesc o agenție grozavă dintre Drupal și WordPress și cred că la acea vreme Drupal era alegerea corectă, dar nu era ceea ce spuneau oamenii despre lucruri precum Oh, dar acesta a fost 2010. Știi, chiar la vârful tipurilor de postări personalizate și al meta-câmpurilor. Și mă întreb doar când ați luat această decizie în ce an aproximativ ascultători

AS: um, asta a fost 2014 ceva din 2014 și cred că WordPress era în jurul versiunii 332 sau ceva de genul ăsta. Nu sunt sigur să fiu sincer.

DV: Așadar, pentru tine, ca dezvoltator independent, beneficiul site-urilor de postare personalizate fusese deja lansat. Și așa ai pătruns într-un fel în acest ecosistem și ai văzut acele capacități. Un WP CLI mai era încă doi ani distanță, totuși. Deci, bănuiesc că nu a răspuns pe deplin la tot ce aveai nevoie ca dezvoltator, dar este grozav să te văd gestionând acel proiect acum. Acum, înțelegeți că lucrați cu XMPP. Și ne spunem ce face XMPP și ce faci tu acolo.

AS : So X Delta P este o agenție care se concentrează pe proiecte WordPress de înaltă performanță de nivel enterprise. Accentul principal este pe performanță, dar nu numai în ceea ce privește cât de repede se încarcă site-ul, ci și cât de bine se întâlnește cu afacerea dvs. Lucrez cu XWP de aproximativ doi ani și jumătate și în acel timp, am lucrat împreună la pluginul amfa WordPress și apoi la experiența de pagină pentru pluginul WordPress.

DV: sună ca proiecte MIDI. Cu siguranță sunt familiarizat cu ele, nu am pentru WordPress, nu am jucat încă cu experiența paginii și știu că știi că XMPP am avut câțiva oameni de la XMPP de fapt la presa asta. Ei fac niște proiecte foarte grozave. Se pare că te apuci de lucru la unele dintre cele mai tari. Și asta e minunat. În ceea ce privește subiectul nostru pentru spectacol, totuși, astăzi, WP CLI de la nivel înalt, presupunând că vor exista unii ascultători care nu au idee ce este WP CLI, mă întrebam dacă ați putea să-l încadrați astfel încât să poată înțelege ce WP CLI este.

AS: Da, sigur. Deci WordPress are back end-ul său de administrator unde faci toată întreținerea site-ului unde faci modificările în care configurezi opțiunile. Și WP CLI este o interfață diferită pentru controlul site-ului dvs. WordPress. Este o interfață pe care o puteți utiliza din linia de comandă. Deci tastați comenzi în formă de text pentru a vă controla site-ul. Vă permite să faceți tot ceea ce face backend-ul admin și multe altele. Și, folosind linia de comandă care se întâmplă să fie o interfață mult mai expresivă decât backend-ul de administrare, puteți rezolva o mulțime de probleme care sunt foarte specifice cazurilor dvs. de utilizare în care nu există niciun element prefabricat de interfață cu utilizatorul în spatele admin. Sfârşit. Puteți combina și potrivi comenzile WP CLI pentru a rezolva aceste probleme oriunde. Și apoi, ca un pas mai departe, orice puteți face cu WP CLI, îl puteți pune și într-un script și, în cele din urmă, astfel încât să vă puteți automatiza toate procesele de gestionare și să le puteți executa chiar de la distanță. Deci, există multă putere prin accesarea unei interfețe bazate pe text și WP CLI vă permite să faceți asta cu WordPress.

DV: Wow, a fost foarte elegant. Cred că ai o altă carieră doar în marketing. Acesta a fost un mod foarte frumos de a încadra VCI și nu uitați să descrieți, deși este foarte bun. Bine, din punctul meu de vedere, și am, știți, o mică foaie de cheat pentru cronologia momentelor cheie din istoria WordPress pe care o folosesc atunci când aud poveștile despre originea oamenilor pentru a-i întreba despre când au intrat și ce se întâmplă la timpul. Și WP CLI este de fapt unul dintre momentele cheie din istoria WordPress pe care le spun aici. În 2016, în perspectiva cronologiei, o mențin așa că cred că este super important. Și știu că știți că există acest impuls pentru a obține din ce în ce mai multe caracteristici și capabilități lansate, dar sunt doar curios să spun că lotul recent de lansări legate de caracteristici sau refactorizare sau orice altceva, de ce ați fost cel mai încântat în lansările recente ?

AS: O caracteristică foarte interesantă este adăugarea de contexte globale pe care le avem pentru că, de când a fost creat YouTube, s-a discutat întotdeauna despre contextul în care instrumentul ar trebui să se execute, dacă ar trebui să se execute ca proces front-end sau proces de administrare sau ceva de genul. intre. Și toate abordările au venit întotdeauna cu propriul set de probleme. Deci nu a existat niciodată o soluție curată. Și modul în care CLI se execută în mod implicit este acest amestec ciudat care nu este nici un proces de administrare, nici un proces frontal. Din motive istorice, dar asta înseamnă că unele procese care verifică dacă cererea curentă este o solicitare de administrator, de exemplu, vor eșua automat. Acest lucru se întâmplă cel mai notoriu cu pluginurile și temele premium atunci când rulați pentru a rula actualizările. Deci, de obicei, veți vedea acele actualizări pe care le funcționează în backend-ul admin. Dar cu WP CLI, administratorii nu sunt actualizările vizibile sau nu funcționează conform așteptărilor. Acest lucru se datorează faptului că logica personalizată care gestionează aceste actualizări pentru fiecare plugin, ei verifică dacă procesul de administrare nu încetinește, desigur, front-end-ul și care execută automat WP CLI. Deci, acum, cu acest nou indicator de context, putem alege contextul în care să rulăm și care vă permite să comutați contextul într-un context de administrare. De exemplu, când faceți o actualizare a pluginului și apoi dintr-o dată toate integrările premium funcționează exact așa cum era de așteptat. Acest lucru este foarte incitant. Ne pare rău, aceasta nu este o nouă caracteristică foarte interesantă. A fost construit în colaborare cu cloudways, deoarece în prezent testăm într-o fază în care nu este activat implicit. Prin urmare, trebuie să faceți manual această furnizare automată va deveni implicită în următoarea iterație.

DV: Excelent, excelent. Văd de ce ai fi încântat de asta. Și cred că este foarte inteligent că te-ai gândit cum ar fi, bine, va exista front-end sau admin, dar într-adevăr, oferind dezvoltatorului posibilitatea de a alege, îți oferă abilitatea de a rezolva, sau cel puțin dezvoltatorul să rezolve pentru mai multe cazuri de utilizare simultan. Văd de ce ai fi entuziasmat de asta. gândindu-mă în special la acel caz de utilizare al eroului și neputând reda actualizări pentru pluginuri premium. Este un caz de utilizare destul de comun. Și imaginați-vă că multe altele ies în cascadă din asta. Am câteva întrebări, totuși, despre, știți, cum să pătrundem în foaia de parcurs și să mă gândesc la considerații de compatibilitate inversă. Dar ne vom lua prima pauză. Vom reveni imediat. Este timpul să vă conectați la o pauză publicitară. Rămâneți pe fază pentru mai multe apăsări într-un moment. Toată lumea este binevenită să apăsăm pe acest podcast-ul comunității WordPress pe care îl ofer lui Omar, gazda dumneavoastră David Vogel. Paul. Sunt în mijlocul unui interviu cu un locator de lansare despre WP CLI și câțiva conectori de compatibilitate inversă. Singur, chiar înainte de pauză, împărtășeai despre caracteristica ta preferată sau WP CLI recent, care a fost contextul global care a schimbat semnalul, fie că este vorba despre un proces frontal sau de administrare. Și mi s-a părut că a fost foarte inteligent. Orice ai vrut să adaugi la asta înainte de a ajunge la felul de viitoare foaie de parcurs și compatibilitatea cu înapoi.

AS: Da, am vrut să adaug că aștept cu nerăbdare asta, deoarece aceasta este probabil una dintre cele mai frecvente solicitări de asistență pe care le primește WP CLI. De ce funcționează actualizările în WP CLI când funcționează în compartimentul de administrare?

DV: Da, că procesul de repo cu plugin-uri premium își ridică capul și o mulțime de locuri diferite pe care le găsesc în WordPress, dar da, pot vedea unde este o capacitate de bază în care sunt oamenii, de ce naiba nu face asta ? Este atât de simplu pentru WordPress. Asta e uimitor. Pe măsură ce vă gândiți la viitorul WP CLI, vreau să aduc considerații de compatibilitate inversă într-o secundă, dar ceea ce ne plac primele două sau trei caracteristici de care sunteți încântați pentru viitor.

AS: Deci, ceea ce am planificat de ceva vreme acum este să revizuiesc complet schelele WP CLI. Comanda de schele este o comandă care utilizează șabloane pentru a vă permite să generați cod, cum ar fi generarea unei teme goale, generarea unui plugin gol. Și am vrut să finalizez Super Bowl-ul să fie mai puțin un instrument Noțiuni introductive și mai mult un ajutor constant de dezvoltare, așa cum este în spațiul Laravel, cu comanda autism, unde fiecare concept care este folosit în dezvoltarea WordPress ar avea propria sa comandă pentru a generează versiunea canonică a acesteia. Și asta nu numai că ar accelera drastic dezvoltarea, ci ar fi și un instrument extraordinar de învățare și ar ajuta la modelarea calității generale în spațiul WordPress.

DV: Acela sună foarte frumos și pot, de asemenea, să încep să-mi imaginez unde ar putea apărea compatibilitatea inversă pentru. Există alte caracteristici asemănătoare foii de parcurs? Acesta a fost unul destul de bun oricare altul Vrei să adaugi?

AS: În prezent, se lucrează și la o rescrie a comenzii Profil, care este încă o comandă terță parte. Nu este încă la pachet. Dar, de îndată ce acea rescrie s-a terminat, vreau, de asemenea, să grupez acea comandă, astfel încât toată lumea să aibă o modalitate ușoară de profilare. Site-ul web solicită și văzând în ce acțiuni am nevoie, urmăriți ce filtre sunt blocate principalele blocaje de performanță.

DV: Asta e încă una bună. Bine, deci ai două articole suculente ale foii de parcurs. Sunt sigur că mai mult decât doar asta, desigur, este că te gândești la viitor și alți contribuitori se gândesc la viitor. Dar, evident, compatibilitatea inversă este un lucru important în WordPress. Deci, ce considerații îți cântăresc în minte atunci când te gândești la capacitatea ta de a îndeplini această foaie de parcurs?

AS: Da, WP CLI este modul în care funcționează, activitatea sa internă este direct legată de politica de compatibilitate inversă a nucleului WordPress. În acest moment, WordPress Core încă acceptă un minim de PHP 5.6 WP CLI, de asemenea, face acest lucru. Și există o politică pentru WP CLI conform căreia, indiferent de minimul WordPress, ori de câte ori se schimbă. WP CLI va amâna această modificare cu cel puțin un an pentru a oferi tuturor șansa de a utiliza WP CLI pentru a migra de pe vechile site-uri. Spre noile site-uri. Și pentru că WP CLI este de obicei instrumentul care este folosit pentru migrarea de pe site-uri vechi, trebuie să funcționeze în continuare la exporturi, oameni buni. Deci, WP CLI nu poate conduce niciodată abordarea în sprijinirea versiunilor mai noi de PHP și lucruri de genul acesta. Pentru că atunci ar eșua scopul principal, care este să obțină acces la vechile site-uri și să îți permită să faci mișcarea. Așadar, în această privință, este foarte greu să faci dezvoltarea în WP CLI într-un mod care să mențină codul proaspăt și care poate fi întreținut, dar totuși să respecte această cerință minimă PHP foarte scăzută cu nucleul WordPress, care provoacă din ce în ce mai multe probleme.

DV: când vor sau știți când nucleul ar ridica numărul minim de versiune de 5.6. În continuare, aveți AB pentru că 5.6 este destul de multe variații trecute și este dificil să mențineți atât de mult în urmă, aveți o marfă când versiunile mai recente ar fi minim?

AS: Sincer, nu pot spune că am investit multă muncă în proiectul sub fericit, unde am o mulțime de mecanisme pentru a face posibil din punct de vedere tehnic ca codul WordPress să se deplaseze rapid către versiuni mai noi de PHP în acest moment, toate cerințele tehnice preliminare sunt Acolo. Este doar o chestiune de a lua o decizie. Și nu pot spune când se va întâmpla asta. Pentru că era deja planificat de ceva vreme, dar până acum nu s-a întâmplat nimic.

DV: Și așa din momentul în care se întâmplă, deși aveți un an după aceea când WP CLI își poate ridica versiunea PHP minimă acceptată. Există și alte părți ale stivei de software sau limbi sau orice altceva care, de asemenea, slăbesc atunci când vă gândiți la capacitatea dvs. de a livra pe foaia de parcurs sau este în principal PHP

AS: este în termeni de compatibilitate inversă? Este în principal php. WP CLI este construit în PHP și în scripturi Gherkin și shell. Așadar, cornița este un limbaj de testare care nu este cu adevărat o problemă, iar scripturile shell nu s-au schimbat de 20 de ani. Nu cred că vor fi probleme prea curând.

DV: Care este impactul, evident, menținerea software-ului compatibil cu versiunile foarte vechi de PHP este o provocare, dar ajută-mă să înțeleg cum este provocator? Care sunt compromisurile pe care trebuie să le faceți pentru că rămâneți la suportul pentru 5.6

AS: susținerea cinci la șase în sine nu este o afacere atât de mare. Este doar o versiune a limbajului și era o limbă mai urâtă. La acea vreme, dar încă unul foarte utilizabil. Problema este dacă doriți să puteți rula și pe cea mai nouă versiune de PHP. Deci trebuie să acoperiți întregul spectru. Și atâta timp cât nu creștem versiunea minimă, doar adăugăm din ce în ce mai multe versiuni pe care trebuie să le susțineți și cu PHP, dar acum cadența este că în fiecare an apare o nouă versiune majoră, așa că ei apelează este versiuni minore, dar în ceea ce privește caracteristicile sunt versiuni majore, iar ultimele versiuni au cunoscut schimbări mai mari și mai radicale în limbaj. Și acum este foarte greu să construiești mai multe construcții de nivel scăzut, mai de jos, astfel încât să funcționeze atât pe cinci, șase și pe opt doi în același timp și să se înrăutățească în timp. Și ceea ce se adaugă la asta este că instrumentele de care aveți nevoie pentru a lucra în PHP, trebuie să rulați teste unitare, trebuie să rulați teste funcționale și așa mai departe și așa mai departe. Toate aceste instrumente, se lipesc, se lipesc de cadența PHP pentru ceva cu unitatea PHP. De exemplu, acum este foarte greu să vă scrieți testele în așa fel încât testele în sine să funcționeze în toate versiunile unității PHP. Trebuie să utilizați pentru a acoperi toate aceste versiuni PHP.

DV: Bine , deci este ponderea tuturor acestor cohorte multiple, dacă vreți, PHP tip TA-uri de unități, și apoi bănuiesc că, de asemenea, probabil că aveți probleme cu știți cum utilizați funcțiile în diferite versiuni ca funcții noi. devin disponibile și sunt depreciate. Și se pare că colecția de tot ceea ce este munca suplimentară este o frecare care îți pune în greutate capacitatea de a oferi noi funcții, sună corect?

AS: Da, um, există și PHP care devine din ce în ce mai strict. Așadar, unde înainte, când trebuia să mapați mai multe versiuni de PHP și puteați să vă păstrați codul vag, astfel încât să nu afecteze nicio problemă de la o versiune sau alta. Acest lucru devine din ce în ce mai greu acum, deoarece HP aruncă o mulțime de notificări și avertismente și probleme de depreciere. Pentru cele mai mici detalii până acum, și uneori asta înseamnă că creați o funcție pe care trebuie să o rulați build de mai multe ori și să aveți un mecanism pentru a introduce versiunea corectă a acelei funcție, în funcție de versiunea de PHP pe care o rulați, care crește exponențiale la efortul de întreținere a tuturor.

DV: Da, asta are sens. Bine, ei bine, vreau să încep să explorez puțin despre, știi, cum te îmbraci și poate chiar părerile tale despre cum WordPress, în general, poate face mai bine și, știi, să îmbrace compatibilitatea inversă, dar noi' Ne vom lua ultima pauză și ne vom întoarce imediat. Este timpul să vă conectați la o pauză publicitară. Rămâneți pe fază pentru mai multe apăsări într-un moment. Ei bine, toți sunt bineveniți înapoi pentru a apăsa podcasturile acestei comunități WordPress pe W EMR. Suntem în mijlocul unei discuții cu un locator de lansare despre dilema de habitabilitate inversă cu WP CLI. Ar fi trebuit să aleg un titlu mai puțin răsucitor de limbi pentru această emisiune. Dar aici suntem. De mult, este o carte bună. Da, îmi place, trebuie să spun de trei ori repede înainte de a se termina. Dar bine, deci, înainte de pauză, vorbeai despre această problemă de întreținere exponențială pe măsură ce începi să te confrunți cu mai multe versiuni de PHP și nu știu dacă asta te face să te simți mai bine singur, dar ca 100% din motoarele WP clienții sunt corecționați în versiunile moderne de PHP, am forțat aceste actualizări, dar evident că nu toată lumea o face. Dreapta? Nu orice gazdă nu toți cei care găzduiesc un site web fac aceste lucruri și astfel se creează doar oshin puse deoparte și învechite, versiuni soft PHP sau chiar pluginuri WordPress. Și așa, această natură a WordPress-ului, știți, în această idee de compatibilitate inversă face parte din WordPress, puterea în popularitatea sa contează dacă o stabilesc singur. WP CLI trebuie să întârzie pentru că face o treabă pentru oamenii care trebuie să facă upgrade. Și ăsta e un lucru bun, nu? Aceasta este o parte bună a acestei dinamici. Dar mă întreb doar ce părere aveți despre modul în care WP CLI sau WordPress în ansamblu s-ar putea îmbunătăți în ceea ce privește păstrarea acelor părți bune și poate evitând mai multe părți proaste, cum ar fi cerințele exponențiale de întreținere ale compatibilității cu versiuni inverse. Ce părere aveți despre scrisul acela mare?

AS: Da, cred că acum suntem într-un punct în care WordPress face un dezaserviciu bazei sale de utilizatori, ținându-se de acea abordare extremă de compatibilitate inversă pe care o are în acest moment în ceea ce privește PHP, pentru că toate semnele par să indice faptul că că vom intra încet în faza în care nu mai putem menține WordPress să ruleze pe cele mai recente versiuni de PHP, ceea ce este o problemă reală. Și am avea nevoie de mult timp pentru a lucra la compatibilitate, deoarece modificările există și mai multe modificări se întâmplă în PHP în zilele noastre. Și singura modalitate de a rezolva acest lucru este de a avea o abordare continuă de adaptare la ciclul PHP, poate rămâne în urmă în urma PHP, dar nu poate avea o viteză mai mică decât PHP, ceea ce va face problema din ce în ce mai rău. Deci, trebuie să se potrivească cu viteza PHP, chiar dacă nu are în urmă toți doi ani în urmă. Și apoi trebuie să ne asigurăm că putem menține totul la unelte, testare, instrumente și așa mai departe, suficient de actualizate, astfel încât să putem lucra întotdeauna la suportul celei mai recente versiuni de PHP, pentru că așa cum arată acum , PHP nouă va fi probabil prima versiune, așa cum pare acum că WordPress nu va fi posibil să ne adaptăm dacă nu schimbăm abordarea. Sper că, bine, da.

DV: Voiam să spun că se pare că această problemă exponențială cu care ai de-a face pe WP CLI se cam agravează, dacă vrei, în WordPress, și se cam ridică dacă vrei, cu provocările pe care le-ai menționat. pentru PHP nouă. Și astfel încât să aibă sens în acest sens, acest fel de forță de a muta WordPress pentru a trebui să fie mai bine în ceea ce privește menținerea se potrivește cu acea viteză, astfel încât să nu rămână prea în urmă serviciilor și să rămână prea în urmă în versiunile PHP. În ultimele câteva minute aici, știu că există o mulțime de provocări cu compatibilitatea cu versiunea anterioară. Știu că ați oferit funcții grozave și doriți să oferiți mai multe. Și, așa cum am văzut o grămadă de colaboratori la Gutenberg și cum ar fi, simt că nu aș face un serviciu decât dacă am face un pic de dragoste WP CLI în acest podcast pentru colaboratori. Cum pot oamenii să contribuie la WP CLI pentru a menține această parte cu adevărat importantă a WordPress vie și să conducă?

AS: Deci, în primul rând, avem în echipa principală wordpress.org Slack. Avem un canal CLI. Așadar, poți să te uiți pe canalul respectiv și să saluti și să pui întrebări. Și dacă doriți să începeți, există întotdeauna oameni care sunt bucuroși să vă ajute să vă integrați în contribuțiile WP CLI. Există, de asemenea, site-ul web make wordpress.org/cli, care este punctul de intrare pentru toată documentația și link-uri către primele numere bune și așa mai departe și așa mai departe. Și atunci, în mod ideal, v-ați alătura uneia dintre zilele de colaborare a camerei web care se întâmplă din nou. Sunt foarte bucuros de asta. Pentru că în aceste zile de colaborator, oamenii vă pot ajuta să vă configurați propria mașină pentru a face o dezvoltare locală adecvată. Acest lucru va opri piesa live, deoarece uneori onboarding-ul este cel mai dificil obstacol pe care oamenii trebuie să-l instaleze.

DV: Da, pot să mărturisesc asta. Câțiva prieteni care se apucaseră să contribuie și ce au depășit. Știu că există destul de mulți oameni care au puține cursuri și instrucțiuni, desigur că WordPress are chestii în jurul asta și în ceea ce privește documentația, dar acesta este un punct foarte bun și zilele de colaborare care ajută la acest aspect. Mi-a plăcut și cum ai sunat să te înscrii pe canalul Slack. Îmi reamintește cum s-a implicat Mike Liddell cu WordPress, răspunzând la ceea ce comentez la postările pe blogul Mac Mullenweg, dar acea noțiune de a contribui într-un context social duce la ceva mai mare. Ei bine, asta a fost foarte tare. Vă mulțumim că v-ați alăturat astăzi.

AS: Mulțumesc că m-ai primit.

DV: Mă bucur că te am aici. Dacă doriți să aflați mai multe despre ceea ce face Alon și asta. Vă rugăm să vizitați make wordpress.org și căutați site-ul WP CLI sau găsiți-l în wordpress.org slack și canalul WP CLI. Mulțumim tuturor pentru că ați ascultat apăsarea acestui podcast-ul comunității WordPress pe WMR. Din nou, acesta a fost gazda dumneavoastră David Vogelpohl. Sprijin comunitatea WordPress prin rolul meu la WP Engine. Și îmi place să vă aduc tot ce este mai bun din comunitate aici în fiecare săptămână pe Press This.