Trecerea la PHP 8.x în patru pași – Un interviu cu Juliette Reinders Folmer

Actualizarea unui site, plugin sau temă WordPress la o nouă versiune de PHP este o sarcină care se repetă în mod regulat. Dar cum faci asta cât mai eficient posibil? De unde știi că nu vei trece cu vederea nimic? Există o foaie de parcurs pentru asta?

În acest articol, vom aborda aceste întrebări (și multe altele) și vom analiza ce este implicat într-o tranziție lină la PHP 8.x pentru site-ul, pluginul sau tema dvs. WordPress, inclusiv o foaie de parcurs.

Vom face acest lucru pe baza unui interviu pe care l-am realizat cu experta PHP Juliette Reinders Folmer. Ea își dedică cea mai mare parte a vieții de zi cu zi programării și tot ceea ce o înconjoară, concentrându-se în principal pe proiecte open-source, inclusiv WordPress.

Ești gata să faci și tu schimbarea fără probleme? Ești curios despre planul nostru pas cu pas? Atunci haideți să ne scufundăm direct!

PHP 8.x — Ce s-a schimbat

Pentru o prezentare generală a modificărilor, vă recomandăm articolele de mai jos:

• Note de lansare pentru PHP 8.0 și PHP 8.1
• Ghid de migrare pentru PHP 8.0 și PHP 8.1
• WordPress și PHP 8.0 și starea actuală
• Ce este nou în PHP 8.0 și PHP 8.1

După ce ați citit aceste articole, veți fi complet actualizat cu privire la ceea ce s-a schimbat în PHP 8.x și ce trebuie să faceți pentru ca proiectele dvs. PHP să ruleze fără probleme.

Dacă nu ești sigur care este cel mai bun mod de a începe, nicio problemă. În conversația cu Juliette, am discutat acest lucru în detaliu și vă vom explica în acest articol cât mai detaliat posibil cum puteți trece la PHP 8.x.

De asemenea, vom explica în casete informative cum să efectuați diferite operațiuni în MyKinsta, panoul nostru de control proprietar pentru toate site-urile, aplicațiile și bazele de date WordPress.

Trecerea la PHP 8.x: Cum să începeți

Trecerea la PHP 8.x sună simplă și, din punct de vedere tehnic, așa este. Multe gazde vă permit să specificați ce versiune de PHP doriți să utilizați pentru site-ul dvs. în panoul de administrare. La Kinsta, schimbarea versiunii PHP se poate face cu un singur clic în tabloul de bord MyKinsta.

Dar înainte de a face asta, există câteva lucruri de care trebuie să fii sigur. În funcție de nivelul de cunoștințe și experiență, vă recomandăm următoarele:

• Dacă ți-ai construit propriul site WordPress cu teme și pluginuri standard, fără a avea prea multe cunoștințe despre PHP, angajează un dezvoltator sau o agenție pentru a investiga dacă site-ul tău este potrivit pentru a rula pe PHP 8.x. Căutați o terță parte care vă poate ajuta în acest sens? Apoi, uitați-vă la pagina noastră de parteneri care listează câteva companii de încredere care vă pot ajuta.
• Dacă site-ul dvs. WordPress a fost creat de o parte externă, un dezvoltator sau o agenție, contactați-i pentru a-i întreba dacă site-ul dvs. poate rula pe PHP 8.x.
• Dacă ți-ai creat site-ul WordPress - cu propria temă personalizată, de exemplu, sau cu pluginuri dezvoltate de sine stătătoare - avem o foaie de parcurs pentru tine mai jos.

Dacă site-ul dvs. se încadrează într-una dintre primele două categorii, vă invităm cu siguranță să citiți restul articolului, dar nu vă recomandăm să începeți singuri să testați site-ul dvs. pentru compatibilitatea cu PHP 8. Lasă-le profesioniștilor.

Indiferent ce alegeți, vă sfătuim să nu treceți doar site-ul live la PHP 8 și să „vedeți dacă funcționează”. Ești curios despre cum va arăta site-ul tău și abia așteptați să îl vedeți rulând pe PHP 8? Apoi începeți testarea într-un mediu de pregătire. O gazdă bună vă va permite să configurați cu ușurință un mediu de organizare.

În mediul de pregătire, puteți activa PHP 8.x și puteți vedea dacă această actualizare funcționează bine cu site-ul dvs. De asemenea, este posibil să lucrați cu o copie locală a site-ului dvs. Cu instrumentul nostru gratuit de dezvoltare DevKinsta, vă puteți importa cu ușurință site-ul din tabloul de bord MyKinsta, după care puteți schimba versiunea PHP la 8.0 sau 8.1.

Dacă nu vedeți nicio problemă în mediul de punere în scenă, nu înseamnă neapărat că de fapt nu există probleme. Foaia de parcurs de mai jos vă va spune de ce.

Testare de compatibilitate PHP 8.x: foaia de parcurs

Testare: cuvântul cheie pentru un software bun. Chiar și pentru site-urile web WordPress și componentele acestora, cum ar fi teme, pluginuri și nucleul WordPress, testarea este mijlocul de a vă asigura că nu se întâmplă lucruri pe care nu doriți să le întâmpinați.

Un proiect de dezvoltare software constă în mare parte din testare. În acest articol, ne uităm în mod special la testele care vă pot ajuta să faceți ca tranziția la PHP 8.x să meargă fără probleme. În articolul nostru despre Instrumentele DevOps, veți găsi o secțiune cu o colecție de instrumente pe care le puteți utiliza.

Următoarele tipuri de teste sunt discutate în această postare de blog:

Să ne uităm mai atent la diferitele tipuri de teste pe care le putem efectua.

Analiză statică (sau testare statică)

Primul pas pe care îl puteți face ca dezvoltator PHP este să efectuați o analiză statică a codului dvs. cu diverse instrumente. Analiza statică este procesul de analiză a software-ului fără a executa codul. Cu analiza statică, este posibilă detectarea erorilor, detectarea problemelor cu compatibilitatea PHP 8.x, aplicarea standardelor de codare (de exemplu, Standardele de codificare WordPress) și chiar modificarea și curățarea codului este posibilă.

Instrumente pentru analiză statică

Puteți efectua o analiză statică cu diverse instrumente, cum ar fi:

• Compatibilitate PHP
• Psalm
• PHPStan

La momentul scrierii, nu toate verificările PHP 8.1 sunt acceptate în cea mai recentă versiune PHPCompatibility. Verificările PHP 8.1 pot fi în versiunea de dezvoltare, așa că asigurați-vă că le utilizați (deocamdată) când utilizați PHPCompatibility pentru a vă analiza proiectul și a vedea ce erori/recomandări există.

Verificările PHP 8.1 vor fi lansate în curând într-o nouă versiune majoră . Dacă doriți să fiți la curent cu acest lucru și aveți un cont GitHub, deschideți depozitul GitHub de PHPCompatibility și navigați la Watch -> Custom -> Releases , unde puteți alege să fiți notificat când este lansată o nouă versiune.

PHPCompatibility, care testează doar compatibilitatea pentru o anumită versiune (sau o serie de versiuni) de PHP, este ușor de configurat. Obțineți cele mai bune rezultate dacă rulați o versiune test - de exemplu, 8.0+ (8.0 și o versiune ulterioară) - în cadrul PHPCompatibility.

Ar trebui să fiți atenți la funcții învechite sau șterse, valorile implicite modificate ale parametrilor funcției, dacă să utilizați concat fără paranteză, dacă să utilizați potrivirea ca nume de funcție (din moment ce a fost rezervată începând cu PHP 8.0), etc.

Psalm și PHPStan sunt completări bune și vă pot ajuta prin efectuarea de verificări suplimentare legate de tipurile de variabile. Dezavantajul acestor instrumente este că este nevoie de multă configurare pentru a obține rapoarte pentru PHP 8.0 și 8.1. Chiar dacă au succes, te poți aștepta la multe fals pozitive. Falsele pozitive sunt notificări care sunt date greșit, cauzate de limitările analizei statice.

Sunt necesare cunoștințe solide pentru a interpreta corect rezultatele acestor două instrumente, dar aceste cunoștințe vă pot ajuta să identificați incompatibilități suplimentare pe care PHPCompatibility nu le poate găsi. Consultați documentația pentru Psalm și PHPStan dacă doriți să aflați mai multe despre ele.

Rezumat:

• Efectuați analize statice cu PHPCompatibility, Psalm, PHPStan
• Rezolvați toate problemele legitime

Testarea unitară

Următorul pas al procesului este testarea unitară. Testarea unitară este o metodă de testare individuală a bucăților de cod. În cadrul testării unitare, vor fi dezvoltate teste specifice țintite pentru fiecare unitate. Aceasta va implica trecerea prin diferite scenarii. De preferință, fiecare scenariu este testat separat de celelalte, astfel încât testele să fie independente unele de altele.

Desigur, nu este suficient să ai teste unitare. De asemenea, trebuie să fie conduși. Testele unitare sunt cel mai bine automatizate folosind instrumente CI (integrare continuă), cum ar fi Jenkins, GitHub Actions sau Travis.

Suportă versiuni multiple de PHP

În calitate de constructor de pluginuri, dacă doriți să acceptați mai multe versiuni PHP, asigurați-vă că testele în CI sunt executate pe toate versiunile PHP pe care le acceptați.

Desigur, puteți suporta și numai versiuni mai noi, alegerea ține în totalitate de dvs.

Testarea cu mai multe versiuni de PHP necesită să utilizați mai multe versiuni PHPUnit, în funcție de versiunea PHP. Deoarece PHPUnit a introdus mai multe modificări de-a lungul anilor care afectează modul în care sunt scrise testele, această parte poate fi dificilă.

Pentru a ocoli acest lucru, puteți folosi PHPUnit Polyfills (scris de Juliette și sponsorizat de Yoast). Acest lucru vă permite să scrieți teste care sunt neacceptate oficial pentru PHPUnit 9 (și astfel pot rula pe PHP 8.x). Polyfill-urile vă fac apoi testele să funcționeze în PHPUnit 4.x până la 9.x și cu PHP 5.4 până la PHP 8.1 (de acum).[/notice]

Acum că aveți testele care rulează, următorul pas este să vă asigurați că problemele găsite în teste sunt rezolvate.

Acoperire cod

Rularea acestor teste este cea mai fiabilă modalitate de a găsi incompatibilități între versiuni.

În acest sens, acordați atenție acoperirii codului testelor dvs.:

• Să presupunem că aveți o funcție A și ați scris un test pentru aceasta, iar funcția A apelați funcțiile B, C și D ca parte a logicii funcției.
• Testul pentru funcția A este scris pentru a testa logica funcției A, dar va apela și funcțiile B, C și D în timpul testării. Pentru funcțiile B, C și D, de obicei testați doar „calea fericită” - situația în care totul merge bine - și, prin urmare, acele funcții nu sunt încă testate complet, deși (o parte din) codul din acele funcții este executat în timpul testării funcției A.
• Pentru fiecare dintre testele dvs., indicați codul care este testat în mod specific. Faceți acest lucru dând fiecărui test un @covers În acest fel, B, C și D nu sunt „contorizate” în calculul acoperirii codului, ceea ce vă permite să vedeți ce parte a codului dvs. este acoperită de teste.

Deseori, dezvoltatorii scriu și testează – uneori chiar fără să știe – pentru „calea fericită”. În aceste cazuri, este de asemenea necesară testarea a ceea ce se întâmplă atunci când date neașteptate sunt transmise unei funcții. Testarea numai cu valori/tipuri așteptate nu este suficientă .

„În testare trebuie să vă asigurați că o funcție face ceea ce ar trebui să facă, dar și că o funcție nu face ceea ce nu ar trebui.” - Juliette Reinders Folmer Click to Tweet

A doua parte a citatului de mai sus este adesea uitată, când este poate chiar mai importantă decât prima parte. Ce se întâmplă dacă treci de un tip incorect? Primiți un mesaj de eroare? Sau este turnarea variabilă cu funcția continuând normal? Ce se întâmplă dacă o valoare neașteptată este transmisă funcției?

Asigurați-vă că testați funcțiile cu variabile, tipuri și valori neașteptate. Numai atunci te poți baza pe testele tale pentru a găsi problemele pe care le poate cauza o nouă versiune PHP.

PHP devine mai strict

PHP devine din ce în ce mai precis (strict) în modul în care gestionează „tipurile” propriilor funcții PHP, precum și lucruri precum proprietăți dinamice. Aceste modificări sunt, în general, menite să ajute dezvoltatorii să furnizeze cod fără erori (ei bine, cod cu mai puține erori). Dar acest lucru poate prezenta un obstacol de actualizare pentru codul preexistent scris pe baza principiilor „vechi” ale PHP.

Datorită acestui impuls pentru mesaje de eroare mai utile în PHP, puteți vedea că adaptarea codului existent cu noile versiuni PHP necesită din ce în ce mai mult timp. Realizarea unui cod care a funcționat pe PHP 5.6 potrivit pentru PHP 7.0 a durat doar o fracțiune din timp în majoritatea cazurilor, în comparație cu actualizarea codului pentru a-l face potrivit pentru PHP 8.1. Și asta în ciuda faptului că PHP 7.0 a fost o versiune „majoră”, în timp ce PHP 8.1 este o versiune „minoră”.

În multe cazuri, testarea este încă singura modalitate fiabilă de a determina ce trebuie modificat pentru a accepta o nouă versiune.

Testarea unitară este posibilă cu diverse instrumente, inclusiv:

• PHPUnit
• Bătaie de joc
• Behat,
• Storyplayer

Multe dintre aceste instrumente sunt construite pe baza sau împreună cu PHPUnit.

În cele din urmă, nu contează ce instrumente folosiți. Cel mai important lucru este să testați și să faceți testele să ruleze pe noile versiuni PHP. Acest pas poate fi uneori foarte complicat, dar din fericire, așa cum am menționat mai devreme, există instrumente pentru aceasta, cum ar fi PHPUnit Polyfills.

Testare de integrare

Testarea de integrare este următorul pas pe care îl vom efectua, după analiza statică și testarea unitară. Un test de integrare este în cazul în care situațiile din viața reală sunt testate într-un context mai larg decât doar o „unitate de cod”. Acestea includ testarea cu o bază de date activă (de testare) sau testarea cu un API extern, pentru a da doar două exemple.

Deci, atunci când testezi codul unui plugin sau al unei teme în contextul WordPress și folosești o versiune reală, acestea sunt, prin definiție, teste de integrare.

WP Test Utils (scris din nou de Juliette și sponsorizat de Yoast) este un instrument excelent pentru testarea integrării. WP Test Utils oferă instrumente pentru a scrie teste de integrare și unitate, în care WordPress este „machiat” folosind Brainmonkey și Mockery, unde funcțiile WordPress utilizate în mod obișnuit sunt „falsificate”, astfel încât să vă testați propriul cod și nu codul WordPress.

Testarea integrării cu WordPress este o poveste mai complicată, deoarece implică integrarea cu WordPress și suita de teste a WordPress. În funcție de ce versiuni de WordPress acceptă un plugin sau o temă, trebuie să luați în considerare ce versiuni PHPUnit sunt acceptate de WordPress însuși pentru a rula testele pe diferite versiuni PHP.

De exemplu, WordPress 5.6 până la 5.8 folosește PHPUnit 5 până la 7 pentru testarea PHP 5.6 până la PHP 8.0, dar începând cu WordPress 5.9, WordPress însuși folosește și PHPUnit Polyfills pentru un suport mai larg. WP Test Utils acționează ca o punte pentru a depăși toate aceste diferențe.

Doriți să aflați mai multe despre cum să rulați teste de integrare împotriva mai multor versiuni diferite de WordPress, inclusiv WordPress 5.9 și versiuni ulterioare? Apoi, citiți despre asta pe site-ul WordPress.

Testare manuală

Acum că ați trecut prin testarea unitară și testarea integrării și ați remediat toate problemele găsite, este timpul să faceți testarea manuală. Site-ul dvs. rulează și propriul cod funcționează, dar utilizați și pluginurile A, B și C. Știți dacă aceste plugin-uri sunt compatibile?

De exemplu, verificați acest lucru cu autorii pluginului și vedeți dacă aceștia indică faptul că este compatibil PHP 8.x. Întrebarea atunci, desigur, este cum a fost testat pluginul. Adesea răspunsul aici este: izolat. Funcțiile pluginului au fost de obicei testate numai împreună cu WordPress, fără alte plugin-uri active. Și chiar dacă în cadrul acestor teste au fost folosite și alte plugin-uri, sunt șanse ca nu toate pluginurile folosite de dvs. să fi făcut parte din testare, așa că luați o astfel de declarație de compatibilitate cu puțină sare.

De exemplu, un site WordPress cu 3 plugin-uri (A, B și C). Este posibil ca pluginul B, de exemplu, să returneze un tip de variabilă incorect printr-un filtru, cu care pluginul C, folosind același filtru, dorește să lucreze. Acest lucru poate provoca apoi o eroare fatală, deoarece tipul nu mai este cel așteptat. Pluginul C este apoi văzut ca vinovat pentru mesajul de eroare, chiar dacă pluginul B este adevăratul infractor.

Interoperabilitatea-incompatibilitățile pluginurilor sunt imposibil de descoperit atunci când se testează izolat. Cu cât sunt mai multe pluginuri active, cu atât este mai probabil ca ceva să meargă prost. De exemplu, ar fi foarte util să treceți solicitările de pagini de la un site web live într-un mediu de pregătire (cu înregistrarea erorilor activată) pentru a descoperi ce nu merge de fapt greșit.

Cu acest tip de problemă, proprietarul unui site va vedea de obicei doar un mesaj că a existat o eroare cu ultimul cod executat (în acest caz, de la pluginul C), chiar dacă pluginul C nu este neapărat cauza problemei.

În cele mai multe cazuri, este implicată multă muncă manuală, umană și este necesară o cantitate sănătoasă de unsoare pentru cot pentru a detecta și remedia aceste probleme. Acest lucru ar putea fi automatizat folosind teste end-to-end, dar nu vedem că acest lucru se întâmplă prea mult în WordPress.

Testați disponibilitatea pentru pluginurile utilizate

Pentru dezvoltatori și echipe de dezvoltare: Acceptați codul numai atunci când testele sunt disponibile. În acest fel, vă asigurați că sunt necesare mai puține teste manuale, ceea ce vă economisește mult timp.

Întrebați strategia de testare dacă doriți să cumpărați un plugin comercial sau o temă. În acest fel, creăm în mod colectiv conștientizarea dezvoltatorilor/echipelor de dezvoltare din comunitatea WordPress pentru a obține testarea mai sus pe ordinea de zi și toți beneficiem.

Testarea este adesea văzută – în mod nedrept – ca un cost când, în realitate, economisește bani. Investiția suplimentară necesară pentru a scrie teste se plătește sub forma semnificativ mai puține rapoarte de erori și mai puțin timp petrecut pentru remedierea erorilor. În plus, cu testarea automată a software-ului, extensiile și modificările pot fi făcute mai rapid, deoarece testele pot confirma rapid că funcționalitatea existentă continuă să funcționeze.

''Fii amabil cu viitorul tău, te rog ;-)'' - Juliette Reinders Folmer Click to Tweet

Rolul gazdelor WordPress și PHP 8.x

Pentru proprietarul obișnuit al site-ului, îndrumările din partea gazdei dvs. sunt foarte de dorit. Luați în considerare următoarele:

• Documentație și actualizări pentru clienți conform cărora WordPress Core, pluginurile și/sau temele nu sunt (în unele cazuri) compatibile cu versiunile încrucișate PHP
• Opțiuni pentru testare (cum ar fi lucrul cu un mediu de testare)
• Metode pentru raportarea erorilor și contactarea asistenței

Acest lucru este benefic și pentru o gazdă web, deoarece proprietarii site-ului contactează adesea gazda pentru ajutor atunci când apar probleme. În cazul trecerii la PHP 8.0 sau 8.1, proprietarul site-ului este responsabil pentru potențialele probleme și cu cât proprietarul are mai multe informații pentru a se pregăti corespunzător pentru schimbare, cu atât mai bine.

A pune la dispoziția clienților PHP 8.0 sau 8.1 ca gazdă web este un lucru, dar, făcând acest lucru, aceștia trebuie să se asigure că creează conștientizarea clienților, astfel încât aceștia să fie conștienți că pot apărea probleme. Se recomandă testarea site-ului într-un mediu de pregătire cu o versiune diferită de cea live. (Selectarea versiunilor PHP este disponibilă implicit la Kinsta.)

Versiune PHP minimă pentru WordPress

Peste 15% din toate site-urile web folosesc în prezent versiunea PHP 7.0 sau mai mică. Acest lucru poate fi văzut în statisticile oficiale WordPress. Aproximativ 83% din toate site-urile WordPress folosesc în prezent versiunea PHP 7.4 sau mai mică. Vă rugăm să rețineți că orice versiune mai mică sau egală cu versiunea 7.4 nu mai este suportată în prezent de PHP. Folosirea versiunilor PHP de sfârșit de viață poate duce la probleme, deoarece actualizările de securitate nu mai sunt lansate.

Pentru a evita probleme, este important ca proprietarii de site-uri WordPress să cunoască și să fie informați cu privire la versiunea PHP minimă care va permite site-ului lor să ruleze în siguranță. La rândul lor, proprietarii site-ului pot modifica singuri versiunea PHP (posibil la Kinsta pentru toate pachetele) sau pot cere gazdei lor să actualizeze site-ul la o versiune PHP mai nouă. În cazuri extreme, puteți trece la o gazdă care acceptă aceste versiuni mai noi.

Deoarece WordPress necesită doar o versiune minimă de 7.4, nu există o motivație suficientă pentru multe gazde și proprietari de site-uri web pentru a-și actualiza site-urile. Și asta în ciuda faptului că PHP 7.4 a ajuns la sfârșitul vieții în noiembrie 2022.

Dacă WordPress crește vreodată versiunea PHP minimă, aceasta poate însemna că multe site-uri nu vor mai fi compatibile cu o actualizare la cea mai recentă versiune WordPress. Cu toate acestea, actualizările de securitate vor continua să fie lansate pentru acele versiuni învechite de ceva timp.

rezumat

Pentru a trece la PHP 8.0 sau o versiune ulterioară pentru site-ul dvs. web, există câțiva pași pe care dvs. sau dezvoltatorul dvs. trebuie să îi efectuați. Pașii importanți includ:

• Analiza statica
• Testarea unitară
• Testarea integrării
• Testare manuală

Când treceți la PHP 8.x, asigurați-vă că totul a fost testat corespunzător. Acesta este singurul mod de a garanta că site-ul dvs. va rula corect, rapid și sigur pe o versiune PHP mai nouă.

Îi mulțumim enorm Juliettei pentru participarea la acest articol și pentru toată munca ei la instrumentele menționate!

Fotografie cu Juliette, făcută de Jip Moors și folosită cu permisiunea.