WordPressin request lifecycle määrittää koko sivun elinkaaren hetkestä, jolloin käyttäjä avaa URL-osoitteen siihen asti kun HTML palautetaan selaimelle. Kun tämän prosessin ymmärtää kunnolla, debuggaus, suorituskykyoptimointi ja plugin-kehitys muuttuvat huomattavasti helpommiksi.
Yksinkertaistettuna:...
Esimerkki:...
WordPressin entry point:...
Tämä tiedosto lataa:...
Tämä käynnistää ympäristön:...
Tärkeä vaihe:...
Jos page cache on käytössä:...
Jos Redis/Memcached käytössä:...
Tämä on WordPressin varsinainen bootstrap....
WordPress käy aktiiviset pluginet läpi:...
MU-pluginet ladataan ennen tavallisia plugineita....
WordPress rakentaa action/filter-järjestelmän....
Ensimmäisiä isoja hookeja:...
Yksi tärkeimmistä vaiheista....
WordPress parsii URLin:...
WordPress luo pääqueryn:...
Esimerkki:...
WordPress päättää mikä template renderöidään....
Viimeinen iso vaihe ennen renderöintiä....
get_header(); Tässä HTML alkaa muodostua....
WordPress renderöi sisällön:...
Gutenberg renderöi blockit:...
wp_footer(); Pluginet lisäävät:...
NGINX/Apache palauttaa:...
Lopuksi:...
Admin-requestit kulkevat eri reittiä:...
admin-ajax.php:...
REST Request ↓ Route Match ↓ Permission Check ↓ Callback ↓ JSON Response Missä suorituskyky yleensä hajoaa Tyypilliset pullonkaulat:...
Tyypilliset pullonkaulat:...
Moderni WordPress:...
Moderni WordPress:...
Moderni WordPress:...
WordPressin request lifecycle on kerroksellinen prosessi, jossa bootstrap, hookit, queryt ja renderöinti tapahtuvat tarkasti määritellyssä järjestyksessä. Kun tämän järjestyksen ymmärtää, on paljon helpompi rakentaa nopeita...
Moni WordPress-ongelma liittyy siihen, että koodi suoritetaan väärässä vaiheessa lifecycleä.
Mitä request lifecycle tarkoittaa
Yksinkertaistettuna:
HTTP Request
↓
Web Server
↓
WordPress Bootstrap
↓
Routing
↓
Query
↓
Template Loading
↓
Response
Jokainen vaihe sisältää hookeja, cachea ja WordPressin sisäisiä prosesseja.
1. HTTP request saapuu palvelimelle
Esimerkki:
GET /blog/post-name
NGINX tai Apache vastaanottaa requestin.
NGINX:
try_files $uri $uri/ /index.php?$args;
Useimmat requestit ohjataan:
index.php
2. index.php käynnistyy
WordPressin entry point:
require __DIR__ . '/wp-blog-header.php';
Tästä bootstrap alkaa.
3. wp-blog-header.php
Tämä tiedosto lataa:
require_once ABSPATH . 'wp-load.php';
4. wp-load.php
Tämä käynnistää ympäristön:
- wp-config.php
- database connection
- constants
- plugin loading
5. wp-config.php
Tärkeä vaihe:
define('DB_NAME', 'wordpress');
Täällä määritellään:
- DB-yhteys
- cache-asetukset
- debug
- environment config
6. advanced-cache.php (jos käytössä)
Jos page cache on käytössä:
advanced-cache.php
voi palauttaa cached response ennen WordPressin latausta.
Tämä on erittäin tärkeä suorituskykyoptimointi.
7. Object cache bootstrap
Jos Redis/Memcached käytössä:
object-cache.php
ladataan aikaisin.
8. wp-settings.php
Tämä on WordPressin varsinainen bootstrap.
Se lataa:
- pluginit
- teemat
- core-komponentit
- hook-järjestelmän
9. Pluginit ladataan
WordPress käy aktiiviset pluginet läpi:
active_plugins
Plugin file suoritetaan heti.
Tässä vaiheessa EI pitäisi tehdä raskaita queryjä.
10. Must-use pluginet
MU-pluginet ladataan ennen tavallisia plugineita.
Hyvä paikka:
- infrastruktuurikoodille
- security layerille
- enterprise bootstrapille
11. Hook-järjestelmä käynnistyy
WordPress rakentaa action/filter-järjestelmän.
Keskeisiä hookeja:
plugins_loaded
init
wp
template_redirect
12. plugins_loaded
Ensimmäisiä isoja hookeja:
add_action('plugins_loaded', ...);
Tässä:
- kaikki pluginet ladattu
- mutta queryä ei vielä ole
13. init
Yksi tärkeimmistä vaiheista.
Tässä yleensä:
- CPT registration
- taxonomy registration
- rewrite rules
- session bootstrap
add_action('init', ...);
14. Rewrite parsing
WordPress parsii URLin:
example.com/product/shoes
Rewrite rules määrittävät:
- mikä sisältö haetaan
- mikä query rakennetaan
15. WP_Query rakentuu
WordPress luo pääqueryn:
$wp_query
Tässä vaiheessa:
- SQL muodostetaan
- cache tarkistetaan
- metadata voidaan preloadata
16. Database query
Esimerkki:
SELECT * FROM wp_posts
Tässä kohtaa hitaat queryt näkyvät.
17. Template hierarchy
WordPress päättää mikä template renderöidään.
Esimerkki:
single-product.php
↓
single.php
↓
index.php
18. template_redirect
Viimeinen iso vaihe ennen renderöintiä.
Hyvä paikka:
- redirecteille
- auth-checkeille
- conditional logicille
add_action('template_redirect', ...);
19. Header output
get_header();
Tässä HTML alkaa muodostua.
20. The Loop
WordPress renderöi sisällön:
while (have_posts()) :
the_post();
endwhile;
Tässä tapahtuu paljon:
- content filters
- shortcodes
- block rendering
- metadata loading
21. Block rendering
Gutenberg renderöi blockit:
parse_blocks()
render_block()
Dynamic blockit voivat tehdä lisää queryjä.
22. Footer phase
wp_footer();
Pluginet lisäävät:
- JS
- trackingit
- analytics
- lazy loaders
23. Response palautetaan
NGINX/Apache palauttaa:
HTML Response
Selain aloittaa:
- parsing
- CSS loading
- JS execution
24. Shutdown vaihe
Lopuksi:
shutdown
Tässä:
- cache write
- session save
- logging
- deferred processing
Request lifecycle adminissa
Admin-requestit kulkevat eri reittiä:
wp-admin/
Mukana:
- capability checks
- admin bootstrap
- screen loading
AJAX lifecycle
admin-ajax.php:
admin-ajax.php
↓
wp-load.php
↓
action hook
REST API on kevyempi vaihtoehto.
REST API lifecycle
REST Request
↓
Route Match
↓
Permission Check
↓
Callback
↓
JSON Response
Missä suorituskyky yleensä hajoaa
Tyypilliset pullonkaulat:
- liian aikaiset queryt
- raskas init-hook
- meta_queryt
- dynamic block rendering
- pluginien duplicate hookit
- autoloaded options
Milloin mikäkin hook kannattaa käyttää
plugins_loaded
- plugin bootstrap
init
- CPT:t
- rewrite rules
wp
- queryyn perustuva logiikka
template_redirect
- redirectit
- auth
wp_enqueue_scripts
- CSS/JS enqueue
Yleisimmät virheet lifecycle-ajattelussa
- query init-hookissa
- output ennen template vaihetta
- liian raskas plugins_loaded
- redirect väärässä hookissa
- session start liian myöhään
Paras arkkitehtuuri lifecycleä ajatellen
Moderni WordPress:
- kevyt bootstrap
- lazy-loaded servicet
- object cache
- page cache
- async processing
- minimaalinen init-logiikka
- hookit oikeissa vaiheissa
Yhteenveto
WordPressin request lifecycle on kerroksellinen prosessi, jossa bootstrap, hookit, queryt ja renderöinti tapahtuvat tarkasti määritellyssä järjestyksessä. Kun tämän järjestyksen ymmärtää, on paljon helpompi rakentaa nopeita plugineita, debugata ongelmia ja optimoida suorituskykyä.
Moni WordPressin hitaus- tai konfliktitilanne johtuu siitä, että logiikka suoritetaan väärässä vaiheessa request lifecycleä.