PHP 8.2: Ce înseamnă pentru WordPress, pluginuri și dezvoltatori?

Publicat: 2022-12-14

PHP 8.2.0 și-a făcut debutul pe 8 decembrie 2022. Ca o actualizare majoră, aduce îmbunătățiri de performanță, o sintaxă mai simplă și o siguranță mai mare a tipului cu null , false și true ca tipuri independente. Una dintre cele mai mari schimbări care ar putea să provoace dezvoltatorii WordPress este introducerea de clase numai în citire , care nu permit proprietăți dinamice.

Proprietățile dinamice sunt depreciate și vor produce o eroare fatală în PHP 9 sau, eventual, PHP 10. Deși este potențial dureros - în special pentru nucleul WordPress - deprecierea este o caracteristică cheie și un cadou pentru dezvoltatorii PHP.

Să aruncăm o privire la evoluția recentă a PHP și, de asemenea, la modul în care dezvoltatorii WordPress mențin compatibilitatea cu versiunea anterioară în timp ce profită de noile funcții atunci când vor beneficia cel mai mult utilizatorilor finali.

Țineți pasul cu dezvoltarea PHP în WordPress

Deoarece nucleul WordPress menține o compatibilitate semnificativă cu retroactiv fără date planificate de sfârșit de viață când versiunile vechi nu vor fi acceptate, revine companiilor WordPress să-și determine propriul ciclu de viață al produsului sau serviciului și versiunile de PHP pe care le vor suporta.

Spre deosebire de WooCommerce, care necesită un minim de PHP 7.4, WordPress core în prezent recomandă doar PHP 7.4 sau mai mare. „Funcționează și cu” PHP 5.6.20, care și-a atins data de sfârșit de viață la sfârșitul anului 2018. Proiectul WordPress notează acest lucru și avertizează că utilizarea versiunilor PHP neacceptate „poate expune site-ul tău la vulnerabilități de securitate”. (Cerințe pentru WordPress.org)

Din fericire, doar 5,1% din toate site-urile WordPress folosesc în prezent PHP 5.6 și doar 2% folosesc o versiune și mai veche. 20% folosesc PHP 7.0 până la 7.3, iar cel mai mare grup (56.7%) utilizează PHP 7.4. (Statistici WordPress.org)

Din păcate, PHP 7.4 tocmai și-a atins data EOL la sfârșitul lunii noiembrie 2022. PHP 8.0 mai are mai puțin de un an pentru suportul său oficial de securitate până în cea mai mare parte a anului 2023. Versiunea actuală și susținută activ, PHP 8.1, se va învechi la sfârșit. din 2024. PHP 8.2, care tocmai a avut prima lansare stabilă, va avea suport de securitate până în decembrie 2025.

Acesta este un ciclu de lansare rapidă și nu este de mirare că ecosistemul WordPress se luptă să țină pasul cu el. Cu peste jumătate din web care rulează pe WordPress, este o navă mare care nu se poate întoarce rapid. Este mult mai mult un act de echilibru decât o cursă către marginea sângerării. Trecerea la PHP 8 are, totuși, multe beneficii, cu funcții mari de îmbunătățire a performanței, cum ar fi compilarea PHP Just-in-Time (JIT) la timpul de execuție pentru o execuție mai rapidă cu o utilizare mai mică a memoriei.

Compartimentul dintre compatibilitatea cu retroactiv și stabilitate, gândire anticipată și inovație

Compartimentul dintre satisfacerea celui mai larg public posibil de utilizatori și menținerea monedei cu PHP a reprezentat întotdeauna o dilemă pentru dezvoltatorii, gazdele și companiile de produse WordPress. Agențiile și freelancerii cu clienți pe termen lung și site-uri vechi se confruntă cu aceeași problemă: actualizarea cerințelor minime poate obliga clienții existenți să facă modificări semnificative site-urilor lor sau să-i vadă rupe.

Pe de o parte, beneficiile de a rămâne la curent cu PHP sunt securitatea și performanța îmbunătățite și cele mai recente concepte și capabilități de programare pentru dezvoltatori. Pe de altă parte, principalul beneficiu al întârzierii PHP-ului minim necesar este o bază de clienți fericită (deși mulțumită) și largă. Este o situație „plătește-mă acum sau plătește-mă mai târziu”. La un moment dat, trebuie să smulgi bandaid.

Datele bune și telemetria despre mediile utilizatorilor pot ajuta la determinarea timpului cel mai puțin perturbator pentru a ridica o cerință minimă de versiune PHP. Majoritatea dezvoltatorilor de pluginuri urmăresc aceste numere cu propriile lor instrumente, deoarece nu face parte din datele de instalare active ale depozitului de pluginuri WordPress.org. În mod inevitabil, orice modificare potențial de neregulă care afectează mulți oameni este garantat ca va duce la o rafală de bilete de asistență.

Prioritizarea compatibilității inverse implică și lucrări de întreținere ridicate. Sprijinirea unei baze de utilizatori foarte mari și diverse este grozavă pentru utilizatorul final, dar înseamnă că dezvoltatorii trebuie să își păstreze codul să lucreze în multe medii diferite. „Îmi place să susțin versiunile PHP mai vechi pe măsură ce se adaugă funcții noi”, a spus niciun dezvoltator, niciodată!

Nu este vorba doar de PHP moștenit de care trebuie să-și facă griji – ci și de bazele de date vechi și zeci de alte variante ale stivei WordPress. Cazurile marginale apar și îi încurcă chiar și pe experți atunci când există un spectru larg de medii de server WordPress cu elemente învechite.

Cel mai bun moment pentru a vă crește cerințele minime PHP

Versiunea iThemes Security Pro 7.2 este un bun exemplu de creștere a cerinței PHP minime pentru un produs WordPress pentru a oferi atât inovație, cât și stabilitate clienților existenți.

Începând cu versiunea 7.2, iThemes Security Pro a necesitat PHP 7.3 sau o versiune ulterioară și acceptă până la 8.1. Decizia de a actualiza cerința PHP pentru iThemes Security Pro a fost luată pentru a implementa cadrul WebAuthn. Implementarea a necesitat biblioteci care au nevoie de PHP 7.3+ pentru a gestiona criptarea și cheile publice. Caracteristicile 2FA, cheia de acces și de conectare biometrică introduse în iThemes Security Pro 7.2 sunt un rezultat direct al acestei decizii. Într-un moment în care parolele sale clare sunt sparte, echipa de securitate iThemes a adus pentru prima dată autentificarea fără parolă la WordPress ca experiență principală de autentificare a utilizatorului.

Ar fi fost posibil să se construiască aceste caracteristici prin rescrierea bibliotecilor WebAuthn pentru compatibilitate cu versiunile mai vechi de PHP. Desigur, ar fi mult mai multă muncă și ar crea cod suplimentar de menținut. Cursul mai înțelept a fost să țineți pasul cu comunitatea PHP într-un ritm moderat, adoptând dependențe care necesită PHP 7.3 sau mai mare. Majoritatea utilizatorilor lor erau deja acolo. De aceea, echipa de dezvoltare iThemes Security a decis să ridice cerințele minime PHP pentru utilizatorii noi și existenți.

Pentru produsele WordPress care sunt investite masiv în editorul de blocuri Gutenberg, cum ar fi GiveWP, gestionarea schimbării poate fi și mai dificilă. Stabilitatea și rata lentă de schimbare a nucleului WordPress poate fi frustrantă pentru dezvoltatorii PHP back-end, dar le permite dezvoltatorilor JavaScript/React front-end să conducă platforma înainte.

Jason Adams, managerul de dezvoltare al GiveWP, observă că nu trebuie să fie compatibile cu versiunea inversă, deoarece pot migra utilizatorii între versiuni pe măsură ce editorul de site evoluează. Cu toate acestea, „Nu există o migrare pentru PHP”, a comentat el. În cele din urmă, ei vor trebui să se adapteze la arhitectura PHP 9 și să se îndepărteze de caracteristicile recent depreciate din PHP 8.2.

Nu există un „moment potrivit” pentru fiecare produs din ecosistemul WordPress pentru a actualiza cerințele minime PHP. „Nu este o problemă pe care o poți rezolva filozofic”, mi-a spus Adams. Depinde într-adevăr de un apel de judecată bazat pe câți utilizatori vor fi afectați negativ de schimbare. Dacă 90% sau mai mult sunt pe PHP 7.2 sau 7.4, creșterea cerinței minime la acel nivel este viabilă.

Aceste numere pot varia mult în funcție de baza specifică de utilizatori a unui produs, spune Adams. Un produs folosit de clienții mai adepți din punct de vedere tehnic va tinde să fie mai aproape de versiunile PHP suportate în prezent. Un produs precum GiveWP, cu multe organizații non-profit care îl folosesc, va trebui să pună mai multă pondere pe compatibilitatea anterioară. O altă cale de urmat este de a lăsa codul moștenit și utilizatorii săi să se ramifice într-o versiune pe termen lung care va fi acceptată, dar care nu va vedea noi funcții adăugate. Când utilizatorii sunt pregătiți să facă upgrade, aceștia ar putea migra la o nouă versiune majoră construită pentru compatibilitatea viitoare cu PHP.

Notificările de depreciere stimulează dezvoltarea

WordPress.com tocmai a lansat PHP 8.2 ca o opțiune pentru planurile sale de afaceri și comerț electronic cu funcțiile de găzduire activate, iar în ecosistemul WordPress.org, codul mai vechi destul de bine conceput este puțin probabil să se rupă sau să devină nesigur cu următoarea versiune majoră a PHP. eliberare. Chiar dacă baza de cod de bază WordPress.org oferă oficial doar suport „beta” pentru PHP 8.0, în general funcționează bine cu cele mai recente versiuni de PHP, la fel și cu pluginurile bine acceptate. Nu vor arunca erori fatale sau de analiză. Nici măcar nu ar trebui să vedeți multe avertismente cu depanarea activată. Este posibil să vedeți o mulțime de notificări de funcții învechite, care nu sunt erori — încă.

Frustrările unui ciclu rapid de lansare PHP au foarte mult de-a face cu dezvoltatorii care se blochează în buruieni, refactorizarea codului lor și jocul de recuperare cu aspectele depreciate ale PHP. Această muncă critică le poate lăsa mai puțin timp să exploreze și să inoveze cu noi concepte și capabilități pe care le aduce cea mai recentă versiune PHP.

Există un alt mod de a privi această situație. Abordarea caracteristicilor depreciate ale PHP este de fapt orientată spre viitor și îi obligă pe dezvoltatori să devină fluent în următoarele iterații ale unui limbaj în evoluție. Fără acest exercițiu oarecum forțat, cunoștințele existente s-ar instala mai ușor în vechile obiceiuri care vor deveni proaste atunci când devin învechite.

Notificările de depreciere indică lucruri care funcționează acum, dar se vor rupe în versiunile viitoare de PHP. Acest lucru este bun pentru tine dacă ești dezvoltator, după cum explică Brent Roose. Dacă dezvoltatorii acordă atenție acestor notificări, ei vor avea suficient timp pentru a trece peste orice cod depreciat. Și nu ar trebui să blocheze actualizările minore ale versiunilor.

Timothy Jacobs, iThemes Security Lead Developer și WordPress Core Committer, spune că este bine să aveți avertismente de depreciere. Aceștia îi împing pe dezvoltatori să adopte cod „mai corect” și „mai puțin fragil”, care va fi din ce în ce mai sigur, mai performant, mai rezistent la greșeli și mai capabil să facă față cazurilor marginale. În această vedere, E_DEPRECATED notificări completarea jurnalului de erori este „ca un sistem de avertizare timpurie că lucrurile se vor rupe în viitor, dar nu sunt stricate acum”.

Fără proprietăți dinamice după PHP 8.2

Motivul lui Nikita Popov pentru eliminarea treptată a proprietăților dinamice în PHP 9 este un bun exemplu al impulsului evolutiv al PHP către cod și convenții de programare mai rezistente:

Motivația acestei schimbări este dublă: pentru a preveni greșelile (datorite greșelilor de scriere sau redenumiri) în cazul obișnuit și pentru a explicita utilizările intenționate. Problema principală este că citirea dintr-o proprietate inexistentă emite un diagnostic care face problema imediat aparentă, în timp ce scrierea pe o proprietate inexistentă este complet silențioasă. PHP nu oferă nicio indicație că programatorul a făcut o greșeală.

Videoclipul de două minute al lui Brent Roose despre evoluția de la PHP 5.6 la 8.2 este o ilustrare vizuală strălucitoare și simplă a cât de departe a ajuns PHP din 2014 până în prezent. Folosind exemplul unui obiect simplu de transfer de date, Roose arată cum codul PHP 5.6 se micșorează dramatic la un bloc de cod mult mai simplu, mai simplu și, în general, mai elegant în drumul către PHP 8.2.

După cum notează Roose în sfaturile sale pentru gestionarea proprietăților dinamice (care sunt depreciate în PHP 8.2), dezvoltatorii ar trebui să aibă o mulțime de piste pentru a-și actualiza codul existent înainte ca avertismentele de depreciere să se transforme în erori fatale. Cu toate acestea, pista respectivă se va diminua rapid, iar WordPress este un caz special. Tonya Mork are o propunere acceptată în Trac pentru gestionarea deprecierii proprietăților dinamice necunoscute în nucleul WordPress. Ea și Juliette Reinders Folmer sunt îngrijorați de faptul că dezvoltatorii WordPress nu vor avea suficient timp pentru a-și refactoriza codul, ca să nu mai vorbim de provocările speciale ale menținerii compatibilității înainte pentru un proiect vechi de douăzeci de ani. Mork, Reinders Folmer și Sergey Biryukov au fost eroii în mare parte necunoscuți ai acestei sarcini descurajante.

În discuția lor despre proprietățile dinamice și metodele magice din PHP 8.2, Mork și Reinders Folmer subliniază că rădăcinile WordPress în PHP 3 și 4 îl mențin într-un univers de programare solid procedural, în timp ce PHP continuă să avanseze ca limbaj orientat pe obiecte. Dezvoltatorii de bază trebuie să găsească o modalitate de a menține comportamentul codului moștenit în PHP-ul de astăzi fără a întrerupe compatibilitatea cu înapoi „și totuși să facă codul mai bun și mai sigur și să atenueze deprecierea proprietăților dinamice PHP 8.2”, așa cum spune Reinders Folmer. „De fapt, ne facem propriile vieți foarte dificile cu regula [de bază a WordPress] fără a încălca [compatibilitatea cu înapoi]”, notează ea în videoclip.

„Există un motiv bun pentru asta”, răspunde Mork – „este pentru utilizatori. Utilizatorii au încredere că pot apăsa butonul respectiv și pot face upgrade și că ne-am gândit la compatibilitatea cu versiunea anterioară, că i-am prioritizat. Este o piatră de temelie pentru noi… astfel încât utilizatorii să aibă încredere să facă upgrade.”

Toată dezvoltarea este întreținere...

Este o provocare unică să încerci să reportezi PHP „modern” pentru a lucra cu cele două versiuni majore anterioare ale PHP de dragul menținerii compatibilității cu versiunea inversă în nucleul WordPress. Dezvoltatorii de pluginuri au o sarcină mult mai ușoară de a-și actualiza codul în moduri care pot profita de noile funcții, cum ar fi clasele de numai citire ale PHP 8.2 și deprecierea proprietăților dinamice. O mare parte din această muncă este în mare măsură și o formă de întreținere.

Din punct de vedere arhitectural, modificările PHP 8+ se concentrează pe concepte de programare precum imuabilitatea. Structurile de date imuabile „nu rezolvă în mod inerent problemele de securitate”, dar ajută codul dezvoltatorilor să fie mai puțin predispus la erori și mai corect, conform lui Jacobs:

Nu aș spune că o structură de date imuabilă este în mod natural sigură, iar o structură de date mutabilă este nesigură. Mai degrabă, structurile de date imuabile pot ajuta la eliminarea greșelilor de programare care pot duce la probleme de securitate. Prin reducerea numărului de stări diferite în care poate exista codul nostru, putem reduce complexitatea codului nostru și, prin urmare, reducem șansele de a face greșeli.

Cel mai bun motiv pentru a menține codul la standardul versiunilor PHP acceptate activ este reducerea riscului de securitate. PHP 8.2 aduce avantaje utile și „balustrade de protecție” în viziunea lui Adams, dar puține lucruri care îi vor entuziasma pe programatori sau vor fi priviți ca schimbatori de joc. Ceva precum atributul #[\SensitiveParameter] ar putea fi mai semnificativ practic, deoarece permite ca datele sensibile să fie filtrate din urmele stivei care ajung adesea la servicii terțe. Introduse în PHP 8, atributele sunt alegerea lui Adams pentru ultima inovație care i-a atras atenția pentru a activa ceva ce nu puteai face anterior: „descrie ceva [cum ar fi clase, variabile, metode etc.] dintr-o meta-perspectivă”.

Profitând de noile funcții din PHP 8.0 până la 8.2 și versiunile viitoare, este locul în care creativitatea dezvoltatorilor poate străluci, dar pur și simplu susținerea acelor versiuni, astfel încât pluginurile și nucleul WordPress să nu le distrugă, este atât practică, cât și vitală.

… Și toată întreținerea este art

Jeff Atwood are o postare de blog veche, dar remarcabilă, intitulată „The Noble Art of Maintenance Programming”, pe care am citit-o recent, datorită buletinului informativ al lui Kale Davis Hacker. „Programarea de întreținere este văzută pe scară largă ca o muncă de îngrijire”, scrie Atwood. Acest lucru mi-a adus aminte de artista Mirele Laderman Ukeles, al cărei „Manifest de artă de întreținere” mi-a părut întotdeauna foarte relevant pentru programare și dezvoltare web:

Două sisteme de bază: Dezvoltare și Întreținere. Mingea oricărei revoluții: după revoluție, cine va ridica gunoiul luni dimineața? […] Sistemele de dezvoltare sunt sisteme de feedback parțial cu spațiu major de schimbare. Sistemele de întreținere sunt sisteme de feedback direct cu puțin spațiu pentru modificare.

Laderman Ukeles a fost o tânără artistă și proaspătă mamă în 1969, când a scris manifestul și a declarat că întreținerea este artă. Ea a fost frustrată de modul în care operele de artă de ultimă oră și munca de rang înalt sunt împărțite de munca care le face posibile: educația parentală, predarea abilităților și tradițiilor artistice sau pur și simplu organizarea unui spectacol de artă. Ea a făcut o expoziție memorabilă bazată pe ea însăși, acționând ca îngrijitor de muzeu. Apoi și-a petrecut cea mai mare parte a carierei sale (în curs de desfășurare) ca artist în rezidență al Departamentului de Sanitare al orașului New York. Primul ei proiect în acest rol a fost să mulțumească personal tuturor celor 8.500 de lucrători din salubritate „pentru că a menținut New York-ul în viață”.

Atwood are o abordare similară a programării. El citează mai multe figuri importante din inginerie software care spun că denigrarea lucrărilor de întreținere este greșită. Robert L. Glass a considerat că „Întreținerea este o provocare intelectuală semnificativă, precum și o soluție și nu o problemă”, așa că ar trebui să fie privită ca o sarcină importantă pentru cei mai pricepuți. Joel Spolsky a scris cu mult timp în urmă că dezvoltatorii sunt leneși, iar motivul pentru care „întotdeauna vor să arunce codul și să o ia de la capăt” este că „este mai greu să citești codul decât să-l scrii”.

Într-o conversație cu Andy Hunt, Dave Thomas a argumentat: „Toată programarea este programare de întreținere pentru că rar scrii cod original. …. Îți petreci cea mai mare parte a timpului în modul de întreținere. Așa că ai putea la fel de bine să muști glonțul și să spui: „Mă mențin din prima zi”. Disciplinele care se aplică întreținerii ar trebui să se aplice la nivel global.” Hunt a fost de acord: „Sunt doar primele 10 minute în care codul este original când îl tastezi prima dată. Asta e."

Atwood se înclină în cele din urmă către acest punct de vedere, dar face ecou perspectiva comună a dezvoltatorului WordPress pe care am auzit-o de la Jason Adams și Timothy Jacobs. Arta specială a dezvoltării/întreținerii WordPress?

„Este un act de echilibru.”

Cel mai bun plugin de securitate WordPress pentru a securiza și proteja WordPress acum 35% reducere!

WordPress alimentează în prezent peste 40% din toate site-urile web, așa că a devenit o țintă ușoară pentru hackerii cu intenții rău intenționate. Pluginul iThemes Security Pro elimină presupunerile din securitatea WordPress pentru a facilita securizarea și protejarea site-ului dvs. WordPress. Este ca și cum ai avea în personal un expert în securitate cu normă întreagă care monitorizează și protejează constant site-ul tău WordPress pentru tine.

Economisiți 35% acum!