Recapitulare intalnire PHP – 6 noiembrie

Aceasta recapitulare este un rezumat al PHP din aceasta saptamana Limbajul de scriptare web in care WordPress este arhitectat in principal. WordPress necesita intalnire PHP 5.6.20 sau mai mare. Acesta evidentiaza ideile si deciziile care au aparut in timpul acelei intalniri, atat ca mijloc de documentare, cat si pentru a oferi o imagine de ansamblu rapida pentru cei care nu au putut participa.

Jurnalul de chat al intalnirii.

Participanti: @bpayton @ flixos90 @jdgrimes @ mte90 @nerrad @overclokk @psykro @schlessera @vizkr

Rezumatul chatului

Agenda pentru aceasta saptamana a fost sa revizuiasca sugestiile pe care @ flixos90 le-a lucrat pentru sectiunea „Inainte de actualizarea PHP” care este disponibila in documentul Google, tinand cont de discutiile din ultimele saptamani.

Intrucat alte subiecte importante au aparut dupa ce agenda a fost stabilita, discutia a ajuns sa se invarta in jurul diferitelor subiecte, luand doar un varf scurt la document pana la sfarsitul reuniunii. Iata rezumatul discutiei:

• @ flixos90 a impartasit cateva vesti minunate despre instrumentul la care a lucrat echipa XWP, care a fost mentionat de cateva ori inainte in alte intalniri: Instrumentul scaneaza automat toate pluginurile din pluginul Un plugin este un software care contine un grup de functii care pot fi adaugate la un site web WordPress. Acestea pot extinde functionalitatea sau adauga noi functii site-urilor dvs. WordPress. Pluginurile WordPress sunt scrise in limbajul de programare PHP si se integreaza perfect cu WordPress. Acestea pot fi gratuite in directorul de pluginuri WordPress.org https://wordpress.org/plugins/ sau pot fi pluginuri bazate pe costuri dintr-un depozit tert pentru utilizarea standardelor de codare WordPress O colectie de reguli PHP_CodeSniffer (sniffs) pentru a valida codul dezvoltat pentru WordPress. Asigura calitatea codului si respectarea conventiilor de codare, in special standardele oficiale pentru WordPress Core. si, mai important pentru echipa PHP, compatibilitatea acestora cu diferite versiuni PHP de la 5.2 la 7.x. Proiectul va fi o parte oficiala a depozitului si toate acestea vor fi tratate printr-un API extern. O API sau o aplicatie de programare interfata este un intermediar software care permite programelor sa interactioneze intre ele si sa partajeze date in limita, clar definita moduri .. Rezultatele scanarilor vor fi afisate pe pagina respectiva a pluginului, iar verificatorul de compatibilitate PHP ar putea utiliza si datele respective. API-ul va putea chiar scana pluginuri si teme care nu fac parte din depozit, incarcandu-le temporar. Acest lucru va permite testarea chiar si a pluginurilor si temelor dezvoltate personalizate sau personalizate.
• @nerrad a comentat ca acest lucru va necesita probabil unele modificari in copia de pe pagina Servehappy care exista pana acum. Aceste schimbari vor fi probabil minore si, cel mai important, elimina unele puncte de incertitudine care, cu instrumentul la indemana, nu vor mai conta.
• Ar avea sens ca PHP Compatibility Checker sa foloseasca acel API, deci trebuie discutat cu persoanele responsabile de la WP Engine care sunt pasii care trebuie luati aici. Noul API ar putea fi folosit in plus pentru rezultate mai precise, dar poate fi chiar mai bine sa inlocuiti mecanismul actual cu acesta in totalitate, deoarece ar imbunatati semnificativ viteza, deoarece ar putea utiliza, in multe cazuri, date care au fost deja colectate inainte mai degraba decat rularea verificarilor scumpe pe server.
• Cele doua subiecte de mai sus ar trebui discutate in detaliu odata ce API-ul a fost lansat oficial publicului.
• @psykro a intrebat daca ar fi posibil sa se schimbe ora intalnirii sau sa gazduiasca o a doua intalnire. Toti cei care au raspuns au fost deschisi la o modificare, cu toate acestea ar trebui sa ramana de preferinta aproape de momentul in care este programata in prezent (in fiecare luni, la ora 19:00 UTC). Daca sunteti interesat, va rugam sa va lasati votul (voturile) pe aceasta postare Slack.
• @ mte90 a intrebat despre noile anteturi ale pluginului pentru o versiune minima necesara PHP si mai ales despre momentul in care integrarea cu Core Core este setul de software necesar pentru a rula WordPress. Echipa de dezvoltare de baza construieste WordPress. caci ar trebui dezvoltat. Desi nucleul nu ar trebui sa includa notificari sau avertismente legate de PHP pana la publicarea paginii Servehappy, este logic sa incepeti lucrul la aceasta inainte. Acesta nu va fi un subiect major pentru intalnirile PHP deocamdata, dar ar trebui sa se intample in principal in proiectul Trac An open source realizat de Edgewall Software care serveste ca instrument de urmarire a erorilor si instrument de gestionare a proiectelor pentru WordPress. ticket Creat atat pentru rapoarte de erori, cat si pentru dezvoltarea caracteristicilor de pe urmaritorul de erori. # 40934, cu exceptia cazului in care apare un subiect destul de complex care ar beneficia de o discutie intr-o intalnire. @psykro, @schlessera si @ mte90 si-au exprimat interesul de a lucra la acest lucru. Mockup-urile pentru partea vizuala a lucrurilor ar trebui create mai devreme, iar echipei #design ar trebui sa li se ceara ajutor in acest sens. Deoarece proiectul va implica probabil un pic de cod si nu este optim sa gestionati acest lucru numai prin Trac, s-a sugerat sa mergeti fie cu o abordare plugin-first, fie sa folositi un GitHub GitHub este un site web care ofera implementarea online a depozitelor git care pot poate fi usor partajat, copiat si modificat de alti dezvoltatori. Depozitele publice sunt gazduite gratuit, depozitele private necesita un abonament platit. GitHub a introdus conceptul de „cerere de extragere” in care modificarile de cod efectuate in sucursale de catre colaboratori pot fi revizuite si discutate inainte de a fi fuzionate de catre proprietarul depozitului. https://github.com/ furculita depozitului de dezvoltare WordPress.
• Dupa aceea, participantii au inceput sa revizuiasca sectiunile din documentul Google si au adaugat cateva comentarii si sugestii. @nerrad a subliniat ca ultima sectiune despre contactarea unui dezvoltator ar trebui sa se adreseze numai acelor proprietari de site-uri care au deja o relatie continua cu unul sau cel putin o cunosc deja. Este putin probabil ca persoanele care nu au angajat un dezvoltator sa faca acest lucru pentru un upgrade PHP „aleatoriu”. O analiza mai aprofundata si o discutie asupra documentului Google a fost amanata pentru sedinta de saptamana viitoare.

Intalnirea de saptamana viitoare

Urmatoarea intalnire va avea loc pe 13 noiembrie 2017, ora 19:00 UTC ca intotdeauna in # core-php, iar agenda sa va fi sa revizuiasca efectiv copia initiala sugerata pentru sectiunea „Inainte de actualizarea PHP”, astfel incat sa poata fi transmisa apoi la echipa de marketing. Daca aveti sugestii despre acest lucru, dar nu puteti face intalnirea, va rugam sa lasati un comentariu la aceasta postare, astfel incat sa le putem lua in considerare. Ne vedem saptamana viitoare!

# core-php, #php, #summary