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 behandelen we deze vragen (en meer) en bekijken we wat er komt kijken bij een soepele overgang naar PHP 8.x voor je WordPress site, plugin of thema, inclusief een stappenplan.
We doen dit op basis van een interview dat we hielden met PHP expert Juliette Reinders Folmer. Zij wijdt het grootste deel van haar dagelijks leven aan programmeren en alles daaromheen, waarbij ze zich vooral richt op open-source 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 veranderingen raden we de onderstaande artikelen aan:
- De release notes van PHP 8.0 (In het Nederlands) en PHP 8.1.
- Migratiegids voor PHP 8.0 en PHP 8.1
- WordPress en PHP 8.0 en de huidige status
- Wat is er nieuw in PHP 8.0 en PHP 8.1
- Wat is nieuw in PHP 8.2 en PHP 8.2 migratiegids.
Na het lezen van deze artikelen ben je volledig op de hoogte van wat er veranderd is in PHP 8.x en wat je moet doen om je PHP projecten probleemloos te laten draaien.
Als je niet zeker weet wat de beste manier is om te beginnen, geen probleem. In het gesprek met Juliette hebben we dit uitgebreid besproken, en we zullen je in dit artikel zo volledig mogelijk uitleggen hoe je kunt overstappen op PHP 8.x.
Ook zullen we in informatieve kaders uitleggen hoe je verschillende handelingen kunt verrichten in MyKinsta, ons eigen controlepaneel voor al je WordPress sites, applicaties en databases.
Overstappen naar PHP 8.x: Zo begin je
Overstappen op PHP 8.x klinkt eenvoudig, en technisch gezien is het dat ook. Bij veel hosts kun je in het beheerderspaneel aangeven welke versie van PHP je voor je website wilt gebruiken. Bij Kinsta kun je met een enkele klik in het MyKinsta dashboard van PHP versie wisselen.
Maar voordat je dat doet, zijn er een paar dingen waar je zeker van moet zijn. Afhankelijk van je kennis- en ervaringsniveau raden we het volgende aan:
- Als je je eigen WordPress site hebt gebouwd met standaard thema’s en plugins, zonder veel kennis te hebben van PHP, huur dan een developers of bureau in om te onderzoeken of je site geschikt is om te draaien op PHP 8.x. Ben je op zoek naar een derde partij die je hiermee kan helpen? Kijk dan op onze Partners pagina waarop verschillende vertrouwde bedrijven staan die je kunnen helpen.
- Als je WordPress site is gebouwd door een externe partij, een developer of een bureau, neem dan contact met hen op om te vragen of je site op PHP 8.x kan draaien.
- Als je je WordPress site zelf hebt gebouwd – met bijvoorbeeld je eigen gebouwde thema of zelf ontwikkelde plugins – dan hebben we hieronder een stappenplan voor je.
Als je site in een van de eerste twee categorieën valt, nodigen we je zeker uit om de rest van het artikel door te lezen, maar we raden je niet aan om zelf te beginnen met het testen van je site op compatibiliteit met PHP 8.1. Laat dat over aan de professionals.
Wat je ook kiest, we raden je aan niet zomaar je live site over te zetten naar PHP 8 en “te kijken of het werkt.” Ben je nieuwsgierig naar hoe je site eruit zal zien, en kun je niet wachten om hem te zien draaien op PHP 8? Begin dan met testen binnen een testomgeving. Bij een goede host kun je gemakkelijk een testomgeving opzetten.
In de testomgeving kun je PHP 8.x activeren en kijken of deze update goed werkt met je site. Het is ook mogelijk om met een lokale kopie van je site te werken. Met onze gratis DevKinsta ontwikkeltool kun je gemakkelijk je site importeren vanuit het MyKinsta dashboard, waarna je de PHPversie kunt wijzigen in 8.0 of 8.1.
Als je in de staging-omgeving geen problemen ziet, hoeft dat niet te betekenen dat er eigenlijk geen problemen zijn. Het stappenplan hieronder vertelt je waarom.
PHP 8.x compatibiliteit testen: Het stappenplan
Testen: het sleutelwoord voor goede software. Ook voor WordPress websites en hun componenten, zoals thema’s, plugins en de WordPress kern, is testen het middel om ervoor te zorgen dat er geen dingen gebeuren die je niet wilt.
Een softwareontwikkelingsproject bestaat voor een groot deel uit testen. In dit artikel kijken we specifiek naar de tests die je kunnen helpen om de overgang naar PHP 8.x soepel te laten verlopen. In ons artikel over DevOps Tools vind je een sectie met een verzameling tools die je kunt gebruiken.
De volgende soorten tests worden in deze blogpost besproken:
Laten we de verschillende soorten tests die we kunnen uitvoeren nader bekijken.
Statische analyse (of statisch testen)
De eerste stap die je als PHP developer ntwikkelaar kunt nemen is het uitvoeren van een statische analyse van je code met verschillende tools. Statische analyse is het proces van het analyseren van software zonder de code uit te voeren. Met statische analyse is het mogelijk om fouten op te sporen, problemen met PHP 8.x compatibiliteit op te sporen, coderingsnormen af te dwingen (bijvoorbeeld de WordPress Coding Standards), en zelfs het aanpassen en opschonen van de code is mogelijk.
Tools voor statische analyse
Je kunt een statische analyse uitvoeren met verschillende tools, zoals:
Op het moment van schrijven worden niet alle PHP 8.1 checks ondersteund in de nieuwste PHPCompatibility release. PHP 8.1 checks kunnen in de ontwikkelingsrelease zitten, dus zorg ervoor dat je die (voorlopig) gebruikt als je PHPCompatibility gebruikt om je project te analyseren en te zien welke fouten/aanbevelingen er zijn.
PHP 8.1 checks worden binnenkort uitgebracht in een nieuwe major versie. Als je hiervan op de hoogte wilt blijven, en je hebt een GitHub account, open dan de GitHub repository van PHPCompatibility en navigeer naar Watch -> Custom -> Releases, waar je kunt kiezen voor een melding als er een nieuwe versie wordt uitgebracht.
PHPCompatibility, dat alleen compatibiliteit test voor een bepaalde versie (of reeks versies) van PHP, is eenvoudig in te stellen. Je krijgt de beste resultaten als je binnen PHPCompatibility een testVersion uitvoert – bijvoorbeeld 8.0+ (8.0 en hoger).
Je moet letten op afgeschreven of verwijderde functies, gewijzigde standaardwaarden van functieparameters, of je concat moet gebruiken zonder haakjes, of je match moet gebruiken als functienaam (want die is gereserveerd sinds PHP 8.0), enz.
Psalm en PHPStan zijn goede toevoegingen en kunnen je helpen door extra controles uit te voeren met betrekking tot variable types. Het nadeel van deze tools is dat het veel configuratie vergt om rapporten te krijgen over PHP 8.0 en 8.1. Zelfs als ze succesvol zijn, kun je veel false positives verwachten. False positives zijn meldingen die ten onrechte worden gegeven, veroorzaakt door de beperkingen van statische analyse.
Er is gedegen kennis nodig om de resultaten van deze twee tools goed te interpreteren, maar die kennis kan je helpen om extra incompatibiliteiten op te sporen die PHPCompatibility niet kan vinden. Bekijk de documentatie voor Psalm en PHPStan als je er meer over wilt weten.
Samenvatting:
- Voer een statische analyse uit met PHPCompatibility, Psalm, PHPStan
- Los alle legitieme problemen op
Unittesten
De volgende stap in het proces is unittesten. Unittesten is een methode om stukken code afzonderlijk te testen. Bij unittesten worden voor elke eenheid specifieke gerichte tests ontwikkeld. Daarbij worden verschillende scenario’s doorlopen. Bij voorkeur wordt elk scenario apart van de andere getest, zodat de tests onafhankelijk van elkaar zijn.
Het hebben van unittests alleen is natuurlijk niet voldoende. Ze moeten ook uitgevoerd worden. Unittesten kunnen het beste worden geautomatiseerd met behulp van CI (continuous integration) tooling zoals Jenkins, GitHub Actions, of Travis.
Ondersteuning van meerdere versies van PHP
Als je als pluginbouwer meerdere PHP versies wilt ondersteunen, zorg er dan voor dat de tests in CI worden uitgevoerd tegen alle PHP versies die je ondersteunt.
Natuurlijk kun je ook alleen nieuwere versies ondersteunen, de keuze is geheel aan jou.
Nu je de tests hebt draaien, is de volgende stap om ervoor te zorgen dat de problemen die in de tests zijn gevonden worden opgelost.
Code coverage
Het uitvoeren van deze tests is de meest betrouwbare manier om cross-versie incompatibiliteiten te vinden.
Let daarbij op de code coverage van je tests:
- Stel, je hebt een functie A en hebt daar een test voor geschreven, en functie A callt functies B, C en D 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 tijdens het testen ook de functies B, C en D callen. Voor functies B, C, en D test je dan meestal alleen het “happy path” – de situatie waarin alles goed gaat – en dus zijn die functies ook nog niet volledig getest, hoewel (een deel van) de code in die functies wordt uitgevoerd tijdens het testen van functie A.
- Geef voor elk van je tests aan welke code specifiek wordt getest. Dit doe je door elke test een @covers te geven. Op die manier worden B, C en D niet “meegeteld” in de berekening van de codedekking, waardoor je kunt zien welk deel van je code door tests wordt gedekt.
Vaak schrijven en testen developers – soms zelfs onbewust – voor het “happy path.” In deze gevallen is het ook nodig om te testen wat er gebeurt als onverwachte gegevens aan een functie worden doorgegeven. Testen met alleen verwachte waarden/types is niet voldoende.
Het tweede deel van bovenstaand citaat wordt vaak vergeten, terwijl het misschien nog wel belangrijker is dan het eerste deel. Wat gebeurt er als je een verkeerd type doorgeeft? Krijg je dan een foutmelding? Of wordt de variabele gecast met de functie en gaat hij gewoon door? En wat als er een onverwachte waarde aan de functie wordt doorgegeven?
Zorg ervoor dat je je functies test met onverwachte variabelen, typen en waarden. Alleen dan kun je vertrouwen op je tests om problemen te vinden die een nieuwe PHP versie kan veroorzaken.
PHP wordt strenger
PHP wordt steeds preciezer (strikter) in hoe het omgaat met “types” voor PHP’s eigen functies, en met zaken als dynamische properties. Deze veranderingen zijn over het algemeen bedoeld om developers te helpen foutloze code te leveren (nou ja, code met minder fouten). Maar dit kan een behoorlijke upgrade-hindernis vormen voor reeds bestaande code die is geschreven op basis van de “oude” grondbeginselen van PHP.
Door deze drang naar meer nuttige 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 werkte in PHP 5.6 voor PHP 7.0 kostte in de meeste gevallen slechts een fractie van de tijd vergeleken met het upgraden van code om die geschikt te maken voor PHP 8.1. En dat ondanks het feit dat PHP 7.0 een “major” release was, terwijl PHP 8.1 een “minor” is.
In veel gevallen is testen nog steeds de enige betrouwbare manier om te bepalen wat er gewijzigd moet worden om een nieuwe versie te ondersteunen.
Unittesten is mogelijk met verschillende tools, waaronder:
Veel van deze tools zijn gebouwd op, of in combinatie met, PHPUnit.
Uiteindelijk maakt het niet uit welke hulpmiddelen je gebruikt. Het belangrijkste is dat je test, en de tests op nieuwe PHP versies laat draaien. Deze stap kan soms erg lastig zijn, maar gelukkig zijn daar, zoals eerder gezegd, tools voor, zoals PHPUnit Polyfills.
Integratietesten
Integratietesten is de volgende stap die we gaan uitvoeren, na statische analyse en unittesten. Bij een integratietest worden levensechte situaties getest in een grotere context dan alleen een “code-unit” Hieronder vallen het testen met een actieve (test)database of het testen met een externe API, om maar twee voorbeelden te noemen.
Als je dus de code van een plugin of thema test in de context van WordPress en een echte versie gebruikt, zijn dat per definitie integratietesten.
WP Test Utils (opnieuw geschreven door Juliette en gesponsord door Yoast) is een uitstekende tool voor integratietesten. WP Test Utils biedt tooling om integratie- en unittests te schrijven, waarbij WordPress wordt “nagemaakt” met behulp van Brainmonkey en Mockery, waarbij veelgebruikte WordPress features worden “nagemaakt”, zodat je je eigen code test en niet de WordPress code.
Integratietesten met WordPress is een lastiger verhaal omdat het gaat om integratie met WordPress en de testsuite van WordPress. Afhankelijk van welke versies van WordPress een plugin of thema ondersteunt, moet je overwegen welke PHPUnit versies door WordPress zelf worden ondersteund om de tests op verschillende PHP versies uit te voeren.
Bijvoorbeeld, WordPress 5.6 t/m 5.8 gebruikt PHPUnit 5 t/m 7 voor het testen van PHP 5.6 t/m PHP 8.0, maar vanaf WordPress 5.9 gebruikt WordPress zelf ook PHPUnit Polyfills voor bredere ondersteuning. WP Test Utils fungeert als een brug om al deze verschillen te overbruggen.
Wil je meer weten over hoe je integratietests kunt uitvoeren tegen meerdere verschillende versies van WordPress, waaronder WordPress 5.9 en hoger? Lees er dan over op de website van WordPress.
Handmatig testen
Nu je unittesten en integratietesten hebt doorlopen en alle problemen die je hebt gevonden hebt opgelost, is het tijd om handmatige testen uit te voeren. Je site draait, en je eigen code werkt, maar je gebruikt ook plugins A, B, en C. Weet je of die plugins compatibel zijn?
Controleer dit bijvoorbeeld bij de auteurs van de plugin en kijk of zij aangeven dat hij compatibel is met PHP 8.x. De vraag is dan natuurlijk hoe de plugin is getest. Vaak is het antwoord hier: in isolatie. De functies van de plugin zijn meestal getest in combinatie met alleen WordPress, zonder andere actieve plugins. En zelfs als binnen deze tests andere plugins werden gebruikt, is de kans groot dat niet alle door jou gebruikte plugins deel uitmaakten van de tests, dus neem zo’n compatibiliteitsverklaring met een korreltje zout.
Neem bijvoorbeeld een WordPress site met 3 plugins (A, B en C). Het is mogelijk dat plugin B via een filter een verkeerd variabelentype teruggeeft, waar plugin C, die hetzelfde filter gebruikt, mee wil werken. Dit kan dan een fatale fout veroorzaken omdat het type niet meer is wat verwacht wordt. Plugin C wordt dan gezien als de boosdoener van de foutmelding, ook al is plugin B de echte dader.
Plugin interoperabiliteit-incompatibiliteiten zijn onmogelijk te ontdekken bij geïsoleerd testen. Hoe meer actieve plugins, hoe groter de kans dat er iets fout gaat. Het zou bijvoorbeeld heel nuttig zijn om paginaverzoeken van een live website door te geven aan een testomgeving (met error logging ingeschakeld) om te ontdekken wat er eigenlijk fout gaat.
Bij dit soort problemen zal een site-eigenaar meestal alleen een bericht zien dat er een fout was met de laatst uitgevoerde code (in dit geval van plugin C), ook al is plugin C niet noodzakelijkerwijs de oorzaak van het probleem.
In de meeste gevallen komt er veel handmatig, menselijk werk bij kijken, en is er een gezonde hoeveelheid elleboogvet nodig om deze problemen op te sporen en op te lossen. Dit zou geautomatiseerd kunnen worden met behulp van end-to-end testen, maar we zien dit niet veel gebeuren in WordPress.
Testbeschikbaarheid voor gebruikte plugins
Voor ontwikkelaars en ontwikkelteams: Accepteer code alleen als er tests beschikbaar zijn. Zo zorg je ervoor dat er minder handmatig getest hoeft te worden, wat veel tijd bespaart.
Trek de teststrategie ervan in twijfel als je een commerciële plugin of thema wilt kopen. Op die manier creëren we collectief bewustzijn bij developers/devteams in de WordPress gemeenschap om testen hoger op de agenda te krijgen, en daar profiteren we allemaal van.
Testen wordt vaak – onterecht – gezien als een kostenpost, terwijl het in werkelijkheid geld bespaart. De extra investering die nodig is om tests te schrijven betaalt zich terug in de vorm van aanzienlijk minder foutmeldingen en minder tijd die nodig is om fouten te repareren. Bovendien kunnen met geautomatiseerde softwaretests uitbreidingen en wijzigingen sneller worden uitgevoerd, omdat de tests snel kunnen bevestigen dat de bestaande functionaliteit blijft werken.
De rol van WordPress Hosts en PHP 8.x
Voor de gemiddelde site-eigenaar is goede begeleiding vanuit de host zeer wenselijk. Overweeg het volgende:
- Documentatie en updates voor klanten dat WordPress Core, plugins en/of thema’s (in sommige gevallen) niet PHP cross-version compatibel zijn
- Opties voor testen (zoals het werken met een testomgeving)
- Methoden voor rapporteren van fouten en contact met ondersteuning
Dit komt ook een webhost ten goede, want site-eigenaren nemen vaak contact op met de host voor hulp bij problemen. In het geval van een overstap naar PHP 8.0, 8.1, of 8.2 is de site-eigenaar verantwoordelijk voor mogelijke problemen, en hoe meer informatie de eigenaar heeft om zich goed op de overstap voor te bereiden, hoe beter.
Als webhost PHP 8.1 of 8.2 beschikbaar maken voor klanten is één ding, maar daarbij moeten ze ervoor zorgen dat ze bewustzijn creëren bij klanten, zodat ze weten dat er problemen kunnen opduiken. Het testen van je site in een testomgeving met een andere versie dan live wordt aanbevolen. (Het selecteren van PHP versies is standaard beschikbaar bij Kinsta.)
Minimum PHP versie voor WordPress
Meer dan 15% van alle websites gebruikt momenteel PHP versie 7.0 of lager. Dit is te zien in de officiële statistieken van WordPress. Ongeveer 83% van alle WordPress sites gebruikt momenteel PHP versie 7.4 of lager. Let op dat alles lager of gelijk aan versie 8.0 momenteel niet meer ondersteund wordt door PHP. Het gebruik van end-of-life versies van PHP kan leiden tot problemen omdat er geen beveiligingsupdates meer worden uitgebracht.
Om problemen te voorkomen is het belangrijk dat eigenaren van WordPress sites op de hoogte zijn van de minimale PHP versie waarmee hun site veilig kan draaien. Van hun kant kunnen site-eigenaren zelf de PHP versie aanpassen (mogelijk bij Kinsta voor alle pakketten) of hun host vragen de site bij te werken naar een nieuwere PHP versie. In extreme gevallen kun je overstappen naar een host die deze nieuwere versies ondersteunt.
Omdat WordPress slechts een minimale versie van 7.4 vereist, is er voor veel hosts en website-eigenaren onvoldoende motivatie om hun sites bij te werken. En dat terwijl PHP 7.4 in november 2022 zijn end-of-life heeft bereikt.
Als WordPress ooit toch de minimale PHP versie verhoogt, kan dat betekenen dat veel sites niet meer compatibel zijn met een update naar de nieuwste WordPress versie. Voor die verouderde versies zullen echter nog geruime tijd beveiligingsupdates worden uitgebracht.
Samenvatting
Om voor je website over te stappen op PHP 8.0 of hoger zijn er verschillende stappen die jij, of je developer, moet uitvoeren. Belangrijke stappen zijn onder andere:
- Statische analyse
- Unittesten
- Integratietesten
- Handmatig testen
Als je overstapt op PHP 8.x, zorg er dan voor dat alles goed getest is. Dit is de enige manier om te garanderen dat je site goed, snel en veilig draait op een nieuwere PHP-versie.
We bedanken Juliette enorm voor haar medewerking aan dit artikel en voor al haar werk aan de genoemde tools!
Foto van Juliette, gemaakt door Jip Moors en gebruikt met toestemming.
Laat een reactie achter