Miten WordPress käynnistyy: latausprosessi selitettynä

Kun käyttäjä kirjoittaa selaimeen URL-osoitteen ja painaa Enter, tapahtuu jotain, mikä näyttää yksinkertaiselta mutta on todellisuudessa monivaiheinen orkesteriesitys. WordPress ei ole yksi skripti. Se on bootstrap-prosessi, jossa järjestelmä rakentaa oman runtime-universuminsa ennen kuin yksikään teema tai lisäosa ehtii sanoa sanaakaan.

WordPress ei “avaudu”.

Se käynnistyy.

Ja käynnistyminen on huomattavasti kiinnostavampi prosessi kuin miltä se ensisilmäyksellä näyttää.

Kaikki alkaa index.php:stä

Tyypillisessä WordPress-asennuksessa HTTP-pyyntö osuu tiedostoon:

index.php

Tämä tiedosto on minimalistinen. Sen tehtävä ei ole logiikka. Sen tehtävä on käynnistys.

Se tekee käytännössä yhden keskeisen asian:

lataa wp-blog-header.php

Index.php on portti, ei sovellus.

wp-blog-header.php: bootstrapin ensimmäinen vaihe

wp-blog-header.php toimii siltana web-palvelimen ja WordPressin ytimen välillä.

Se:

• lataa wp-load.php

• käynnistää WordPressin ympäristön

• aloittaa query-prosessin

Tässä kohtaa WordPress ei vielä tiedä mitään:

• teemasta

• sisällöstä

• käyttäjästä

Se rakentaa perustaa.

wp-load.php: ympäristön paikannus

wp-load.php:n keskeinen tehtävä on löytää:

wp-config.php

WordPress ei oleta kiinteää rakennetta. wp-load.php etsii konfiguraation useiden hakupolkujen kautta.

Kun wp-config.php löytyy, siirrytään bootstrapin kriittisimpään vaiheeseen.

wp-config.php: universumin perussäännöt

wp-config.php ei ole vain asetustiedosto.

Se on runtime’n perustuslaki.

Se määrittelee:

• tietokantayhteyden

• debug-asetukset

• muistirajat

• custom-konfiguraatiot

• ympäristökohtaiset säännöt

Ilman wp-config.php:tä WordPress ei ole sovellus.

Se on kasa PHP-tiedostoja ilman identiteettiä.

wp-settings.php: todellinen käynnistysmoottori

Kun wp-config.php on ladattu, WordPress siirtyy tiedostoon:

wp-settings.php

Tämä on bootstrap-prosessin sydän.

wp-settings.php:

• lataa core-tiedostot

• alustaa globaalit rakenteet

• käynnistää hook-järjestelmän

• lataa lisäosat

• lataa teeman

WordPress ei ole yksi include. Se on satojen includejen hallittu sekvenssi.

Include-järjestys ei ole sattumaa

Bootstrapissa järjestys on kaikki.

Jos tietokantaluokka latautuisi liian myöhään → kaaos.
Jos hookit käynnistyisivät liian aikaisin → kaaos.

wp-settings.php on koreografia.

Core-tiedostojen lataus

Ensimmäinen suuri vaihe:

WordPressin ydintoiminnot.

Mukana ovat esimerkiksi:

• plugin API

• formatting functions

• post types

• taxonomy logic

• query engine

• rewrite system

Tässä kohtaa WordPress rakentaa oman käyttöjärjestelmänsä.

Ei vielä sisältöä.

Vaan infrastruktuurin.

Hook-järjestelmän alustaminen

WordPressin event-driven -malli syntyy bootstrapissa.

Hookit eivät ole lisäominaisuus.

Ne ovat järjestelmän hermosto.

Kun hookit alustetaan:

• callbackit voidaan rekisteröidä

• runtime voidaan muokata

• lisäosat voivat vaikuttaa kaikkeen

Bootstrap ei vain lataa koodia.

Se aktivoi ekosysteemin.

Lisäosien lataus

Seuraava vaihe:

Active plugins.

WordPress:

• lukee active plugin -listan

• includee jokaisen lisäosan

• antaa niille pääsyn hookeihin

Lisäosat eivät ole “myöhemmin ladattavia”.

Ne ovat osa bootstrap-prosessia.

Tässä kohtaa runtime alkaa muuttua emergentiksi.

Core + plugin-ekosysteemi = dynaaminen järjestelmä.

Pluggable functions: historiallinen nerokkuus

WordPress lataa pluggable.php:n, joka mahdollistaa tiettyjen funktioiden uudelleenmäärittelyn.

Tämä on elegantti kompromissi:

• ei pakotettua perintämallia

• ei monimutkaista DI-rakennetta

• mutta silti override-mahdollisuus

Bootstrap ei ole vain tekninen prosessi.

Se on design-filosofia käytännössä.

Teeman lataus

Kun core ja lisäosat ovat ladattu, WordPress siirtyy teemaan.

Teema ei ole pelkkä view-layer.

Se on runtime-komponentti.

functions.php:

• ladataan automaattisesti

• voi rekisteröidä hookeja

• voi muokata queryjä

• voi vaikuttaa renderöintiin

Teema ei ole passiivinen.

Se on aktiivinen osallistuja.

Query-prosessi: mitä käyttäjä oikeasti pyysi?

Kun bootstrap on valmis, WordPress siirtyy kysymykseen:

“Mitä URL tarkoittaa?”

Rewrite rules + query vars → WP_Query

WordPress:

• tulkitsee URL:n

• rakentaa queryn

• hakee sisällön

Bootstrap loi ympäristön. Query täyttää sen datalla.

Template hierarchy: mikä näkymä valitaan?

Kun query on ratkaistu:

• mikä template?

• single.php?

• archive.php?

• page.php?

WordPress ei vain renderöi.

Se päättää renderöintistrategian.

Render pipeline

Lopullinen vaihe:

• template execution

• loop

• block rendering

• output generation

HTML ei ole tallennettu dokumentti.

Se on bootstrap + query + template -prosessin tulos.

Miksi bootstrap ymmärtäminen on tärkeää?

Koska WordPress ei ole lineaarinen skripti.

Se on stateful runtime.

Bugien ymmärtäminen vaatii usein bootstrapin ymmärtämistä:

• milloin hook laukeaa?

• milloin plugin latautuu?

• milloin globaali tila alustetaan?

Suorituskyvyn ymmärtäminen vaatii bootstrapin ymmärtämistä:

• kuinka monta tiedostoa ladataan?

• kuinka paljon logiikkaa suoritetaan ennen outputia?

Suorituskyky: bootstrap ei ole ilmainen

Jokainen pyyntö:

• lataa kymmeniä tai satoja tiedostoja

• alustaa rakenteita

• käynnistää hookit

Opcode cache tekee tästä siedettävää.

Ilman sitä bootstrap olisi huomattavasti raskaampi.

Lopuksi: WordPress ei vain lataa sivua

Se rakentaa universumin joka pyynnöllä.

• ympäristö

• hookit

• pluginit

• query

• template

• renderöinti

Kun tämän kerran sisäistää, WordPress lakkaa näyttämästä yksinkertaiselta CMS:ltä ja alkaa näyttäytyä siltä, mitä se oikeasti on:

Täysimittainen runtime-järjestelmä, joka käynnistyy jokaisella HTTP-pyynnöllä.

Ja siinä on jotain yllättävän eleganttia.