Att uppgradera en WordPress-webbplats, ett plugin eller ett tema till en ny version av PHP är en uppgift som återkommer regelbundet. Men hur gör du detta så effektivt som möjligt? Hur vet du att du inte förbiser något? Finns det en färdplan för det?
I den här artikeln tar vi itu med dessa frågor (och fler). Vi tittar exempelvis på vad som krävs för en smidig övergång till PHP 8.x för din WordPress-webbplats, dina plugins eller ditt tema, inklusive en färdplan.
Vi gör detta utifrån en intervju som vi genomförde med PHP-experten Juliette Reinders Folmer. Hon ägnar större delen av sitt dagliga liv åt programmering och allt runt omkring. Hennes fokus ligger dessutom främst på projekt med öppen källkod, inklusive WordPress.
Är du också redo att göra övergången smidigt? Är du nyfiken på vår steg för steg-plan? Låt oss då köra igång direkt!
PHP 8.x – vad som har ändrats
För en översikt över förändringarna så rekommenderar vi exempelvis artiklarna nedan:
- Versionshänvisningar för PHP 8.0 och PHP 8.1
- Migreringsguide för PHP 8.0 och PHP 8.1
- WordPress och PHP 8.0 och nuvarande status
- Nyheter i PHP 8.0 och PHP 8.1
- Vad är nytt i PHP 8.2 och PHP 8.2 migreringsguide.
Efter att ha läst dessa artiklar så är du helt uppdaterad om vad som har ändrats i PHP 8.x. Du får dessutom koll på vad du behöver göra för att få dina PHP-projekt att fungera utan problem.
Om du är osäker på hur du kommer igång så är det inga problem. I samtalet med Juliette så diskuterade vi detta i detalj. Den här artikeln kommer sedan att ge en så fullständig förklaring som möjligt om hur du kan byta till PHP 8.x.
Vi kommer dessutom att förklara i informativa rutor hur du utför olika operationer i MyKinsta. Det är vår egen kontrollpanel för alla dina WordPress-webbplatser, applikationer och databaser.
Byte till PHP 8.x: Så här kommer du igång
Att byta till PHP 8.x låter enkelt, och tekniskt sett så stämmer detta. Många hostar låter dig ange vilken version av PHP som du vill använda för din webbplats i administratörspanelen. På Kinsta så kan du byta PHP-version med ett enda klick i instrumentpanelen MyKinsta.
Men innan du gör detta så finns det några saker som du måste vara säker på. Beroende på din kunskaps- och erfarenhetsnivå så rekommenderar vi exempelvis följande:
- Har du byggt din egen WordPress-webbplats med standardteman och plugins utan att ha någon större kunskap om PHP? Då rekommenderas det att du anlitar en utvecklare eller en agentur för att undersöka om din webbplats är lämplig att köra på PHP 8.x. Letar du efter en tredje part som kan hjälpa dig med detta? Titta då på vår sida för Partners där flera pålitliga företag som kan hjälpa dig listas.
- Om din WordPress-webbplats byggdes av en extern part, en utvecklare eller en agentur, kontakta dem för att fråga om din webbplats kan köras med PHP 8.x.
- Om du har byggt din WordPress-webbplats – exempelvis med ett eget anpassat tema eller egenutvecklade plugins – så har vi en färdplan för dig nedan.
Tillhör din webbplats någon av de två första kategorierna? Då uppmanar vi dig givetvis att läsa resten av artikeln. Vi rekommenderar dock inte att du börjar testa din webbplats för PHP 8-kompatibilitet själv. Lämna detta till proffsen.
Oavsett vad du väljer så råder vi dig att inte bara byta din live-webbplats till PHP 8 och ”se om det fungerar”. Är du nyfiken på hur din webbplats kommer att se ut, och kan inte vänta på att se den köras med PHP 8? Börja då med att testa i en iscensättningsmiljö. Med en bra host så kan du enkelt sätta upp en iscensättningsmiljö.
I iscensättningsmiljön så kan du aktivera PHP 8.x och se om uppdateringen fungerar bra med din webbplats. Det är dessutom möjligt att arbeta med en lokal kopia av din webbplats. Med vårt kostnadsfria utvecklingsverktyg DevKinsta så kan du enkelt importera din webbplats från instrumentpanelen i MyKinsta. Du kan sedan ändra PHP-versionen till 8.0 eller 8.1.
Om du inte möter några problem i iscensättningsmiljön så behöver detta inte betyda att det inte finns några problem. I färdplanen nedan så får du veta varför.
Testning av kompatibilitet med PHP 8.x: Färdplan
Testning: nyckelordet till bra programvara. Detta gäller även för WordPress-webbplatser och deras komponenter, såsom teman, plugins och WordPress-kärnan. Det är helt enkelt ett sätt att se till att det inte händer saker som du inte vill ska hända.
Ett programvaru-utvecklingsprojekt består till stor del av testning. I den här artikeln så tittar vi särskilt på de tester som kan hjälpa dig att få övergången till PHP 8.x att gå smidigt. Vår artikel om DevOps-verktyg har exempelvis ett avsnitt med en samling av verktyg som du kan använda.
Följande typer av tester diskuteras i det här blogginlägget:
Låt oss titta närmare på de olika typerna av tester som vi kan utföra.
Statisk analys (eller statisk testning)
Det första steget som du kan vidta som PHP-utvecklare är att utföra en statisk analys av din kod med olika verktyg. Statisk analys är en process som analyserar programvara utan att exekvera koden. Med statisk analys så är det möjligt att upptäcka fel, upptäcka problem med PHP 8.x-kompatibilitet, genomdriva kodningsstandarder (exempelvis WordPress kodningsstandarder). Det är dessutom möjligt att ändra och rensa upp koden.
Verktyg för statisk analys
Du kan utföra en statisk analys med olika verktyg, exempelvis:
I skrivande stund så stöds inte alla kontroller av PHP 8.1 i den senaste versionen av PHPCompatibility. Kontroller av PHP 8.1 kan finnas i utvecklingsutgåvan. Se därför till att du använder dessa (för tillfället) när du använder PHPCompatibility för att analysera ditt projekt och se vilka fel/rekommendationer som finns.
Kontroller av PHP 8.1 kommer snart att släppas i en ny större version. Vill du hålla dig uppdaterad om detta och har ett GitHub-konto? Öppna då GitHub-arkivet för PHPCompatibility och navigera till Titta -> Anpassning -> Utgåvor, där du kan välja att bli meddelad när en ny version släpps.
PHPCompatibility, som endast testar kompatibilitet för en viss version (eller ett antal versioner) av PHP, är lätt att konfigurera. Du får bäst resultat om du kör en testversion – exempelvis 8.0+ (8.0 och uppåt) – inom PHPCompatibility.
Du bör dock hålla utkik efter föråldrade eller borttagna funktioner, ändrade standardvärden för funktionsparametrar samt om du ska använda concat utan parenteser. Undersök även om du ska använda match som funktionsnamn (eftersom det har varit reserverat sedan PHP 8.0) osv.
Psalm och PHPStan är bra tillägg och kan hjälpa dig genom att utföra ytterligare kontroller som är relaterade till variabeltyper. Nackdelen med dessa verktyg är att det krävs en hel del konfigurering för att få rapporter om PHP 8.0 och 8.1. Även om de lyckas så kan du exempelvis förvänta dig många falska positiva resultat. Falska positiva är anmälningar som ges felaktigt och som orsakas av begränsningarna i den statiska analysen.
Det krävs gedigna kunskaper för att tolka resultaten från dessa två verktyg korrekt. Den kunskapen kan däremot hjälpa dig att identifiera ytterligare inkompatibiliteter som PHPCompatibility inte kan hitta. Titta på dokumentationen för Psalm och PHPStan om du vill lära dig mer om dem.
Sammanfattning:
- Utför statisk analys med PHPCompatibility, Psalm och PHPStan
- Lös alla legitima problem
Testning av enheter
Nästa steg i processen är enhetstestning. Enhetstestning är en metod för att testa delar av koden individuellt. Vid enhetstestning så utvecklas specifika riktade tester för varje enhet. Detta kommer exempelvis att innebära att man kör igenom olika scenarier. Helst så testas varje scenario separat från de andra så att testerna är oberoende av varandra.
Det räcker naturligtvis inte med att endast ha enhetstester. De måste dessutom köras. Enhetstester automatiseras bäst med hjälp av CI-verktyg (continuous integration) som Jenkins, GitHub Actions eller Travis.
Stöd för flera versioner av PHP
Om du som plugin-byggare vill stödja flera PHP-versioner så ska du se till att testerna i CI körs mot alla PHP-versioner som du stöder.
Du kan naturligtvis välja att endast stödja nyare versioner, valet är helt upp till dig.
Testning med flera versioner av PHP kräver att du använder flera PHPUnit-versioner, beroende på PHP-versionen. Eftersom PHPUnit har infört flera ändringar under åren som påverkar hur tester skrivs så kan den här delen vara knepig.
För att komma runt detta så kan du exempelvis använda PHPUnit Polyfills (skrivet av Juliette och sponsrat av Yoast). Som ett resultat så kan du skriva tester som officiellt inte stöds av PHPUnit 9 (och som därmed kan köras på PHP 8.x). Polyfills gör sedan att dina tester fungerar i PHPUnit 4.x till 9.x och med PHP 5.4 till PHP 8.1 (från och med nu).[/notice]
Nu när du har testerna igång så är nästa steg att se till att de problem som upptäcktes i testerna är åtgärdade.
Kodtäckning
Att köra dessa tester är det mest tillförlitliga sättet att hitta inkompatibilitet mellan olika versioner.
När du gör detta så ska du vara uppmärksam på kodtäckningen i dina tester:
- Anta att du har en funktion A och har skrivit ett test för den. Du kan även anta att funktion A anropar funktionerna B, C och D som en del av logiken i funktionen.
- Testet för funktion A är skrivet för att testa logiken i funktion A. Det kommer dock även att anropa funktionerna B, C och D under testningen. För funktionerna B, C och D så testar man då vanligtvis bara ”den lyckliga vägen” – den situation där allt går bra. Som ett resultat så är dessa funktioner inte heller helt testade ännu, även om (en del av) koden i dessa funktioner utförs under testningen av funktion A.
- Ange för varje test vilken kod som testas specifikt. Du gör exempelvis detta genom att ge varje test en @covers På så sätt ”räknas” inte B, C och D med i beräkningen av kodtäckningen. Du kan därför se vilken del av din kod som täcks av testerna.
Ofta skriver och testar utvecklare – ibland till och med omedvetet – för den ”lyckliga vägen” I dessa fall är det även nödvändigt att testa vad som händer när oväntade data skickas till en funktion. Det räcker inte att testa med endast förväntade värden/typer.
Den andra delen av citatet ovan glöms ofta bort, trots att den kanske är ännu viktigare än den första delen. Vad händer om du lämnar över en felaktig typ? Får du ett felmeddelande? Eller kastas variabeln medan funktionen fortsätter som vanligt? Vad händer om ett oväntat värde lämnas över till funktionen?
Se till att testa dina funktioner med oväntade variabler, typer och värden. Först då så kan du lita på att dina tester hittar problem som en ny PHP-version kan orsaka.
PHP blir strängare
PHP blir mer exakt (strikt) i hur det hanterar ”typer” för PHP’s egna funktioner samt saker som dynamiska egenskaper. Dessa förändringar är generellt avsedda att hjälpa utvecklare att leverera felfri kod (eller åtminstone kod med färre fel). Men detta kan dessvärre utgöra ett rejält uppgraderingshinder för redan existerande kod som har skrivits enligt de ”gamla” principerna för PHP.
Det finns med andra ord en strävan efter mer hjälpsamma felmeddelanden i PHP. Som ett resultat så kan du se att det tar allt mer tid att göra befintlig kod lämplig för nya PHP-versioner. Att göra kod som fungerade med PHP 5.6 lämplig för PHP 7.0 tog i de flesta fall bara en bråkdel av tiden jämfört med att uppgradera kod för att göra den lämplig för PHP 8.1. Och detta trots att PHP 7.0 var en ”större” version, medan PHP 8.1 är en ”mindre”
I många fall så är testning fortfarande det enda tillförlitliga sättet att avgöra vad som behöver ändras för att stödja en ny version.
Enhetstestning är möjlig med olika verktyg, exempelvis:
Många av dessa verktyg är byggda på eller i samband med PHPUnit.
I slutändan så spelar det ingen roll vilka verktyg som du använder. Det viktigaste är att du testar och att du får testerna att fungera på nya PHP-versioner. Det här steget kan ibland vara mycket knepigt. Det finns dock som tidigare nämnts verktyg för detta, exempelvis PHPUnit Polyfills.
Integreringstestning
Integreringstestning är nästa steg som vi kommer att utföra, efter statisk analys och enhetstestning. Vid ett integreringstest testas verkliga situationer i ett större sammanhang än bara en ”kodenhet” Det handlar exempelvis om testning med en aktiv (test)databas eller testning med ett externt API, för att bara ge två exempel.
Så när du testar koden för ett plugin eller ett tema i WordPress-sammanhang och använder en riktig version är detta per definition integreringstester.
WP Test Utils (återigen skrivet av Juliette och sponsrat av Yoast) är ett utmärkt verktyg för integreringstester. WP Test Utils tillhandahåller exempelvis verktyg för att skriva integrerings- och enhetstester, där WordPress ”mockas upp” med hjälp av Brainmonkey och Mockery. Där ”fejkas” vanligt förekommande WordPress-funktioner så att du testar din egen kod och inte WordPress-koden.
Integreringstestning med WordPress är en knepigare historia. Det handlar nämligen om integrering med WordPress och WordPress testföljd. Beroende på vilka versioner av WordPress som ett plugin eller tema stöder så måste du överväga vilka PHPUnit-versioner som stöds av WordPress självt. Du kan därefter köra testerna på olika PHP-versioner.
WordPress 5.6 till 5.8 använder exempelvis PHPUnit 5 till 7 för att testa PHP 5.6 till PHP 8.0. Från och med WordPress 5.9 så använder WordPress dessutom PHPUnit Polyfills för ett bredare stöd. WP Test Utils fungerar som en bro för att övervinna alla dessa skillnader.
Vill du veta mer om hur du kör integreringstester mot flera olika versioner av WordPress, inklusive WordPress 5.9 och senare? Läs då om detta på WordPress webbplats.
Manuell testning
Nu har du gått igenom enhetstestning och integreringstestning och åtgärdat alla problem som du hittade. Det är med andra ord dags att göra manuella tester. Din webbplats är igång och din egen kod fungerar. Du använder dock dessutom plugins A, B och C. Vet du om dessa plugins är kompatibla?
Kontrollera exempelvis detta med pluginets författare och se om de anger att det är kompatibelt med PHP 8.x. Frågan är då förstås hur pluginet testades. Ofta är svaret här: isolerat. Pluginets funktioner har vanligtvis testats tillsammans med enbart WordPress, utan andra aktiva plugins. Och även om det användes andra plugins i dessa tester så är chansen stor att alla plugins som du använder inte var en del av testerna. Ta därför ett sådant kompatibilitetsuttalande med en nypa salt.
Ta exempelvis en WordPress-webbplats med 3 plugins (A, B och C). Det är möjligt att plugin B exempelvis returnerar en felaktig variabel typ via ett filter, som plugin C, som använder samma filter, vill arbeta med. Som ett resultat så kan det orsakas ett fatalt fel eftersom typen inte längre är den förväntade. Plugin C ses då som den skyldige till felmeddelandet, även om plugin B är den verkliga boven.
Det är omöjligt att upptäcka kompatibilitetsproblem mellan plugins när man testar isolerat. Ju fler aktiva plugins, desto större är sannolikheten att något går fel. Det skulle exempelvis vara mycket fördelaktigt att skicka sidförfrågningar från en live-webbplats till en iscensättningsmiljö (med felloggning aktiverad) för att upptäcka vad som faktiskt går fel.
Vid den här typen av problem så kommer en webbplatsägare vanligtvis bara att se ett meddelande om att det var ett fel med den senast exekverade koden (i det här fallet från insticksmodul C). Detta gäller även om plugin C inte nödvändigtvis är orsaken till problemet.
I de flesta fall så är det mycket manuellt, mänskligt arbete inblandat. Det krävs dessutom en rejäl dos armbågsolja för att upptäcka och åtgärda dessa problem. Detta skulle kunna automatiseras med hjälp av end to end-testning, men detta sker inte så ofta i WordPress.
Testa tillgängligheten för använda plugins
För utvecklare och utvecklingsteam: Acceptera endast kod när testerna är tillgängliga. På så sätt ser du till att det krävs mindre manuell testning. Som ett resultat så sparar du mycket tid.
Fråga efter dess teststrategi om du vill köpa ett kommersiellt plugin eller tema. Som ett resultat så skapar vi tillsammans en medvetenhet bland utvecklare/utvecklingsteam i WordPress-communityt. Testning kommer därför högre upp på dagordningen, och alla tjänar på detta.
Testning betraktas ofta – orättvist – som en kostnad när det i själva verket sparar pengar. Den extra investering som krävs för att skriva tester lönar sig i form av betydligt färre felrapporter. Det går dessutom åt betydligt mindre tid till att åtgärda fel. Med en automatiserad programvarutestning så kan dessutom utvidgningar och ändringar göras snabbare. Testerna kan ju ge en snabb bekräftelse på att den befintliga funktionaliteten fortsätter att fungera.
Rollen för WordPress-hostar och PHP 8.x
För den genomsnittlige webbplatsägaren så är vägledning från hosten högst önskvärd. Tänk på följande:
- Dokumentation och uppdateringar för kunder om att WordPress-kärnan, plugins och/eller teman (i vissa fall) inte är kompatibla med PHP-versioner
- Alternativ för testning (t.ex. att arbeta med en iscensättningsmiljö)
- Metoder för felrapportering och kontakt med supporten
Detta gynnar även en hosting-leverantör, eftersom webbplatsägare ofta kontaktar hosten för att få hjälp när problem uppstår. Vid ett byte till PHP 8.0, 8.1 eller 8.2 så är det webbplatsägaren som ansvarar för eventuella problem. Ju mer information som ägaren har för att förbereda sig för bytet, desto bättre.
Att göra PHP 8.1 eller 8.2 tillgängligt för kunderna som hosting-leverantör är en sak. De måste dessutom se till att skapa medvetenhet bland kunderna så att de är medvetna om att problem kan dyka upp. Det rekommenderas att man testar webbplatsen i en iscensättningsmiljö med en annan version än live. (Att välja PHP-versioner är tillgängligt som standard på Kinsta.)
Minsta PHP-version för WordPress
Över 15 % av alla webbplatser använder för närvarande PHP-version 7.0 eller lägre. Detta kan ses i den officiella WordPress-statistiken. Omkring 83 % av alla WordPress-webbplatser använder för närvarande PHP-version 7.4 eller lägre. Observera att allt som är lägre än eller lika med version 8.0 för närvarande inte längre stöds av PHP. Om du exempelvis använder PHP-versioner som är i slutet av sin livslängd så kan detta leda till problem eftersom säkerhetsuppdateringar inte längre släpps.
För att undvika problem så är det därför viktigt att ägare av WordPress-webbplatser är medvetna om och informerade om den minsta PHP-versionen. Som ett resultat så kan deras webbplats kan köras säkert. Webbplatsägarna kan själva ändra PHP-versionen (möjligt på Kinsta med alla paket). De kan även be sin host att uppdatera webbplatsen till en nyare PHP-version. I extrema fall så kan man byta till en host som stöder dessa nyare versioner.
Eftersom WordPress endast kräver en minimiversion på 7.4 så är det inte tillräckligt motiverat för många hostar och webbplatsägare att uppdatera sina webbplatser. Och detta trots att PHP 7.4 nådde sitt slutdatum i november år 2022.
Om WordPress någonsin höjer den lägsta PHP-versionen kan detta innebära att många webbplatser inte längre kommer att vara kompatibla med en uppdatering till den senaste WordPress-versionen. Säkerhetsuppdateringar kommer dock att fortsätta att släppas för dessa föråldrade versioner under en lång tid framöver.
Sammanfattning
För att byta till PHP 8.0 eller högre för din webbplats så finns det flera steg som du, eller din utvecklare, måste utföra. Viktiga steg är bland annat följande:
- Statisk analys
- Testning av enheter
- Testning av integrering
- Manuell testning
När du byter till PHP 8.x så ska du se till att allt har testats ordentligt. Det är det enda sättet att garantera att din webbplats kommer att fungera korrekt, snabbt och säkert i en nyare PHP-version.
Vi tackar Juliette oerhört mycket för att hon deltog i den här artikeln och för allt hennes arbete med de nämnda verktygen!
Foto på Juliette, taget av Jip Moors och använt med tillstånd.
Lämna ett svar