Overstappen naar PHP 8.x in vier stappen – Een interview met Juliette Reinders Folmer

Introductie

Het upgraden van een WordPress site, plugin of thema naar een nieuwe versie van PHP is een taak die eens in de zoveel tijd terugkomt. Maar hoe doe je dit zo efficiënt mogelijk? Hoe weet je dat je niets over het hoofd ziet? Is er een stappenplan voor?

In dit artikel gaan we met deze vragen (en meer) aan de slag en kijken we wat er allemaal komt kijken bij een soepele transitie naar PHP 8.x voor jouw WordPress site, plugin of thema, inclusief een stappenplan.

Dit doen we aan de hand van een interview die ik had met PHP-expert Juliette Reinders Folmer. Zij besteedt haar dagelijks leven voor het merendeel aan programmeren en alles wat er bij programmeren komt kijken, en richt zich vooral op opensource-projecten, waaronder WordPress.

Klaar om ook jouw overstap soepel te laten verlopen? Benieuwd naar ons stappenplan? Lees dan snel verder!

PHP 8.x – Dit is er veranderd

Voor een overzicht van de wijzigingen raden we je onderstaande artikelen aan.

• De release notes van PHP 8.0 (In het Nederlands) en PHP 8.1.
• De PHP 8.0 migration guide, de PHP 8.1 migration guide.
• Extra: WordPress en PHP 8.0 en de huidige status.
• Wat is er nieuw in PHP 8, PHP 8.1.

Na het lezen van deze artikelen ben je helemaal op de hoogte van wat er allemaal is veranderd in PHP 8.x en wat je moet doen om je PHP projecten zonder problemen op PHP 8.x te laten draaien.

Als je niet zeker weet hoe je dat het beste kan aanpakken: geen probleem. In het gesprek met Juliette hebben we dit uitvoerig besproken en we gaan je in dit artikel dan ook zo volledig mogelijk uitleggen hoe jij de overstap naar PHP 8.x kan maken.

We zullen in informatieve kaders uitleggen hoe je diverse handelingen uit kan voeren in MyKinsta, ons eigen control panel voor al je WordPress site, applicaties en databases.

Over naar PHP 8.x – Zo begin je

Overstappen naar PHP 8, het klinkt eenvoudig, en technisch gezien is dat het ook. Veel hosters bieden je de mogelijkheid om in het adminpaneel aan te geven welke versie van PHP je wilt gebruiken voor je website. Bij Kinsta is het aanpassen van de PHP versie een kwestie van een enkele klik in het MyKinsta dashboard.

Maar voordat je dat doet, moet je wel een aantal dingen zeker weten. Afhankelijk van je kennisniveau raden we je het volgende aan:

• Als je je WordPress site met standaard thema’s en plugins hebt samengesteld, zonder zelf al te veel kennis van PHP te hebben, schakel dan een developer of een bureau in om te onderzoeken of jouw site geschikt is om op PHP 8.x te draaien. Ben je nog op zoek naar een partij die je hierbij kan helpen? Neem dan een kijkje op onze partnerpagina, waar we een aantal Nederlandse en Belgische partijen hebben staan die je met deze stap kunnen helpen.
• Als je WordPress site is gebouwd door een externe partij, een developer, of een bureau, neem dan contact met ze op om te vragen of jouw site geschikt is om op PHP 8.x te draaien.
• Als je je WordPress site zelf gebouwd hebt, met bijvoorbeeld een eigen thema, of zelfontwikkelde plugins, dan hebben we hieronder een stappenplan voor je.

Wanneer je site in één van de eerste twee categorieën valt, nodigen we je zeker uit om de rest van het artikel door te lezen, maar raden we je echt af om zelf aan de slag te gaan met het testen van je site op PHP 8. Ieder zijn vak, laat het over aan de professionals.

Sowieso willen we je aanraden niet zomaar over te stappen naar PHP 8, en ‘te kijken of het werkt’. Ben je toch nieuwsgierig, en kan je niet wachten? Begin dan met een testomgeving. Een goede hoster geeft je de mogelijkheid om eenvoudig een testomgeving op te zetten.

In de testomgeving kan je PHP 8.x activeren en zo kan je zien of deze update goed werkt op je site. Het is ook mogelijk om met een lokale kopie van je site te werken. Met onze gratis DevKinsta ontwikkeltool, kan je je site makkelijk importeren vanuit het MyKinsta dashboard, waarna je de PHP versie kan veranderen naar 8.0 of 8.1.

Als je in de testomgeving geen problemen ziet, hoeft dat niet te betekenen dat er ook daadwerkelijk geen problemen zijn. In onderstaand stappenplan lees je waarom.

PHP 8.x compatibiliteit testen – Het stappenplan

Testen. Het sleutelwoord tot goede software. Ook voor WordPress websites en de onderdelen daarvan, zoals thema’s, plugins, maar ook WordPress-core (de kern van WordPress), is testen het middel om er voor te zorgen dat er geen dingen gebeuren die je niet wilt dat er gebeuren.

Een software-ontwikkeltraject bestaat voor een groot deel uit testen. In dit artikel kijken we specifiek naar de testen die je kunnen helpen om een transitie naar PHP 8.x soepel te laten verlopen. In ons artikel over DevOps Tools vind je een sectie met een verzameling tools die je kan gebruiken.

De volgende type testen worden hier besproken:

Laten we kijken naar de details van de verschillende soorten testen die we kunnen uitvoeren.

Statische analyse (ook wel statisch testen genoemd)

De eerste stap die je als PHP developer kan zetten is een statische analyse van je code uitvoeren met een variatie van tools. Statische analyse is het proces waarbij software geanalyseerd wordt, zonder daarbij de code uit te voeren. Met statische analyse is het mogelijk fouten te detecteren, problemen met PHP 8.x compatibility te detecteren, coding standaarden af te dwingen (bijvoorbeeld de WordPress Coding Standards) en zelfs het aanpassen en opschonen van code is mogelijk.

Tools voor statische analyse

Een statische analyse kan je uitvoeren met diverse tools, zoals:

• PHPCompatibility
• Psalm
• PHPStan

Op het moment van schrijven zitten niet alle PHP 8.x checks in de laatste PHPCompatibility release. De PHP 8.x checks zitten wel in de develop versie, dus zorg dat je (vooralsnog) die gebruikt als je PHPCompatibility gebruikt om je project te analyseren en te zien welke fouten/aanbevelingen er zijn.

De PHP 8.0 en 8.1 checks zullen binnenkort gereleased worden in een nieuwe major versie. Als je hiervan op de hoogte gehouden wilt worden, en je hebt een GitHub account, stel dan in de GitHub repository van PHPCompatibility Watch -> Custom -> Releases in, dan krijg je een signaal als er nieuwe versie is.

PHPCompatibility, die dus alleen de compatibility test voor een bepaalde versie (of range van versies) van PHP is eenvoudig in te stellen. De beste resultaten krijg je als je een testVersion, bijvoorbeeld 8.0- (8.0 en hoger), meegeeft aan PHPCompatibility.

Denk hierbij aan het vinden van deprecated of verwijderde functies, veranderde default waardes van functie parameters, of je concat gebruikt zonder parenthesis, of je match als functienaam gebruikt (want deze is gereserveerd sinds PHP 8), etc.

Psalm en PHPStan zijn een goede aanvulling en kunnen je vooral helpen door aanvullende checks te doen die te maken hebben met variable types. Het nadeel van deze tools is dat er veel configuratie nodig is om alleen meldingen over PHP 8.0 en 8.1 te krijgen. Zelfs als dat gelukt is, kan je veel false positives verwachten. False positives zijn meldingen die onterecht gegeven worden, veroorzaakt door de beperkingen van statische analyse.

Er is gedegen kennis nodig om de uitkomsten van deze twee tools goed te kunnen interpreteren, maar het kan je zeker helpen om extra dingen te identificeren die PHPCompatibility niet kan vinden. Bekijk vooral eens de documentatie van Psalm en PHPStan om er meer over te leren.

Samenvattend:

• Voer een statische analyse uit met PHPCompatibility, Psalm, PHPStan.
• Los alle legitieme problemen op.

Unittesten

De volgende stap in het proces van testen, is unittesten. Unittesten is een methode om stukken code afzonderlijk te testen. Bij unittesten zullen voor iedere unit specifiek gerichte testen ontwikkeld worden. Hierbij worden dan verschillende scenario’s doorlopen. Bij voorkeur wordt ieder scenario los van de andere scenario’s getest, zodat de testen onafhankelijk van elkaar zijn.

Het hebben van unittesten alleen is natuurlijk niet genoeg. Ze moeten ook gedraaid worden. Unittesten kunnen het beste geautomatiseerd uitgevoerd worden met behulp van CI (continuous integration) tooling zoals Jenkins, GitHub Actions of Travis.

Meerdere versies van PHP ondersteunen

Als je als pluginbouwer meerdere PHP versies wilt ondersteunen, zorg dan dat de testen in CI tegen alle PHP versies die je ondersteunt gedraaid worden.

Je kan er natuurlijk ook voor kiezen om alleen nieuwere versies te ondersteunen, de keuze is geheel aan jou.

Om met meerdere versies van PHP te testen is het nodig dat je meerdere PHPUnit versies gebruikt, afhankelijk van de PHP-versie. Aangezien PHPUnit over de jaren diverse keren wijzigingen geïntroduceerd heeft die gevolgen hebben voor hoe testen geschreven worden, kan dat lastig zijn.

Om dit te omzeilen, kan je gebruik maken van de PHPUnit Polyfills (geschreven door Juliette, gesponsord door Yoast). Dit laat je testen schrijven die officieel onmdersteund zijn voor PHPUnit 9 (en dus kunnen draaien op PHP 8). De Polyfills zorgen er dan voor dat je testen werken in PHPUnit 4.x tot en met  9.x en met PHP 5.4 tot en met PHP 8.1 (op dit moment).

Als je de testen uiteindelijk draaiend hebt, is de volgende stap om ervoor te zorgen dat de problemen die uit de testen komen, opgelost worden.

Het draaien van de testen is de meest betrouwbare manier om cross-version incompatibilities te vinden.

Code coverage

Let hierbij wel op de code coverage van je testen.

• Stel, je hebt een functie A en je hebt daar een test voor geschreven en functie A roept functie B, C en D aan als onderdeel van de logica in de functie.
• De test voor functie A is geschreven om de logica van functie A te testen, maar zal ook functie B, C en D aanroepen tijdens het testen. Voor functie B, C en D test je dan meestal alleen het “happy path”, de situatie waarbij alles goed gaat, en die functies zijn dus ook nog niet geheel getest, ondanks dat (een deel van) de code in die functies wel tijdens het testen van functie A uitgevoerd wordt.
• Geef bij elk van je testen aan welke code specifiek getest wordt. Dit doe je door elke test een @covers tag te geven. Zo worden B, C en D niet “meegeteld” bij de code coverage berekening waarmee je kan zien welk deel van je code afgedekt is door testen.

Vaak wordt er door developers – soms zelfs onbewust – ontwikkeld voor het “happy path”. Let op dat er in deze gevallen ook getest moet worden wat er gebeurt als er onverwachte data aan een functie wordt doorgegeven. Alleen testen met verwachte waarden/typen is niet voldoende.

Het tweede deel van bovenstaand citaat wordt vaak vergeten, terwijl dit misschien nog wel belangrijker is dan het eerste deel. Wat gebeurt er als je een verkeerd type meegeeft? Krijg je een foutmelding, of wordt de variabele gecast en gaat de functie gewoon door? Wat als er een onverwachte waarde aan de functie meegegeven wordt?

Test je functies met onverwachte variabelen, types en waarden, pas dan zal je op je testen kunnen vertrouwen om daadwerkelijk problemen te vinden die een nieuwe PHP versie kan veroorzaken.

PHP wordt steeds strenger

PHP wordt steeds nauwkeuriger (strenger) in hoe het voor de PHP eigen functies met “types” omgaat, maar ook bijvoorbeeld met dingen zoals dynamische properties. Over het algemeen zijn dit soort wijzigingen bedoeld om ontwikkelaars te helpen foutloze code af te leveren (nou ja, code met minder fouten). Maar voor al bestaande code die geschreven is op basis van de “oude” uitgangspunten van PHP, kan dit een behoorlijke upgrade-hobbel geven.

Door deze drive voor meer behulpzame foutmeldingen in PHP, zie je dat het geschikt maken van bestaande code met nieuwe PHP versies steeds meer tijd kost. Het geschikt maken van code die op PHP 5.6 werkte, voor PHP 7.0, koste in de meeste gevallen maar een fractie van de tijd in vergelijking met het upgraden van code om deze geschikt te maken voor PHP 8.1. En dat terwijl PHP 7.0 een “major” release was, terwijl PHP 8.1 een “minor” is.

In veel gevallen zijn testen nog steeds de enige echt betrouwbare manier om te vinden wat er aangepast moet worden om een nieuwe versie te ondersteunen.

Unittesten is mogelijk met diverse tools, o.a.:

• PHPUnit
• Mockery
• Behat,
• Storyplayer

Veel van deze tools zijn gebouwd op basis van, of werken in combinatie met, PHPUnit.

Uiteindelijk maakt het niet uit welke tools je gebruikt, zolang je maar test, en je de testen maar draaiend krijgt op nieuwe PHP versies. Dit kan een stap zijn die soms heel lastig is, maar zoals al eerder gezegd, zijn er gelukkig hulpmiddelen voor zoals PHPUnit Polyfills.

Integratietesten

Integratietesten is de volgende stap die we uit gaan voeren, na de statische analyse en de unittesten. Een integratietest is een test waarbij real-life situaties in een grotere context dan enkel een “code unit”, getest worden. Denk hierbij bijvoorbeeld aan testen met een actieve (test) database of testen met een externe API.

Wanneer je de code van een plugin of thema in de context van WordPress wilt testen, waarbij je daadwerkelijk een echte versie van WordPress gebruikt, zijn dat dus per definitie integratietesten.

Voor integratietesten is WP Test Utils (wederom geschreven door Juliette en gesponsord door Yoast) een prima hulpmiddel. WP Test Utils biedt tooling om zowel integratietesten te schrijven, als ook om unittesten te schrijven, waarin WordPress “gemocked” wordt met behulp van Brainmonkey en Mockery, waarbij veelgebruikte WordPress functies “gefaked” worden zodat je je eigen code test en niet de WordPress code.

Integratietesten met WordPress is een lastiger verhaal, want dan integreer je met WordPress en de test-suite van WordPress. Afhankelijk van welke versies van WordPress een plugin/thema moet ondersteunen, moet je rekening houden met welke PHPUnit versies WordPress zelf ondersteunt om de testen op verschillende PHP versies te laten draaien.

WordPress 5.6 tot en met 5.8 maakt bijvoorbeeld gebruik van PHPUnit 5 tot en met 7 voor PHP 5.6 tot en met PHP 8.0, maar vanaf WordPress 5.9 gebruikt ook WordPress zelf de PHPUnit Polyfills voor een bredere ondersteuning. WP Test Utils werkt als een soort brug om al die verschillen te overkomen.

Wil je meer weten over hoe je integratietesten kan laten draaien tegen meerdere verschillende versies van WordPress, inclusief WordPress 5.9 en hoger? Lees dan het artikel hierover op de WordPress website.

Handmatig testen

Nu je de unittesten en integratietesten hebt doorlopen en alle gevonden problemen hebt opgelost, is het tijd om handmatig te testen. Je site draait, je eigen code werkt, maar je gebruikt ook plugins A, B en C. Weet je of die plugins compatible zijn?

Dit vraag je bijvoorbeeld na bij de auteurs van de plugins, en die geven aan dat deze PHP 8.x compatible is. De vraag is dan natuurlijk, hoe is de plugin getest? Vaak is hier het antwoord: in isolatie. De functies van de plugin zijn veelal alleen samen met WordPress getest, zonder andere actieve plugins. Als er al met andere plugins is getest, dan is de kans aanwezig dat door jou gebruikte plugins niet meegetest zijn, dus neem zo’n compatibility-statement met een korreltje zout.

Neem een WordPress site, met 3 plugins, A, B en C. Het kan voorkomen dat plugin B bijvoorbeeld via een filter een verkeerd variable type teruggeeft, waarmee plugin C, die dezelfde filter gebruikt, aan de slag wil gaan. Dit kan dan een fatal error veroorzaken omdat het type niet meer is wat er verwacht wordt. Plugin C wordt dan als “schuldige” gezien van de foutmelding, maar plugin B is de echte veroorzaker.

Plugininteroperability-incompatibilities ontdek je nooit bij het testen in isolatie. Hoe meer plugins er actief zijn, hoe groter de kans is dat er iets fout gaat. Het zou heel mooi zijn om bijvoorbeeld de pagina-aanvragen van een live website naar een testomgeving door te sturen (met error logging ingeschakeld), om zodoende te ontdekken wat er daadwerkelijk fout gaat.

Een site-eigenaar ziet bij dit soort problemen alleen de melding dat er bij de laatst uitgevoerde code (in dit geval van plugin C) een fout optreedt, maar dat hoeft dus niet de oorzaak van het probleem te zijn.

In de meeste gevallen is het puur mensenwerk en is handmatig testen nodig om dit soort problemen op te sporen en op te lossen. Dit zou ook te automatiseren zijn met behulp van end-to-end testen, maar dit zien we in de WordPress wereld weinig voorkomen.

Zorg dat er testen beschikbaar zijn van gebruikte plugins

Voor ontwikkelaars en ontwikkelteams: accepteer pas code als er testen beschikbaar zijn. Zo zorg je ervoor dat er minder handmatig getest hoeft te worden en bespaar je veel tijd.

Als je een commerciële plugin of thema wilt kopen, vraag dan eens naar de teststrategie van deze software. Op die manier creëren we bewustzijn bij developers/development teams in de WordPress community om testen hoger op de agenda te krijgen, en daar profiteren we allemaal van.

Testen wordt vaak als onterecht als kostenpost gezien, terwijl het in werkelijkheid geld bespaart. De extra investering die nodig is om testen te schrijven, betaalt zich terug in significant minder bugreports en tijd die aan het oplossen van bugs besteed hoeft te worden. Daarnaast kan, door het geautomatiseerd testen van software, het maken van uitbreidingen en aanpassingen sneller worden gedaan, want de testen bevestigen dat bestaande functionaliteit blijft werken.

De rol van WordPress hosters en PHP 8.x

Voor de gemiddelde site-eigenaar, is een stuk begeleiding vanuit de hoster zeer gewenst. Denk hierbij aan:

• Klanten informeren over het feit dat WordPress core, plugins en/of thema’s (in sommige gevallen) niet helemaal PHP cross-version compatible zijn.
• Hoe moet je testen? Werk met een testomgeving!
• Hoe rapporteer je fouten?

Ook een webhoster heeft hier baat bij, omdat site-eigenaren bij problemen vaak bij de hoster om hulp vragen. In het geval van een switch naar PHP 8.0 of 8.1 is de site-eigenaar verantwoordelijk voor mogelijke problemen, en hoe meer info de eigenaar heeft om zich hier goed op voor te bereiden, des te beter.

PHP 8.0/8.1 beschikbaar maken als webhost is één ding, maar zorg daarbij wel voor bewustzijn bij klanten, zodat ze weten dat er misschien problemen naar boven kunnen komen. Het testen van je site in een testomgeving met een andere versie dan live is aan te raden. (PHP versies selecteren is bij bij Kinsta standaard beschikbaar).

Minimumversie van PHP voor WordPress

Iets meer dan 15% van alle websites gebruikt op dit moment PHP versie 7.0 of lager. Dit is te zien in de officiële WordPress statistieken. Ongeveer 83% van alle WordPress sites gebruikt op dit moment PHP versie 7.4 of lager. Let op, alles lager of gelijk aan versie 7.4 is op dit moment niet meer ondersteund door PHP. Het gebruiken van end-of-life versies van PHP kan resulteren in problemen, doordat er geen veiligheidsupdates meer uitgebracht worden.

Om problemen te voorkomen is het van belang dat WordPress site-eigenaren op de hoogte gebracht worden van de minimum versie van PHP waarmee hun site veilig kan draaien. De site-eigenaren kunnen op hun beurt zelf de PHP versie aanpassen (zoals bij Kinsta voor alle pakketten mogelijk is), of hun hoster vragen om de site van een nieuwere PHP versie te voorzien. In het uiterste geval, kan je overstappen naar een host die deze nieuwere versies ondersteunt.

Omdat WordPress een minimum versie van 7.4 hanteert, is er voor veel hosters en website eigenaren onvoldoende motivatie om te updaten. Zelfs niet als er bekend is dat deze PHP versie sinds november 2022 end-of-life is.

Mocht WordPress ooit wel de minimum PHP versie verhogen, dan kan dit voor veel sites betekenen dat deze niet meer bijgewerkt kunnen worden naar de nieuwste WordPress versie. Wel zullen er dan voor een geruime tijd voor die verouderde versies nog security updates uitkomen.

Samenvattend

Om over te stappen op PHP 8.x of hoger voor jouw website zijn er een aantal stappen die jij, of je development partner, moet uitvoeren. Belangrijke stappen zijn:

• • Statische analyse
  • Unittesten
  • Integratietesten
  • Handmatig testen

Let bij het overstappen naar PHP 8.0 (of 8.1) op dat echt alles goed getest is. Alleen zo kan je garanderen dat jouw site goed, snel en veilig draait op een nieuwere PHP versie.

Ik wil Juliette ontzettend bedanken voor haar medewerking aan dit artikel en voor al haar werk aan de genoemde tools.

De foto van Juliette is gemaakt door Jip Moors en wordt gebruikt met toestemming.