Gutenberg näyttää käyttäjälle visuaaliselta editorilta, mutta konepellin alla kyse ei ole “tekstieditorista”, vaan rakenteellisesta renderöintijärjestelmästä. Kun sivu ladataan, WordPress ei yksinkertaisesti tulosta HTML:ää tietokannasta. Se suorittaa kokonaisen pipeline’n, jossa lohkot tulkitaan, muunnetaan ja lopulta renderöidään.
Ja tämä pipeline on paljon vähemmän maaginen – ja paljon loogisempi – kuin miltä se aluksi tuntuu.
Kaikki alkaa datasta, ei HTML:stä
Klassisessa WordPressissä sisältö oli pitkälti HTML:ää. Gutenberg muutti tämän ajattelumallin. Postauksen sisältö ei ole enää pelkkä markup, vaan lohkorakenne.
Tietokantaan tallennettu sisältö näyttää tältä:
<!-- wp:paragraph -->
<p>Tämä on kappale.</p>
<!-- /wp:paragraph -->
Tai monimutkaisemmassa muodossa:
<!-- wp:group -->
<div class="wp-block-group">
<!-- wp:heading -->
<h2>Otsikko</h2>
<!-- /wp:heading -->
</div>
<!-- /wp:group -->
Tärkeä havainto: HTML on mukana, mutta se ei ole primäärinen totuus. Primäärinen totuus on lohkorakenne.
HTML on enemmänkin snapshot.
Ensimmäinen vaihe: parsing
Kun WordPress renderöi sivun, pipeline’n ensimmäinen askel on parsing.
WordPress:
-
lukee post_contentin
-
tunnistaa lohkokommentit
-
rakentaa lohkotietorakenteen
Funktio parse_blocks() tekee tämän työn. Se muuntaa tekstin rakenteelliseksi dataksi.
Lopputulos ei ole HTML, vaan array- tai objektirakenne, joka sisältää:
-
block type
-
attribuutit
-
inner blocks
-
inner HTML
Sisältö muuttuu ohjelmalliseksi rakenteeksi.
Parsing ei renderöi mitään
Parsing ei vielä “piirrä” sivua. Se vain purkaa sisällön osiin.
Ajattele tätä AST:nä (Abstract Syntax Tree). Sama idea kuin ohjelmointikielissä:
Teksti → rakenne → suoritus
Toinen vaihe: block resolution
Kun lohkot on parsittu, WordPress joutuu ratkaisemaan:
“Mitä tämä block type tarkoittaa?”
Block type yhdistyy rekisteröityyn lohkoon:
-
core block
-
plugin block
-
dynamic block
WordPress etsii:
-
renderöintilogiiikan
-
callbackit
-
metadata
Block ei ole vain HTML-fragmentti. Se on komponentti, jolla on käyttäytyminen.
Staattinen vs dynaaminen renderöinti
Tässä kohtaa pipeline haarautuu.
Staattiset lohkot
Staattinen block:
-
käyttää tallennettua HTML:ää
-
ei vaadi serverilogiiikkaa
-
renderöinti on lähes trivial
Esimerkiksi perus paragraph-block.
WordPress voi käytännössä sanoa:
“Tässä on HTML → tulostetaan.”
Dynaamiset lohkot
Dynaaminen block:
-
ei luota tallennettuun HTML:ään
-
käyttää render callbackia
-
generoi outputin lennossa
Esimerkkejä:
-
Latest Posts
-
Query Loop
-
Navigation
-
WooCommerce-lohkot
Renderöinti ei ole enää pelkkä tulostus. Se on logiikan suoritus.
Kolmas vaihe: renderointi
Varsinainen renderöinti tapahtuu funktion render_block() kautta.
Pipeline:
-
Block tunnistetaan
-
Callback tarkistetaan
-
HTML generoidaan
-
Inner blocks renderöidään rekursiivisesti
Tärkeä sana: rekursiivisesti.
Blockit voivat sisältää blockeja, jotka sisältävät blockeja.
Renderöinti ei ole lineaarinen prosessi. Se on puumainen traversal.
Inner blocks: pipeline’n fraktaalirakenne
Group-block ei oikeasti “sisällä HTML:ää”. Se sisältää lohkoja.
Renderöinti:
-
renderöi parentin
-
renderöi childrenit
-
yhdistää lopputuloksen
Sama logiikka toistuu jokaisella tasolla.
Pipeline on fraktaali.
Neljäs vaihe: filtteri-ekosysteemi
Kun block renderöidään, WordPress ei vielä sano viimeistä sanaa.
Hookit astuvat näyttämölle:
-
render_block -
pre_render_block -
block-spesifit filterit
Lisäosat voivat:
-
muokata outputia
-
injektoida sisältöä
-
ohittaa renderöintiä
Render pipeline ei ole suljettu putki. Se on avoin järjestelmä.
Ja tästä syntyy WordPressin klassinen emergenssi.
Viides vaihe: frontend vs editor
Hauska käänne: Gutenberg renderöi kahdessa universumissa.
Editor-renderöinti
Editorissa renderöinti tapahtuu React-komponenttien kautta.
Block:
-
ei ole PHP-renderöinti
-
vaan JavaScript-komponentti
-
käyttää block definitionia
Editor ei lue HTML:ää samalla tavalla kuin frontend.
Se lukee block dataa.
Frontend-renderöinti
Frontendissa PHP ottaa vallan.
Block:
-
parsitaan
-
renderöidään serverillä
-
output lähetetään selaimelle
Sama sisältö, eri renderöintimoottori.
Tämä kaksoisarkkitehtuuri on Gutenbergin ydin.
Miksi tallennettu HTML on mukana?
Tämä hämmentää monia.
Jos blockit renderöidään dynaamisesti, miksi HTML tallennetaan?
Syyt ovat pragmaattisia:
-
fallback-yhteensopivuus
-
editorin preview
-
portability
-
backward compatibility
HTML toimii snapshotina.
Block metadata toimii logiikkana.
Pipeline’n ajallinen luonne
Block rendering pipeline ei ole vain tekninen prosessi. Se on ajallinen malli.
Sisältö ei ole staattinen dokumentti. Se on resepti.
Parsing → resolution → rendering → filtering
Sivu ei ole “luettu”. Se on rakennettu.
Joka latauksella.
Suorituskyky: missä kustannus syntyy?
Pipeline ei ole ilmainen.
Jokainen sivulataus:
-
parsii blockit
-
renderöi callbackit
-
traversoi rakenteen
-
suorittaa hookit
Staattinen HTML olisi halvempi.
Mutta Gutenberg ostaa joustavuutta laskennalla.
Välimuisti pipeline’n pelastajana
Tästä syystä caching on Gutenberg-maailmassa kriittinen:
-
page cache
-
fragment cache
-
object cache
Pipeline’n kustannus voidaan amortisoida.
Pipeline’n filosofinen ydin
Gutenberg ei ole vain editori. Se on renderöintimalli.
Sisältö ei ole:
HTML → näytä
Sisältö on:
Rakenne → tulkitse → renderöi
Se on lähempänä sovelluslogiikkaa kuin dokumenttimallia.
Ja juuri siksi Gutenberg tuntuu joskus “raskaammalta”, mutta mahdollistaa asioita, joita klassinen editori ei koskaan voinut.
Block rendering pipeline ei ole mustaa magiaa.
Se on deterministinen rakennusprosessi.
WordPress ei piirrä sivua.
Se kokoaa sen.
