WordPress näyttää ulospäin yksinkertaiselta: selain pyytää URL-osoitetta ja sivu ilmestyy ruudulle. Kulissien takana tapahtuu kuitenkin tarkasti määritelty ja vuosien aikana hioutunut bootstrap-prosessi, joka muuttaa HTTP-pyynnön tietokantakyselyiksi, PHP-olioiksi ja lopulta HTML:ksi. Tämä prosessi on WordPressin todellinen selkäranka.
Bootstrap-prosessin ymmärtäminen erottaa WordPressin käyttäjän WordPress-kehittäjästä. Kun tiedät, missä vaiheessa mikäkin tapahtuu, osaat sijoittaa koodisi oikein, optimoida suorituskykyä ja välttää yleisiä virheitä, kuten väärässä kohdassa ajettuja kyselyitä tai tarpeettomia hookeja.
Tässä artikkelissa käydään teknisesti ja järjestelmällisesti läpi WordPressin bootstrap-prosessi index.php:stä aina teemaan ja template-renderöintiin asti.
Kaikki alkaa index.php:stä
Jokainen WordPress-pyyntö alkaa yhdestä tiedostosta: index.php. Riippumatta siitä, pyydetäänkö etusivua, yksittäistä artikkelia tai REST API -endpointia, WordPressin front controller -malli ohjaa pyynnön index.php:hen.
index.php on tarkoituksella äärimmäisen ohut. Sen tehtävä ei ole tehdä päätöksiä tai suorittaa logiikkaa, vaan käynnistää WordPressin ydin.
Tämä on tietoinen arkkitehtuurivalinta. Kun kaikki kulkee yhden sisääntulopisteen kautta, WordPress voi hallita elinkaarta ennustettavasti.
wp-blog-header.php ja siirtymä ytimeen
index.php lataa wp-blog-header.php-tiedoston. Tässä vaiheessa WordPress siirtyy “ulkomaailmasta” omaan sisäiseen koneistoonsa.
wp-blog-header.php vastaa kahdesta asiasta:
– WordPress-ympäristön lataamisesta
– Varsinaisen pääkyselyn käynnistämisestä
Tämä tiedosto yhdistää bootstrapin ja sisällön hakemisen toisiinsa.
wp-load.php ja ympäristön määrittely
Seuraava kriittinen askel on wp-load.php. Tämä tiedosto etsii wp-config.php:n ja määrittää WordPressin perusympäristön.
wp-load.php:
– määrittää ABSPATH-polun
– lataa wp-config.php:n
– varmistaa, että WordPress tietää missä se on ja miten se toimii
Tässä vaiheessa ei vielä ole tietokantayhteyttä, käyttäjiä tai teemoja. Vain perusympäristö rakennetaan.
wp-config.php: konfiguraation sydän
wp-config.php ei ole osa WordPress Corea, mutta se on bootstrap-prosessin kriittisin yksittäinen tiedosto. Se määrittää:
– tietokantayhteyden
– suolat ja avaimet
– debug-asetukset
– ympäristökohtaiset asetukset
Bootstrap-prosessissa wp-config.php ajetaan hyvin aikaisessa vaiheessa. Tämän jälkeen WordPress tietää, mihin tietokantaan se yhdistyy ja millä ehdoilla.
Tässä vaiheessa ei silti ole vielä ladattu mitään “WordPress-toiminnallisuutta”.
wp-settings.php: todellinen bootstrap alkaa
wp-settings.php on WordPressin bootstrap-prosessin ydin. Tämä tiedosto vastaa lähes kaiken lataamisesta oikeassa järjestyksessä.
wp-settings.php:
– lataa PHP-ytimen funktiot
– alustaa globaalit muuttujat
– yhdistää tietokantaan
– lataa aktiiviset lisäosat
– alustaa käyttäjäjärjestelmän
– rekisteröi hook-järjestelmän
Jos WordPress olisi käyttöjärjestelmä, wp-settings.php olisi sen kernel.
PHP-funktiot ja Core API:t
Bootstrapin alkuvaiheessa WordPress lataa suuren määrän core-funktioita. Näihin kuuluvat esimerkiksi:
– plugin API
– option API
– user API
– post API
– taxonomy API
Näitä ei vielä käytetä aktiivisesti, mutta ne ovat saatavilla. Tämä on tärkeää, koska lisäosat ja teemat voivat luottaa siihen, että nämä funktiot ovat olemassa, kun niiden oma koodi ajetaan.
Must-use plugins ja niiden paikka
Must-use plugins eli mu-plugins ladataan hyvin aikaisessa vaiheessa. Ne ajetaan ennen tavallisia lisäosia ja ennen teemoja.
Tämä tekee niistä ihanteellisen paikan:
– kriittiselle konfiguraatiolle
– välimuistille
– tietoturvalle
– ympäristökohtaiselle logiikalle
Bootstrapin näkökulmasta mu-plugins ovat ensimmäinen paikka, jossa kehittäjä voi vaikuttaa WordPressin toimintaan.
Tavalliset lisäosat bootstrapissa
Seuraavaksi WordPress lataa aktiiviset lisäosat. Tässä vaiheessa:
– kaikki core API:t ovat käytettävissä
– tietokantayhteys toimii
– hook-järjestelmä on aktiivinen
Lisäosat eivät vielä tiedä, millainen pyyntö on kyseessä. Ei ole vielä päätetty, onko kyseessä etusivu, artikkeli vai arkisto.
Tämä on tärkeää ymmärtää, koska liian aikaisin tehty logiikka voi johtaa virheisiin tai suorituskykyongelmiin.
Teeman alustaminen
Kun lisäosat on ladattu, WordPress siirtyy teemaan. Tässä vaiheessa ladataan:
– aktiivinen teema
– mahdollinen parent-teema
– functions.php
functions.php ei ole template, vaan osa bootstrapia. Se ajetaan jokaisella pyynnöllä, myös adminissa ja API-kutsuissa.
Tämä tekee functions.php:stä tehokkaan mutta myös vaarallisen paikan liialliselle logiikalle.
Hookit bootstrapin aikana
Bootstrap-prosessin aikana ajetaan useita keskeisiä hookeja. Näistä tärkeimpiä ovat:
– plugins_loaded
– after_setup_theme
– init
init on usein väärin ymmärretty. Se ei tarkoita, että WordPress olisi “valmis”, vaan että perusrakenteet ovat olemassa. Query ei ole vielä ajettu.
Hookien oikea käyttö vaatii ymmärrystä siitä, missä kohtaa bootstrapia ollaan.
Rewrite-säännöt ja URL-tulkinta
Kun ympäristö on ladattu, WordPress tulkitsee URL:n. Rewrite-säännöt muunnetaan query var -parametreiksi.
Tässä vaiheessa päätetään:
– mikä post_type on kyseessä
– mikä slug tai ID haetaan
– onko kyseessä arkisto, haku tai yksittäinen sisältö
Tämä tapahtuu ennen varsinaista tietokantakyselyä.
WP_Query ja pääkysely
Seuraavaksi WordPress luo pääkyselyn. WP_Query rakentaa SQL-kyselyn query var -parametrien perusteella ja hakee datan tietokannasta.
Tämä on ensimmäinen hetki, jolloin sisältö oikeasti haetaan. Kaikki aiempi on ollut valmistelua.
Pääkyselyn jälkeen WordPress tietää:
– mitä sisältöä näytetään
– mitä template-logiikkaa käytetään
Template hierarchy astuu kuvaan
Kun kysely on valmis, WordPress valitsee teeman template hierarchy -säännöillä oikean tiedoston.
Esimerkiksi:
– single.php
– page.php
– archive.php
– index.php
Template hierarchy on WordPressin tapa erottaa logiikka ja esitys. Bootstrap-prosessin kannalta tämä on viimeinen suuri päätösvaihe.
The Loop ja sisällön renderöinti
Kun template on valittu, WordPress siirtyy renderöintiin. The Loop käy läpi WP_Queryn tulokset ja tulostaa sisällön.
Tässä vaiheessa:
– tietokantakyselyt on jo tehty
– suurin osa logiikasta on valmis
– fokus on HTML:n tuottamisessa
Bootstrap on käytännössä ohi. Nyt ollaan esityskerrokseen puolella.
wp_head ja wp_footer
wp_head ja wp_footer ovat viimeisiä bootstrap-prosessin “portteja”. Ne mahdollistavat:
– assettien lisäämisen
– metatietojen tulostamisen
– lisäosien viime hetken toiminnan
Niiden merkitys suorituskyvylle ja yhteensopivuudelle on valtava.
Mitä bootstrap ei tee
On tärkeää ymmärtää, mitä bootstrap ei tee automaattisesti:
– se ei välimuistita sivuja
– se ei optimoi kyselyitä
– se ei tiedä liiketoimintalogiikasta
Bootstrap tarjoaa rungon, ei ratkaisuja.
Yleisimmät virheet bootstrapin ymmärtämisessä
Yksi yleisimmistä virheistä on tehdä raskasta logiikkaa liian aikaisessa hookissa. Toinen on olettaa, että WP_Query on käytettävissä ennen kuin se on luotu.
Kolmas virhe on laittaa kaiken functions.php:hen ilman ymmärrystä kontekstista.
Bootstrap ja suorituskyky
Jokainen bootstrap-vaihe lisää hieman overheadia. Välimuistikerrokset pyrkivät ohittamaan bootstrapin kokonaan, mikä on suorituskyvyn kannalta ideaali tilanne.
Silti bootstrapin ymmärtäminen on välttämätöntä, koska kaikkea ei voi välimuistittaa.
Lopuksi
WordPressin bootstrap-prosessi on elegantti, jos sitä tarkastelee oikein. Se on deterministinen, laajennettava ja yllättävän looginen kokonaisuus.
Kun ymmärrät, miten index.php muuttuu teemaksi, ymmärrät samalla, missä WordPressin rajat ja vahvuudet todella ovat. Bootstrap ei ole pelkkä käynnistysvaihe. Se on WordPressin koko ajattelumalli.
