Opgradering af et WordPress-websted, plugin eller tema til en ny version af PHP er en opgave, som du jævnligt skal udføre. Men hvordan gør du det så effektivt som muligt? Hvordan kan du vide, at du ikke overser noget? Er der en køreplan for det?
I denne artikel tager vi fat på disse spørgsmål (og flere) og ser på, hvad der er involveret i en problemfri overgang til PHP 8.x for dit WordPress-websted, plugin eller tema, herunder en køreplan.
Vi gør dette på baggrund af et interview, som vi har foretaget med PHP-ekspert Juliette Reinders Folmer. Hun bruger det meste af sin dagligdag på programmering og alt omkring det, og fokuserer primært på open source-projekter, herunder WordPress.
Er du også klar til at foretage et smidigt skift? Er du nysgerrig efter vores trin-for-trin-plan? Så lad os dykke ned med det samme!
PHP 8.x – Hvad er der ændret?
For at få et overblik over ændringerne anbefaler vi nedenstående artikler:
- Udgivelsesbemærkninger for PHP 8.0 og PHP 8.1
- Migrationsvejledning for PHP 8.0 og PHP 8.1
- WordPress og PHP 8.0 og den aktuelle status
- Hvad er nyt i PHP 8.0 og PHP 8.1
- Nyheder i PHP 8.2 og PHP 8.2 migrationsguide.
Når du har læst disse artikler, vil du være helt opdateret på, hvad der er ændret i PHP 8.x, og hvad du skal gøre for at få dine PHP-projekter til at køre uden problemer.
Hvis du er usikker på, hvad der er den bedste måde at starte på, er det ikke noget problem. I samtalen med Juliette diskuterede vi dette i detaljer, og vi vil i denne artikel forklare dig så fyldestgørende som muligt, hvordan du kan skifte til PHP 8.x.
Vi vil også forklare i informative bokse, hvordan du udfører forskellige operationer i MyKinsta, vores proprietære kontrolpanel til alle dine WordPress-websteder, applikationer og databaser.
Skift til PHP 8.x: Sådan kommer du i gang
At skifte til PHP 8.x lyder simpelt, og det er det teknisk set også. Mange værter giver dig mulighed for at angive, hvilken version af PHP du ønsker at bruge til dit websted i administrationspanelet. Hos Kinsta kan du skifte PHP-versionen med et enkelt klik i MyKinsta-dashboardet.
Men før du gør det, er der nogle ting, du skal være sikker på. Afhængigt af dit videns- og erfaringsniveau anbefaler vi følgende:
- Hvis du har bygget dit eget WordPress-websted med standardtemaer og plugins uden at have meget viden om PHP, skal du hyre en udvikler eller et bureau til at undersøge, om dit websted er egnet til at køre på PHP 8.x. Leder du efter en tredjepart, der kan hjælpe dig med dette? Så kig på vores Partnerside med en liste over flere pålidelige virksomheder, der kan hjælpe dig.
- Hvis dit WordPress-websted er bygget af en ekstern part, en udvikler eller et bureau, skal du kontakte dem for at spørge, om dit websted kan køre på PHP 8.x.
- Hvis du selv har bygget dit WordPress-websted – f.eks. med dit eget tilpassede tema eller selvudviklede plugins – har vi en køreplan til dig nedenfor.
Hvis dit websted falder ind under en af de to første kategorier, opfordrer vi dig bestemt til at læse resten af artiklen, men vi anbefaler ikke, at du selv begynder at teste dit websted for PHP 8-kompatibilitet. Overlad det til de professionelle.
Uanset hvad du vælger, vil vi råde dig til ikke bare at skifte dit live-site til PHP 8 og “se, om det virker” Er du nysgerrig på, hvordan dit websted vil se ud, og kan du ikke vente med at se det køre med PHP 8? Så begynd at teste i et scenemiljø. En god host vil give dig mulighed for nemt at oprette et scenemiljø.
I scenemiljøet kan du aktivere PHP 8.x og se, om denne opdatering fungerer godt med dit websted. Det er også muligt at arbejde med en lokal kopi af dit websted. Med vores gratis DevKinsta-udviklingsværktøj kan du nemt importere dit websted fra MyKinsta-dashboardet, hvorefter du kan ændre PHP-versionen til 8.0 eller 8.1.
Hvis du ikke kan se nogen problemer i staging-miljøet, betyder det ikke nødvendigvis, at der faktisk ikke er nogen problemer. I nedenstående køreplan kan du se hvorfor.
Test af PHP 8.x-kompatibilitet: Køreplan
Test: nøgleordet til god software. Selv for WordPress-websteder og deres komponenter, såsom temaer, plugins og WordPress-kernen, er testning et middel til at sikre, at der ikke sker ting, som du ikke ønsker skal ske.
Et softwareudviklingsprojekt består i høj grad af testning. I denne artikel ser vi specifikt på de tests, der kan hjælpe dig med at få overgangen til PHP 8.x til at gå glat. I vores artikel om DevOps-værktøjer finder du et afsnit med en samling af værktøjer, du kan bruge.
Følgende typer af tests behandles i dette blogindlæg:
Lad os se nærmere på de forskellige typer af tests, vi kan udføre.
Statisk analyse (eller statisk test)
Det første skridt, du kan tage som PHP-udvikler, er at udføre en statisk analyse af din kode med forskellige værktøjer. Statisk analyse er en proces, hvor man analyserer software uden at udføre koden. Med statisk analyse er det muligt at opdage fejl, opdage problemer med PHP 8.x-kompatibilitet, håndhæve kodningsstandarder (f.eks. WordPress-kodningsstandarderne), og det er endda muligt at ændre og rydde op i koden.
Værktøjer til statisk analyse
Du kan udføre en statisk analyse med forskellige værktøjer, f.eks:
I skrivende stund understøttes ikke alle kontroller af PHP 8.1 i den seneste udgave af PHPCompatibility. PHP 8.1-kontroller kan være i udviklingsudgaven, så sørg for at bruge disse (indtil videre), når du bruger PHPCompatibility til at analysere dit projekt og se, hvilke fejl/anbefalinger der er.
PHP 8.1-kontroller vil snart blive frigivet i en ny større version. Hvis du vil holdes opdateret om dette, og du har en GitHub-konto, skal du åbne GitHub-repositoriet for PHPCompatibility og navigere til Watch -> Custom -> Releases, hvor du kan vælge at blive underrettet, når en ny version udgives.
PHPCompatibility, som kun tester kompatibilitet for en bestemt version (eller række af versioner) af PHP, er let at opsætte. Du får de bedste resultater, hvis du kører en testVersion – f.eks. 8.0+ (8.0 og opefter) – inden for PHPCompatibility.
Du bør holde øje med forældede eller slettede funktioner, ændrede standardværdier for funktionsparametre, om du skal bruge concat uden parenteser, om du skal bruge match som funktionsnavn (da det har været reserveret siden PHP 8.0) osv.
Psalm og PHPStan er gode tilføjelser og kan hjælpe dig ved at udføre yderligere kontroller i forbindelse med variabelstyper. Ulempen ved disse værktøjer er, at det kræver en masse konfiguration for at få rapporter om PHP 8.0 og 8.1. Selv hvis de er vellykkede, kan du forvente mange falske positive resultater. False positives er indberetninger, der gives forkert, hvilket skyldes begrænsningerne i statisk analyse.
Der kræves solid viden for at fortolke resultaterne fra disse to værktøjer korrekt, men denne viden kan hjælpe dig med at identificere yderligere inkompatibiliteter, som PHPCompatibility ikke kan finde. Se dokumentationen for Psalm og PHPStan, hvis du vil lære mere om dem.
Sammenfatning:
- Udfør statisk analyse med PHPCompatibility, Psalm, PHPStan
- Løs alle legitime problemer
Test af enheder
Det næste trin i processen er enhedstest. Enhedstest er en metode til at teste kodestykker enkeltvis. Ved enhedstestning udvikles der specifikke målrettede tests for hver enhed. Dette vil indebære, at forskellige scenarier skal køres igennem. Det er at foretrække, at hvert scenarie testes separat fra de andre, så testene er uafhængige af hinanden.
Det er naturligvis ikke nok at have unit-tests alene. De skal også køres. Unit tests automatiseres bedst ved hjælp af CI-værktøjer (continuous integration) som Jenkins, GitHub Actions eller Travis.
Understøttelse af flere versioner af PHP
Hvis du som plugin-bygger ønsker at understøtte flere PHP-versioner, skal du sikre, at testene i CI køres mod alle de PHP-versioner, du understøtter.
Du kan selvfølgelig også kun understøtte nyere versioner, valget er helt op til dig.
Test med flere versioner af PHP kræver, at du bruger flere PHPUnit-versioner, afhængigt af PHP-versionen. Da PHPUnit har indført flere ændringer i løbet af årene, der påvirker, hvordan testene skrives, kan denne del være vanskelig.
For at komme udenom dette kan du bruge PHPUnit Polyfills (skrevet af Juliette og sponsoreret af Yoast). Dette giver dig mulighed for at skrive tests, der officielt ikke understøttes af PHPUnit 9 (og som derfor kan køre på PHP 8.x). Polyfills får derefter dine tests til at fungere i PHPUnit 4.x til 9.x og med PHP 5.4 til PHP 8.1 (fra nu af).[/notice]
Nu hvor du har testene kørende, er det næste skridt at sikre, at de problemer, der er fundet i testene, er rettet.
Kodedækning
Kørsel af disse tests er den mest pålidelige måde at finde inkompatibiliteter på tværs af versioner på.
I den forbindelse skal du være opmærksom på kodedækningen af dine tests:
- Lad os antage, at du har en funktion A og har skrevet en test for den, og at funktion A kalder funktionerne B, C og D som en del af logikken i funktionen.
- Testen for funktion A er skrevet for at teste logikken i funktion A, men den vil også kalde funktionerne B, C og D under testen. For funktionerne B, C og D tester man så normalt kun “happy path” – den situation, hvor alt går godt – og dermed er disse funktioner heller ikke fuldt ud testet endnu, selv om (en del af) koden i disse funktioner udføres under testen af funktion A.
- For hver af dine tests skal du angive, hvilken kode der specifikt testes. Det gør du ved at give hver test et @covers På denne måde “tæller B, C og D ikke med” i beregningen af kodedækningen, hvilket giver dig mulighed for at se, hvilken del af din kode der er dækket af testene.
Ofte skriver og tester udviklere – nogle gange endda ubevidst – for “den lykkelige vej”. I disse tilfælde er det også nødvendigt at teste, hvad der sker, når der overføres uventede data til en funktion. Det er ikke nok at teste med kun forventede værdier/typer.
Den anden del af ovenstående citat bliver ofte glemt, selv om den måske er endnu vigtigere end den første del. Hvad sker der, hvis du overfører en forkert type? Får du en fejlmeddelelse? Eller bliver variablen castet med funktionen fortsætter som normalt? Hvad sker der, hvis der overgives en uventet værdi til funktionen?
Sørg for at teste dine funktioner med uventede variabler, typer og værdier. Kun på den måde kan du stole på, at dine tests kan finde problemer, som en ny PHP-version kan forårsage.
PHP bliver strengere og strengere
PHP bliver mere præcis (strict) i sin håndtering af “typer” for PHP’s egne funktioner samt ting som dynamiske egenskaber. Disse ændringer har generelt til formål at hjælpe udviklere med at levere fejlfri kode (altså kode med færre fejl). Men dette kan udgøre en stor opgraderingshøjde for allerede eksisterende kode, der er skrevet på grundlag af de “gamle” principper i PHP.
På grund af denne stræben efter mere nyttige fejlmeddelelser i PHP kan du se, at det tager mere og mere tid at gøre eksisterende kode egnet til nye PHP-versioner. At gøre kode, der fungerede i PHP 5.6, egnet til PHP 7.0, tog i de fleste tilfælde kun en brøkdel af tiden sammenlignet med at opgradere kode, så den blev egnet til PHP 8.1. Og det er på trods af, at PHP 7.0 var en “major”-udgave, mens PHP 8.1 er en “minor”-udgave
I mange tilfælde er testning stadig den eneste pålidelige måde at afgøre, hvad der skal ændres for at understøtte en ny version.
Unit testing er muligt med forskellige værktøjer, f.eks:
Mange af disse værktøjer er bygget på eller i forbindelse med PHPUnit.
I sidste ende er det ligegyldigt, hvilke værktøjer du bruger. Det vigtigste er, at du tester, og at du får testene til at køre på nye PHP-versioner. Dette trin kan nogle gange være meget tricky, men heldigvis findes der som tidligere nævnt værktøjer til dette, såsom PHPUnit Polyfills.
Integrationstestning
Integrationstest er det næste trin, vi udfører efter statisk analyse og enhedstest. En integrationstest er der, hvor virkelige situationer testes i en større sammenhæng end blot en “kodenhed” Det drejer sig f.eks. om test med en aktiv (test)database eller test med et eksternt API, for blot at give to eksempler.
Så når du tester koden for et plugin eller tema i forbindelse med WordPress og bruger en rigtig version, er der pr. definition tale om integrationstest.
WP Test Utils (igen skrevet af Juliette og sponsoreret af Yoast) er et fremragende værktøj til integrationstest. WP Test Utils leverer værktøj til at skrive integrations- og enhedstests, hvor WordPress “mocked up” ved hjælp af Brainmonkey og Mockery, hvor almindeligt anvendte WordPress-funktioner “fakes”, så du tester din egen kode og ikke WordPress-koden.
Integrationstest med WordPress er en mere tricky historie, fordi det involverer integration med WordPress og WordPress’ testsuite. Afhængigt af hvilke versioner af WordPress et plugin eller tema understøtter, skal du overveje, hvilke PHPUnit-versioner der understøttes af WordPress selv for at køre testene på forskellige PHP-versioner.
WordPress 5.6 til 5.8 bruger f.eks. PHPUnit 5 til 7 til at teste PHP 5.6 til PHP 8.0, men fra WordPress 5.9 bruger WordPress selv også PHPUnit Polyfills til bredere understøttelse. WP Test Utils fungerer som en bro for at overvinde alle disse forskelle.
Vil du lære mere om, hvordan du kører integrationstest mod flere forskellige versioner af WordPress, herunder WordPress 5.9 og nyere? Så læs om det på WordPress’ websted.
Manuel testning
Nu hvor du har gennemgået enhedstest og integrationstest og har rettet alle de problemer, du har fundet, er det tid til at lave manuel test. Dit websted kører, og din egen kode fungerer, men du bruger også plugins A, B og C. Ved du, om disse plugins er kompatible?
Tjek f.eks. dette med pluginets forfattere og se, om de angiver, at det er PHP 8.x-kompatibelt. Spørgsmålet er så selvfølgelig, hvordan plugin’et er blevet testet. Ofte er svaret her: isoleret. Pluginets funktioner er normalt blevet testet i forbindelse med WordPress alene, uden andre aktive plugins. Og selv hvis der blev brugt andre plugins i disse tests, er der stor sandsynlighed for, at ikke alle plugins, som du bruger, var en del af testen, så tag en sådan kompatibilitetserklæring med et gran salt.
For eksempel et WordPress-websted med 3 plugins (A, B og C). Det er muligt, at plugin B f.eks. returnerer en forkert variabel type via et filter, som plugin C, der bruger det samme filter, ønsker at arbejde med. Dette kan så forårsage en fatal fejl, fordi typen ikke længere er den forventede. Plugin C ses så som den skyldige for fejlmeddelelsen, selv om plugin B er den egentlige synder.
Plugin-interoperabilitet-inkompatibiliteter er umulige at opdage, når man tester isoleret. Jo flere aktive plugins, jo større er sandsynligheden for, at noget går galt. Det ville f.eks. være meget gavnligt at sende sideanmodninger fra et livewebsted til et scenemiljø (med fejllogning aktiveret) for at opdage, hvad der faktisk går galt.
Med denne type problem vil en webstedsejer normalt kun se en meddelelse om, at der var en fejl med den sidst udførte kode (i dette tilfælde fra plugin C), selv om plugin C ikke nødvendigvis er årsagen til problemet.
I de fleste tilfælde er der en masse manuelt, menneskeligt arbejde involveret, og der kræves en god portion albuefedt for at opdage og løse disse problemer. Dette kunne automatiseres ved hjælp af end-to-end-test, men vi ser ikke, at dette sker meget i WordPress.
Test tilgængelighed for udnyttede plugins
For udviklere og udviklingsteams: Accepter kun kode, når test er tilgængelige. På den måde sikrer du, at der kræves mindre manuel testning, hvilket sparer dig for en masse tid.
Stil spørgsmålstegn ved dens teststrategi, hvis du ønsker at købe et kommercielt plugin eller tema. På den måde skaber vi i fællesskab bevidsthed blandt udviklere/udviklingsteams i WordPress-fællesskabet om at få testning højere op på dagsordenen, og det kommer os alle til gode.
Testning bliver ofte – uretfærdigt – opfattet som en omkostning, når det i virkeligheden sparer penge. Den ekstra investering, der kræves for at skrive tests, betaler sig i form af betydeligt færre fejlrapporter og mindre tid brugt på at rette fejl. Med automatiseret softwaretestning kan udvidelser og ændringer desuden gennemføres hurtigere, fordi testene hurtigt kan bekræfte, at den eksisterende funktionalitet fortsat fungerer.
WordPress-værternes rolle og PHP 8.x
For den gennemsnitlige webstedsejer er vejledning fra din host yderst ønskelig. Overvej følgende:
- Dokumentation og opdateringer til kunderne om, at WordPress Core, plugins og/eller temaer (i nogle tilfælde) ikke er kompatible med PHP på tværs af versioner
- Muligheder for test (såsom at arbejde med et scenemiljø)
- Metoder til fejlrapportering og kontakt med support
Dette er også en fordel for en webhost, da webstedsejere ofte kontakter hostet for at få hjælp, når der opstår problemer. I tilfælde af et skift til PHP 8.0, 8.1 eller 8.2 er ejeren af webstedet ansvarlig for potentielle problemer, og jo flere oplysninger ejeren har for at kunne forberede skiftet ordentligt, jo bedre er det.
At stille PHP 8.1 eller 8.2 til rådighed for kunderne som webhost er én ting, men i den forbindelse skal de sørge for at skabe opmærksomhed blandt kunderne, så de er klar over, at der kan opstå problemer. Det anbefales at teste dit websted i et scenemiljø med en anden version end live-versionen. (Valg af PHP-versioner er tilgængelig som standard hos Kinsta)
Minimum PHP-version til WordPress
Over 15 % af alle websteder bruger i øjeblikket PHP-version 7.0 eller lavere. Dette kan ses i de officielle WordPress-statistikker. Omkring 83% af alle WordPress-websteder bruger i øjeblikket PHP-version 8.0 eller lavere. Bemærk venligst, at alt, der er lavere end eller lig med version 7.4, i øjeblikket ikke længere understøttes af PHP. Brug af udtjente versioner af PHP kan medføre problemer, fordi sikkerhedsopdateringer ikke længere udgives.
For at undgå problemer er det vigtigt, at ejere af WordPress-websteder er opmærksomme på og informeret om den mindste PHP-version, der gør det muligt for deres websted at køre sikkert. Ejere af websteder kan for deres vedkommende selv ændre PHP-versionen (muligt hos Kinsta for alle pakker) eller bede deres host om at opdatere webstedet til en nyere PHP-version. I ekstreme tilfælde kan man skifte til en vært, der understøtter disse nyere versioner.
Da WordPress kun kræver en minimumsversion på 7.4, er der ikke tilstrækkelig motivation for mange værter og webstedsejere til at opdatere deres websteder. Og det er på trods af, at PHP 7.4 nåede sin slutdato i november 2022.
Hvis WordPress nogensinde øger minimumsversionen af PHP, kan det betyde, at mange websteder ikke længere vil være kompatible med en opdatering til den nyeste WordPress-version. Der vil dog fortsat blive udgivet sikkerhedsopdateringer til disse forældede versioner i et stykke tid endnu.
Opsummering
For at skifte til PHP 8.0 eller højere for dit websted er der flere trin, som du eller din udvikler skal udføre. Vigtige trin omfatter:
- Statisk analyse
- Test af enheder
- Integrationstest
- Manuel test
Når du skifter til PHP 8.x, skal du sikre dig, at alt er blevet testet korrekt. Det er den eneste måde at garantere, at dit websted vil køre korrekt, hurtigt og sikkert på en nyere PHP-version.
Vi takker Juliette enormt meget for at deltage i denne artikel og for alt hendes arbejde med de nævnte værktøjer!
Foto af Juliette, taget af Jip Moors og brugt med tilladelse.
Skriv et svar