WordPress ja PHP 8.x: Tyypit, virheet ja backward compatibility

WordPress ja PHP 8.x kokonaisuutena

PHP 8.x -siirtymä on WordPress-ekosysteemissä yksi merkittävimmistä teknisistä murroksista vuosiin. Kyse ei ole vain suorituskyvystä tai uusista kieliominaisuuksista, vaan ajattelutavan muutoksesta: löyhästi tulkitsevasta PHP:stä kohti tiukempaa, ennustettavampaa ja virheherkempää ympäristöä.

WordPress on historiallisesti nojannut PHP:n joustavuuteen. PHP 8.x puolestaan suosii eksplisiittisyyttä. Tässä jännitteessä syntyvät sekä ongelmat että mahdollisuudet.

PHP 8.x ei ole vain nopeampi PHP

Muuttunut virhemalli

Yksi suurimmista muutoksista PHP 8:ssa on virheiden luonne. Monet asiat, jotka aiemmin olivat:

• notice

• warning

• hiljaisesti ohitettuja

ovat nyt TypeError- tai Fatal error -tilanteita.

WordPressissä tämä näkyy erityisesti custom-koodissa ja vanhemmissa lisäosissa, jotka nojaavat PHP:n anteeksiantavuuteen.

“Toimi ennen” ei ole tekninen argumentti

PHP 7.x saattoi hyväksyä epäselviä tilanteita:

• väärä tyyppi funktiolle

• null-arvon käyttö merkkijonona

• puuttuva array-indeksi

PHP 8.x ei enää katso näitä läpi sormien. Tämä ei ole regressio, vaan tietoinen suunnitteluratkaisu.

Tyypit: vapaaehtoisesta kurinalaiseksi

Tyypityksen merkityksen kasvu

PHP 8.x ei pakota käyttämään tyyppejä, mutta se rankasee tyypittömyydestä enemmän kuin ennen. Erityisesti:

• funktioparametrit

• paluuarvot

• union types

• nullable-tyypit

tekevät koodista joko erittäin selkeää tai erittäin hauraasti rikkoutuvaa.

WordPress-core on pitkälti tyypitöntä historiallisista syistä. Custom-koodissa tyypitys on kuitenkin kaksiteräinen miekka.

Tyypit ja WordPress-hookit

Hookit välittävät dataa, jonka tyyppi ei ole aina taattu. Jos custom-koodi:

• olettaa tietyn tyypin

• ei validoi syötettä

• käyttää tiukkaa tyypitystä suoraan hookissa

PHP 8.x paljastaa tämän välittömästi virheenä.

Hyvä malli on:

• validoida data hookissa

• normalisoida se

• käyttää tyyppejä vasta omassa sisäisessä logiikassa

Yleisimmät PHP 8.x -rikkojat WordPressissä

Null-arvot

PHP 8:ssa:

• strlen(null) on virhe

• strpos(null, 'x') on virhe

• array_key_exists() käyttäytyy eri tavalla

WordPressissä null-arvot ovat yleisiä, erityisesti:

• meta-arvoissa

• REST API -datassa

• optioissa

Custom-koodi, joka ei tarkista näitä, rikkoutuu helposti.

Array- ja objektikäyttö

PHP 8 on tiukempi tilanteissa, joissa:

• arraya käytetään objektina

• objektia käsitellään arrayna

• puuttuvaa indeksiä käytetään suoraan

WordPress palauttaa usein dynaamisia rakenteita. Ne eivät ole koskaan “varmoja” ilman tarkistuksia.

Funktioiden allekirjoitukset

PHP 8 vaatii:

• yhteensopivat parameterit

• yhteensopivat paluuarvot

Jos custom-luokka ylikirjoittaa core-luokan metodin väärällä allekirjoituksella, tuloksena on fatal error. Tämä koskee erityisesti:

• REST controller -luokkia

• WooCommerce-laajennuksia

• periytyviä abstrakteja luokkia

Backward compatibility WordPressissä

WordPressin filosofia

WordPress pyrkii säilyttämään taaksepäin yhteensopivuuden, mutta:

• PHP-versio ei ole WordPressin hallinnassa

• hosting-ympäristöt päivittyvät itsenäisesti

WordPress voi tukea PHP 8.x:ää, mutta se ei voi korjata huonosti kirjoitettua custom-koodia.

“Yhteensopiva” ei tarkoita “turvallinen”

Lisäosa tai teema voi olla:

• teknisesti yhteensopiva PHP 8:n kanssa

• mutta silti täynnä deprecation-varoituksia

• tai reunatapauksia, jotka kaatuvat kuormassa

PHP 8-yhteensopivuus ei ole binäärinen tila, vaan jatkumo.

Deprecation-varoitukset ovat ennakkovaroitus

Älä sammuta, kuuntele

Moni ratkaisee PHP 8 -ongelmat sammuttamalla varoitukset. Tämä on lyhytnäköistä. Deprecation-viestit kertovat:

• mikä koodi on vanhentumassa

• mikä rikkoutuu tulevassa versiossa

WordPress-kehityksessä nämä ovat arvokasta signaalia, ei häiriötä.

Hiljainen tekninen velka

Jos PHP 8 -varoituksia ei korjata:

• seuraava PHP-versio rikkoo koodin

• korjaus on kiireinen ja kallis

• regressioriski kasvaa

Varoitukset ovat aikaa ostava mekanismi.

PHP 8.x ja suorituskyky WordPressissä

Nopeampi, mutta vain oikein käytettynä

PHP 8.x tuo:

• JIT-mahdollisuuden

• parannuksia moottoriin

• tehokkaampaa muistinkäyttöä

Mutta:

• WordPress ei automaattisesti nopeudu

• huono koodi pysyy huonona

• virheellinen koodi kaatuu nopeammin

Suurin hyöty tulee puhdistetusta custom-koodista, ei PHP-version vaihdosta yksinään.

Testaus on pakollinen, ei suositus

Miksi tuotantopäivitys on vaarallinen

PHP-version päivitys:

• vaikuttaa kaikkeen koodiin

• ei koske vain corea

• ei näy aina heti

Ilman staging-ympäristöä PHP 8 -siirtymä on arpapeliä.

Mitä pitää testata

PHP 8.x -siirtymässä testataan erityisesti:

• admin-puoli

• cron-tehtävät

• integraatiot

• REST API -endpointit

• virhepolut

“Etusivu latautuu” ei riitä.

Miten kirjoittaa PHP 8 -kestävää WordPress-koodia

Hyvä PHP 8 -yhteensopiva custom-koodi:

• validoi kaiken ulkoa tulevan datan

• ei oleta tyyppiä

• käyttää tyyppejä vasta sisäisesti

• ei nojaa sivuvaikutuksiin

• käsittelee null-arvot eksplisiittisesti

Tämä ei ole PHP 8 -spesifiä. PHP 8 vain pakottaa siihen.

Milloin PHP 8.x on riski WordPressissä

PHP 8.x on riski, jos:

• sivustolla on paljon vanhaa custom-koodia

• lisäosia ei ylläpidetä aktiivisesti

• virhelokit ovat tyhjiä tai pois päältä

• päivityksiä ei testata

Tällöin ongelma ei ole PHP 8, vaan kehitysprosessi.

Lopuksi: PHP 8.x tekee ongelmat näkyviksi

PHP 8.x ei riko hyvin kirjoitettua WordPress-koodia. Se rikkoo oletuksia, joita ei koskaan olisi pitänyt olla olemassa.

WordPress-kehityksessä PHP 8 on terveellinen pakote:

• kohti parempaa koodia

• kohti ennustettavampaa järjestelmää

• kohti hallittavampaa teknistä velkaa

Kun PHP 8.x otetaan käyttöön tietoisesti ja testaten, se ei ole uhka. Se on askel kohti ammattimaisempaa WordPress-arkkitehtuuria.