WordPress Core -päivitysten vaikutus custom-koodiin
WordPressin ydin kehittyy jatkuvasti. Jokainen core-päivitys tuo mukanaan bugikorjauksia, tietoturvaparannuksia ja uusia ominaisuuksia, mutta samalla se muuttaa ympäristöä, jossa custom-koodi elää. Useimmat päivitykset ovat taaksepäin yhteensopivia, mutta se ei tarkoita, etteikö custom-koodi voisi rikkoutua, hidastua tai alkaa käyttäytyä odottamattomasti.
Core-päivitysten vaikutus ei yleensä ole dramaattinen “sivusto kaatui” -hetki. Useammin kyse on hienovaraisista muutoksista, jotka paljastuvat vasta ajan kanssa.
Miksi custom-koodi on herkin osa päivityksissä
Custom-koodi elää WordPressin oletusten ulkopuolella. Se:
-
käyttää hookeja, joiden ajoitus voi muuttua
-
nojaa funktioihin, joiden sisäinen toiminta kehittyy
-
olettaa tiettyjä tietorakenteita tai palautusarvoja
WordPress core ei tunne sinun koodiasi. Se ei voi taata, että kaikki epäviralliset käyttötavat pysyvät ennallaan.
Yleisin väärinkäsitys: “WordPress ei riko taaksepäin yhteensopivuutta”
WordPress pyrkii säilyttämään taaksepäin yhteensopivuuden, mutta se ei lupaa, että:
-
sisäinen toiminta pysyy samana
-
suorituskyky pysyy samana
-
epäviralliset hook-ketjut pysyvät identtisinä
Useimmat regressiot custom-koodissa syntyvät siitä, että koodi nojaa implisiittisiin oletuksiin, ei dokumentoituihin sopimuksiin.
Hookit ja niiden ajoitus
Hook on sopimus – mutta vain osittain
Action- ja filter-hookit ovat WordPressin laajennettavuuden perusta. Core-päivityksissä:
-
uusia hookeja lisätään
-
vanhoja saatetaan siirtää
-
hookin ajoitus suhteessa muihin vaiheisiin voi muuttua
Jos custom-koodi olettaa, että tietty data on aina saatavilla tietyssä hookissa, päivitys voi rikkoa tämän oletuksen.
Tyypillinen ongelmatilanne
Custom-koodi käyttää esimerkiksi:
-
liian aikaista hookia, jossa data ei ole vielä valmis
-
liian myöhäistä hookia, jossa core on jo tehnyt päätöksiä
Core-päivitys ei riko hookia, mutta muuttaa sen kontekstia.
Funktiot, jotka eivät ole niin vakaita kuin luullaan
Julkinen funktio ei tarkoita muuttumatonta
WordPressin funktiot ovat pääosin julkisia, mutta niiden:
-
sisäinen toteutus
-
suorituskyky
-
sivuvaikutukset
voivat muuttua. Jos custom-koodi:
-
kutsuu funktiota poikkeavalla tavalla
-
nojaa sivuvaikutuksiin
-
käyttää funktiota väärässä kontekstissa
päivitys voi muuttaa lopputulosta.
Sisäisten funktioiden käyttö on riski
Jos custom-koodi käyttää:
-
funktioita, joita ei ole dokumentoitu
-
core-luokkien sisäisiä metodeja
-
globaaleja muuttujia
se on aina altis core-muutoksille. Nämä eivät ole vakaita rajapintoja.
Tietorakenteiden hienovaraiset muutokset
Taulukot, objektit ja REST-vastaukset
Core-päivitys voi:
-
lisätä uusia kenttiä
-
muuttaa oletusarvoja
-
muuttaa kenttien järjestystä
Jos custom-koodi:
-
olettaa tietyn rakenteen
-
ei tarkista kenttien olemassaoloa
-
käyttää tiukkaa vertailua
se voi alkaa toimia väärin ilman näkyvää virhettä.
REST API ja Gutenberg korostavat tätä
Moderni WordPress käyttää yhä enemmän JSON-rakenteita. Custom-koodi, joka:
-
parsii vastauksia käsin
-
olettaa tietyn muodon
on herkkä muutoksille, vaikka API-versio ei vaihtuisikaan.
Suorituskykyvaikutukset custom-koodiin
Sama koodi, eri kustannus
Core-päivitys voi tehdä:
-
yhdestä hookista raskaamman
-
tietystä funktiosta kalliimman
-
yhdestä kyselystä useamman kyselyn
Custom-koodi, joka aiemmin oli “riittävän kevyt”, voi päivityksen jälkeen muuttua pullonkaulaksi.
Regressiot eivät näy heti
Usein käy niin, että:
-
sivusto toimii edelleen
-
kuormassa vasteajat kasvavat
-
PHP-prosessit kuormittuvat
Custom-koodi ei ole rikki, mutta se ei enää skaalaudu samalla tavalla.
Deprecated-merkinnät ja hiljaiset varoitukset
Deprecation ei riko heti
WordPress merkitsee vanhentuvia toimintoja deprecated-merkinnöillä. Nämä:
-
eivät riko koodia heti
-
näkyvät vain debug-tilassa
-
ovat ennakkovaroitus
Custom-koodi, joka sivuuttaa nämä varoitukset, altistuu rikkoutumiselle tulevissa päivityksissä.
Hiljainen tekninen velka
Jos deprecated-varoituksia ei korjata:
-
ongelma siirtyy eteenpäin
-
korjauskynnys kasvaa
-
tuleva core-päivitys muuttuu riskiksi
Deprecation on mahdollisuus, ei häiriö.
Milloin core-päivitys rikkoo custom-koodin pahiten
Suurimmat riskit syntyvät, kun custom-koodi:
-
käyttää globaaleja muuttujia
-
manipuloi query-objekteja suoraan
-
muokkaa core-käyttäytymistä laajasti
-
yrittää “ohittaa” WordPressin logiikan
Mitä syvemmälle coreen mennään, sitä suurempi riski.
Miten custom-koodi kannattaa suojata core-päivityksiltä
Pysy virallisissa rajapinnoissa
Käytä:
-
dokumentoituja hookeja
-
virallisia API-funktioita
-
tuettuja datamalleja
Jos jotain ei ole dokumentoitu, se ei ole sopimus.
Ole defensiivinen
Custom-koodi kestää muutoksia paremmin, kun se:
-
tarkistaa datan olemassaolon
-
ei oleta liikaa kontekstista
-
sietää ylimääräisiä kenttiä
Defensiivinen koodi ei ole ylivarovaista, se on realistista.
Testaa core-päivitykset erikseen
Core-päivitystä ei pidä niputtaa:
-
teemapäivityksiin
-
lisäosapäivityksiin
-
suuriin koodimuutoksiin
Kun muutos on yksittäinen, vaikutus on ymmärrettävissä.
Core-päivitykset eivät ole vihollinen
On helppo ajatella, että core-päivitykset “rikkoivat” custom-koodin. Useimmiten ne vain paljastavat:
-
piilevän oletuksen
-
teknisen velan
-
liian tiukan sidoksen coreen
Hyvin kirjoitettu custom-koodi ei pelkää core-päivityksiä. Se elää niiden mukana.
Lopuksi: custom-koodi on vastuu, ei vain ratkaisu
WordPress Core kehittyy riippumatta siitä, mitä custom-koodia sivustolla on. Kun päätät kirjoittaa omaa koodia, päätät samalla ottaa vastuun sen elinkaaren hallinnasta.
Core-päivitysten vaikutus custom-koodiin ei ole sattumaa. Se on seurausta siitä, miten tiukasti koodi on sidottu WordPressin sisäiseen toimintaan.
Kun rajapinnat valitaan huolellisesti, oletukset minimoidaan ja muutoksia seurataan, core-päivitykset eivät ole uhka. Ne ovat vain osa normaalia kehityksen rytmiä.
