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ä:

Tai monimutkaisemmassa muodossa:

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:

1. Block tunnistetaan

2. Callback tarkistetaan

3. HTML generoidaan

4. 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.

WordPressin WP-Cron on yksi niistä järjestelmän osista, jotka näyttävät harmittomilta, mutta kätkevät sisäänsä eleganttia logiikkaa ja muutaman klassisen ohjelmistokehityksen sudenkuopan. Näistä ehkä kiinnostavin – ja ajoittain tuskallisin – liittyy cron locking -mekanismiin ja kilpajuoksuongelmiin.

WP-Cron ei ole oikea käyttöjärjestelmätason cron. Se on simulaatio. Ja simulaatiot, kuten tiedämme, ovat usein täynnä hienovaraisia kompromisseja.

WP-Cronin perusrealiteetti

WP-Cron toimii pyynnön yhteydessä. Kun joku lataa sivun, WordPress tarkistaa:

“Onko ajastettuja tehtäviä, jotka pitäisi suorittaa?”

Jos on, WordPress käynnistää cron-prosessin.

Tämä tarkoittaa yhtä tärkeää asiaa:

Cron ei ole jatkuva taustaprosessi. Se on opportunistinen.

Ei käyttäjiä → ei cron-ajamista.
Paljon käyttäjiä → paljon cron-tarkistuksia.

Ja tästä alkaa mielenkiintoinen dynamiikka.

Cron locking: miksi sitä edes tarvitaan?

Ajattele hetki tilannetta ilman lockingia.

Sivustolla on paljon liikennettä. Useita pyyntöjä osuu palvelimelle lähes samanaikaisesti. Jokainen pyyntö tarkistaa cronin.

Kaikki huomaavat:

“Ahaa, tehtävä pitäisi ajaa.”

Ilman lockingia:

• sama cron-tehtävä voisi käynnistyä monta kertaa

• raskas logiikka monistuisi

• tietokanta kärsisi

• CPU itkisi hiljaa nurkassa

Cron locking on WordPressin tapa sanoa:

“Vain yksi cron-prosessi kerrallaan.”

Locking on koordinaatiomekanismi

Cron locking ei ole turvallisuusominaisuus. Se on synkronointimekanismi.

Se estää:

• päällekkäiset ajot

• redundantit operaatiot

• resurssien tuhlauksen

Kyse on klassisesta concurrency-ongelmasta.

Miten WordPress toteuttaa cron lockingin?

WP-Cron käyttää transienttia nimeltä:

doing_cron

Kun cron käynnistyy:

• WordPress asettaa lockin

• lockilla on aikaraja

• muut prosessit näkevät lockin

• rinnakkaiset ajot estetään

Eleganttia. Kevyttä. Käytännöllistä.

Ja silti… ei täydellistä.

Kilpajuoksuongelmat: missä realismi iskee?

Kilpajuoksu (race condition) syntyy, kun:

• useita prosesseja toimii samanaikaisesti

• järjestelmän tila muuttuu nopeasti

• lopputulos riippuu ajoituksesta

WP-Cron + korkea liikenne = täydellinen laboratorio kilpajuoksuille.

Klassinen skenaario

Kaksi pyyntöä saapuu lähes samanaikaisesti.

1. Molemmat tarkistavat cron-tilan

2. Molemmat näkevät “ei lockia”

3. Molemmat yrittävät asettaa lockin

Tässä kohtaa kaikki riippuu nanosekunneista.

Transienttien käsittely ei ole atominen operaatio koko järjestelmän tasolla. Locking ei ole täydellinen mutex.

Ja näin syntyy:

• kaksoisajot

• päällekkäiset cronit

• satunnaiset ilmiöt

Ei usein. Mutta riittävän usein tuotannossa.

Locking ei ole absoluuttinen takuu

Tämä on tärkeä oivallus.

Cron locking on best-effort -mekanismi.

Se vähentää kilpajuoksuja.
Se ei poista niitä täysin.

Web-ympäristössä täydellinen synkronointi on vaikeaa, koska:

• useita PHP-prosesseja

• useita palvelimia (load balancing)

• välimuistit

• transient storage -strategiat

WordPress tekee pragmaattisen kompromissin.

Transientit ja distributed reality

Kun transientit tallennetaan:

• tietokantaan

• object cacheen

• Redis/Memcachediin

locking-käyttäytyminen muuttuu hienovaraisesti.

Single server → melko ennustettava
Distributed cache → viiveitä, synkronointieroja

Lock ei ole aina välittömästi näkyvä kaikille prosesseille.

Ja concurrency-ongelmat rakastavat tällaisia tilanteita.

Kilpajuoksujen seuraukset käytännössä

Useimmiten kilpajuoksu ei kaada sivustoa. Se aiheuttaa outoja sivuvaikutuksia.

Esimerkiksi:

• sama email lähetetään kahdesti

• sama API-kutsu tehdään useasti

• sama raportti generoidaan rinnakkain

• data päivittyy epäjohdonmukaisesti

Nämä ovat niitä virheitä, jotka tuntuvat “satunnaisilta”.

Mutta ne eivät ole satunnaisia.

Ne ovat ajoitusongelmia.

Idempotenssi: concurrency-maailman supervoima

Kun cron-tehtäviä suunnitellaan, yksi käsite nousee ylitse muiden:

Idempotenssi.

Idempotentti operaatio tarkoittaa:

Voidaan suorittaa useasti ilman haitallisia sivuvaikutuksia.

Jos cron ajetaan kahdesti:

• ei duplikaatteja

• ei datakorruptiota

• ei kaaosta

WP-Cron-maailmassa tämä ei ole vain hyvä käytäntö.

Se on selviytymisstrategia.

Locking vs logiikan kestävyys

Cron locking yrittää estää kaksoisajot.

Mutta kypsä arkkitehtuuri olettaa:

“Kaksoisajot ovat mahdollisia.”

Tämä ajattelutavan muutos on kriittinen.

Locking on optimointi.
Idempotenssi on turvaverkko.

Korkean liikenteen sivustot ja cron-dynamiikka

Mitä enemmän liikennettä:

• sitä useammin cron tarkistetaan

• sitä enemmän concurrency-tilanteita

• sitä suurempi kilpajuoksuriski

Ironia on herkullinen.

WP-Cron toimii parhaiten:

• matalan liikenteen sivustoilla

Ja joutuu kovimmalle koetukselle:

• korkean liikenteen ympäristöissä

Oikea cron vs WP-Cron

Tästä syystä monissa tuotantoympäristöissä käytetään:

Oikeaa server cron -ajastusta.

Server cron:

• käynnistää WP-Cronin hallitusti

• vähentää kilpailutilanteita

• lisää ennustettavuutta

WP-Cron:

• opportunistinen

• reaktiivinen

• elegantti mutta epätäydellinen

Kumpikaan ei ole “väärä”. Ne palvelevat eri konteksteja.

Kilpajuoksuongelmien filosofia

Kilpajuoksut eivät ole WordPress-ongelma.

Ne ovat distributed systems -ongelma.

Kun useita prosesseja toimii:

• samassa tilassa

• samassa ajassa

• ilman täydellistä synkronointia

kilpajuoksut ovat väistämättömiä.

WP-Cron ei riko tätä sääntöä. Se elää sen sisällä.

Lopuksi: locking ei ole pelastus, vaan kompromissi

Cron locking ei ole virheetön lukitusmekanismi.

Se on:

• kevyt

• nopea

• riittävän hyvä useimpiin tilanteisiin

Ja juuri tämä “riittävän hyvä” on WordPressin design-filosofian ydin.

Täydellinen locking vaatisi:

• raskaita synkronointimekanismeja

• suorituskykyuhrauksia

• monimutkaista infrastruktuuria

WordPress valitsee käytännöllisyyden.

Kypsä kehittäjä ei kysy:

“Miten estän kaikki kilpajuoksut?”

Kypsä kehittäjä kysyy:

“Miten järjestelmä kestää kilpajuoksut?”

Ja juuri siinä kohtaa cron-logiikka muuttuu mekaanisesta ajastuksesta resilientiksi systeemisuunnitteluksi.

Kilpajuoksut eivät ole poikkeus.

Ne ovat moniprosessimaailman luonnonlaki.

WordPress-kehityksessä – ja web-kehityksessä ylipäätään – harva aihe synnyttää yhtä paljon hiljaista sekaannusta kuin sanitization ja escaping. Termit kuulostavat samankaltaisilta. Molemmat liittyvät turvallisuuteen. Molemmat käsittelevät dataa. Ja silti ne eivät ole sama asia, eivätkä ne ole vaihdettavissa keskenään.

Kyse ei ole semantiikasta tai terminologiasta. Kyse on koko sovelluksen turvallisuusmallista.

Sanitization ja escaping ovat kuin kaksi eri ajallista ulottuvuutta datan elämässä. Toinen tapahtuu ennen kuin data hyväksytään järjestelmään. Toinen tapahtuu juuri ennen kuin data päästetään ulos.

Ja juuri tämä ajallinen ero on kaiken ydin.

Data ei ole koskaan vain dataa

Kun käyttäjä syöttää tietoa WordPressiin, kyse ei ole vain tekstistä. Kyse ei ole vain lomakekentästä. Kyse on rajapinnasta järjestelmän ja ulkomaailman välillä.

Ulkoa tuleva data on lähtökohtaisesti epäluotettavaa.

Ei siksi, että käyttäjä olisi pahantahtoinen. Vaan siksi, että järjestelmä ei voi tehdä oletuksia. Turvallisuus ei perustu optimismiin.

Sanitization ja escaping ovat mekanismeja, joilla WordPress käsittelee tätä epistemologista ongelmaa: mitä voimme luottaa, ja milloin.

Sanitization: sisäänpääsyn vartija

Sanitization tapahtuu, kun data tulee järjestelmään.

Se kysyy:
“Mitä tämä data saa olla?”

Sanitization ei ole pelkkää haitallisen sisällön poistamista. Se on datan normalisointia. Muokkaamista. Siistimistä. Rajoittamista.

Kun käytät esimerkiksi sanitize_text_field()-funktiota, et vain “poista vaarallisia merkkejä”. Muotoilet datan vastaamaan odotettua rakennetta.

Sanitization määrittelee datan kelpoisuuden.

Sanitization on intentiokeskeinen

Sanitization perustuu oletukseen, että tiedämme, millaista dataa haluamme.

Esimerkiksi:

• Tekstikenttä → vain tekstiä

• Email → validi sähköpostiosoite

• Numero → numero

Sanitization ei ole universaali suodatin. Se on kontekstisidonnainen muunnos.

Se ei kysy “onko tämä vaarallista?”, vaan “onko tämä sellaista dataa kuin odotamme?”.

Escaping: ulospääsyn turvaportti

Escaping tapahtuu, kun data lähtee järjestelmästä.

Se kysyy:
“Miten tämä data esitetään turvallisesti tässä kontekstissa?”

Escaping ei muuta datan merkitystä. Se muuttaa sen representaatioita.

Kun käytät esc_html()-funktiota, data ei muutu sisällöllisesti. Sen esitysmuoto muuttuu. Erikoismerkit muutetaan turvallisiksi HTML-entiteeteiksi.

Escaping suojaa renderöintiympäristöä.

Escaping on kontekstikeskeinen

Escaping riippuu siitä, missä data näytetään.

HTML-konteksti → esc_html()
Attribuuttikonteksti → esc_attr()
URL-konteksti → esc_url()
JavaScript-konteksti → esc_js()

Sama data tarvitsee eri escaping-logiikan riippuen ympäristöstä.

Escaping ei ole datan validointia. Se on ympäristön suojaamista.

Ajallinen ero: koko pelin ydin

Sanitization ja escaping eivät ole kilpailijoita. Ne toimivat eri hetkissä.

Sanitization → ennen tallennusta
Escaping → ennen outputia

Tämä ei ole mielipidekysymys. Tämä on turvallisuusarkkitehtuurin perusperiaate.

Ilman sanitizationia:

• tietokantaan päätyy roskaa

• data voi olla rakenteellisesti virheellistä

• logiikka voi hajota

Ilman escapingia:

• XSS-hyökkäykset mahdollisia

• renderöintikonteksti rikkoontuu

• käyttäjä näkee haitallista sisältöä

Toinen suojaa järjestelmää sisältäpäin. Toinen suojaa käyttöliittymää ulospäin.

Klassinen väärinkäsitys: “sanitoin kaiken tallennuksessa, olen turvassa”

Tämä on yksi yleisimmistä ajatusvirheistä.

Sanitization ei ole escaping.

Sanitoitu data voi silti olla vaarallista output-kontekstissa.

Esimerkiksi:

Käyttäjä syöttää tekstin, joka on täysin validia sisältöä, mutta sisältää HTML-merkkejä. Sanitization voi hyväksyä sen, koska data on rakenteellisesti kelvollista.

Ilman escapingia selain voi tulkita sisällön koodina.

Sanitization ei suojaa renderöintiä.

Toinen väärinkäsitys: “escapaan kaiken outputissa, sanitization turhaa”

Escaping ei ole datan validointia.

Ilman sanitizationia:

• tietokantaan tallentuu odottamatonta dataa

• logiikka voi rikkoontua

• kyselyt voivat epäonnistua

• suorituskyky voi kärsiä

Escaping ei tee datasta semanttisesti järkevää.

Se tekee siitä vain turvallisesti näytettävää.

Datan elinkaari: sisään, lepo, ulos

Ajattele dataa matkustajana.

Sanitization tarkistaa passin rajalla.
Escaping tarkistaa, ettei matkustaja kanna tulitikkurasiaa polttoainevarastoon.

Eri tarkastuspisteet. Eri riskit.

Data voi viettää tietokannassa vuosia. Sen käyttökonteksti voi muuttua. Output-ympäristö voi muuttua.

Escaping tapahtuu aina suhteessa nykyiseen kontekstiin.

XSS: miksi escaping on kriittinen

XSS (Cross-Site Scripting) ei ole datan tallennusongelma. Se on renderöintiongelma.

Selain ei tiedä:

• mikä on dataa

• mikä on koodia

Escaping tekee tämän erottelun eksplisiittiseksi.

Se sanoo selaimelle:

“Tämä on sisältöä, ei koodia.”

Sanitization ei ratkaise tätä ongelmaa.

SQL-injektio: miksi sanitization ei ole ratkaisu

Sanitization ei ole SQL-suojaus.

SQL-injektio estetään:

• valmistelluilla kyselyillä

• parametrien sitomisella

• $wpdb->prepare()

Sanitization voi auttaa datan normalisoinnissa, mutta se ei ole turvallinen SQL-suojausstrategia.

Sanitization ei ole turvallisuuden hopealuoti.

Trust boundary: missä epäluotettavuus alkaa?

Turvallisuusarkkitehtuurissa keskeinen käsite on trust boundary.

Se on raja:

• luotettavan

• epäluotettavan

välillä.

Sanitization tapahtuu trust boundaryn ylityksessä.

Escaping tapahtuu trust boundaryn toisessa päässä, kun data kohtaa selaimen.

“Escape late” – WordPressin turvallisuusmantra

WordPress-kehityksessä toistuu periaate:

Escape late.

Escaping tehdään juuri ennen outputia.

Miksi?

Koska konteksti ratkaisee.

Data voi:

• päätyä HTMLiin

• päätyä attribuuttiin

• päätyä JavaScriptiin

• päätyä URLiin

Väärä escaping väärässä kontekstissa = haavoittuvuus.

Escaping ei ole kertatoimenpide.

Sanitization vs validation: hienovarainen ero

Sanitization ja validation eivät ole identtisiä.

Validation kysyy:

“Onko tämä arvo validi?”

Sanitization kysyy:

“Miten tämä arvo muokataan validiksi?”

Validation voi hylätä.
Sanitization voi korjata.

Usein ne toimivat yhdessä.

Defense-in-depth: miksi kerroksia tarvitaan

Turvallisuus ei ole yksi mekanismi. Se on kerroksia.

Sanitization → datan eheys
Escaping → renderöintiturvallisuus
Prepared statements → SQL-turvallisuus
Noncet → CSRF-suojaus
Capabilityt → käyttöoikeudet

Yksi kerros ei korvaa toista.

Turvallisuus on arkkitehtuuria, ei funktiokutsuja.

Psykologinen ansa: “turvallisuus = yksi ratkaisu”

Ihmismieli rakastaa yksinkertaisia selityksiä.

“Sanitoin → valmis.”

Web-turvallisuus ei toimi näin.

Riskit syntyvät eri vaiheissa:

• input

• tallennus

• käsittely

• output

Sanitization ja escaping suojaavat eri vaiheita.

Miksi tämä kaikki on niin helppo sotkea?

Koska molemmat käsittelevät dataa.

Koska molemmat liittyvät turvallisuuteen.

Koska molemmat “muuttavat jotain”.

Mutta niiden tarkoitus on täysin eri.

Sanitization → muokkaa dataa
Escaping → muokkaa esitystä

Sanitization → sisään
Escaping → ulos

Ajallinen ajattelu ratkaisee sekaannuksen.

Lopuksi: kyse ei ole funktioista, vaan ajattelumallista

Sanitization ja escaping eivät ole WordPress-spesifejä kikkoja. Ne ovat universaaleja turvallisuusperiaatteita.

Kun ymmärtää datan elinkaaren, trust boundaryt ja kontekstuaalisen renderöinnin, molemmat alkavat tuntua itsestäänselviltä.

Sanitization pitää järjestelmän loogisena.
Escaping pitää käyttöliittymän turvallisena.

Yksi ilman toista on puolustus, jossa on reikä.

Turvallinen WordPress ei ole “sanitoitu” tai “escapattu”.

Se on molempia.

Ja juuri oikeassa järjestyksessä.

WordPressin käyttöoikeusjärjestelmä näyttää pinnalta yksinkertaiselta. Roolit. Capabilities. current_user_can(). Mutta kulissien takana tapahtuu jotain huomattavasti kiinnostavampaa ja arkkitehtonisesti elegantimpaa: capability mapping.

Tämä on se osa WordPressiä, jossa järjestelmä siirtyy mekaanisesta tarkistuksesta kontekstuaaliseen päättelyyn. Ei enää pelkkä “onko käyttäjällä oikeus X?”, vaan “mitä tämä oikeus tarkoittaa juuri tässä tilanteessa?”.

Ja juuri tässä kohtaa WordPress muuttuu staattisesta permission-taulukosta dynaamiseksi päätöskoneeksi.

Primitive capabilities vs meta capabilities

WordPress ei käsittele kaikkia oikeuksia samalla tavalla. Capabilities jakautuvat kahteen maailmaan:

Primitive capabilities ovat suoria oikeuksia. Ne ovat binäärisiä: käyttäjällä on tai ei ole.

Esimerkkejä:

• edit_posts

• publish_posts

• manage_options

Meta capabilities ovat kontekstisidonnaisia. Ne eivät ole varsinaisia oikeuksia, vaan kysymyksiä, jotka WordPress muuntaa primitiveiksi.

Esimerkkejä:

• edit_post

• delete_post

• edit_user

Meta capability ei ole vastaus. Se on lähtökohta.

Capability mapping: mitä oikeasti tapahtuu?

Kun koodi kutsuu:

current_user_can('edit_post', $post_id)

WordPress ei etsi suoraan capability-listasta edit_post. Sen sijaan se käynnistää mapping-prosessin:

Meta capability → mapataan primitive capabilityiksi

Tämä tapahtuu funktion map_meta_cap() kautta. Se on järjestelmän hermokeskus.

Mapping-prosessi kysyy:

• Mikä post type?

• Kuka omistaa postauksen?

• Mikä status?

• Mikä konteksti?

Yksi meta capability voi muuttua täysin eri primitive-tarkistuksiksi riippuen tilanteesta.

Sama kysymys, eri vastaus

edit_post voi tarkoittaa:

• edit_posts

• edit_others_posts

• edit_published_posts

Kaikki riippuu kontekstista.

Capability mapping ei ole staattinen sääntö. Se on päätöksentekologiikka.

Kontekstuaalinen päättely – WordPressin hiljainen älykkyys

Capability mapping on WordPressin tapa mallintaa todellisuutta, jossa oikeudet eivät ole absoluuttisia.

Esimerkiksi:

“Saako käyttäjä muokata postausta?”

Ei universaalia vastausta. Riippuu:

• Onko käyttäjä kirjoittaja?

• Onko postaus julkaistu?

• Onko käyttäjä admin?

• Onko kyseessä CPT?

Mapping-järjestelmä tekee tästä dynaamista.

WordPress ei kysy vain “mitä käyttäjä saa tehdä?”. Se kysyy “mitä tämä toiminto tarkoittaa juuri nyt?”.

map_meta_cap(): arkkitehtuurinen jalokivi

map_meta_cap() on yksi WordPressin aliarvostetuimmista mekanismeista.

Se:

• vastaanottaa meta capabilityn

• analysoi kontekstin

• palauttaa primitive capabilityt

• delegoi varsinaisen tarkistuksen

Tämä erottaa semantiikan ja toteutuksen.

Meta capability kuvaa intentiota. Primitive capability kuvaa mekanismia.

Tämä on design-tasolla erittäin puhdas ratkaisu.

Custom Post Types ja capability mapping

Custom post typet tekevät capability mappingista erityisen kiinnostavan.

Kun rekisteröit CPT:n, voit määritellä:

• omat capabilityt

• capability mapping -käyttäytymisen

• meta → primitive -logiikan

CPT ei ole vain uusi sisältötyyppi. Se on uusi permission-maailma.

Capability schema CPT:lle

CPT voi käyttää:

• default capabilityt

• custom capabilityt

• hybridimallit

Tämä mahdollistaa erittäin hienojakoisen käyttöoikeusarkkitehtuurin.

Ja samalla… erittäin hienojakoiset virheet.

Sivuvaikutukset ja väärinkäsitykset

Capability mapping synnyttää tyypillisiä väärinkäsityksiä.

Kehittäjä olettaa:

“Jos käyttäjällä on capability X → toiminto sallitaan”

Todellisuus:

Meta capability voi mapata useisiin primitiveihin, joista jokainen vaikuttaa lopputulokseen.

Yksi capability ei ole aina ratkaiseva.

current_user_can() ei ole suora tarkistus

Se on kyselyjärjestelmä.

Se voi:

• laukaista mapping-logiikan

• käyttää filttereitä

• muuttaa käyttäytymistä dynaamisesti

Permission-tarkistus ei ole pelkkä array lookup.

Capability mapping ja turvallisuus

Capability mapping on WordPressin turvallisuusmallin keskiössä.

Ilman mappingia:

• oikeudet olisivat jäykkiä

• konteksti katoaisi

• permission-logiikka olisi kömpelö

Mapping mahdollistaa:

• omistajuuspohjaiset oikeudet

• statussidonnaiset oikeudet

• dynaamiset permissionit

Mutta tämä tuo mukanaan klassisen riskin:

Virheellinen oletus kontekstista = tietoturva-aukko.

Meta capability väärässä kontekstissa

Jos mapping-logiikkaa ei ymmärretä:

• käyttäjälle voidaan antaa liikaa oikeuksia

• toiminto voidaan sallia väärin

• privilege escalation syntyy

Capability mapping ei ole vain tekninen detalji. Se on security boundary.

Filters: capability mappingin dynaaminen DNA

Capability mapping ei ole suljettu järjestelmä.

WordPress tarjoaa filttereitä:

• map_meta_cap

• user_has_cap

Nämä mahdollistavat permission-logiikan muokkauksen lennossa.

Tämä on äärimmäisen voimakas ominaisuus.

Ja kuten aina voimakkaiden ominaisuuksien kanssa…

Se voi tehdä järjestelmästä nerokkaan tai kaoottisen.

Emergenssi permission-järjestelmässä

Kun useat lisäosat manipuloivat capability mappingia, syntyy emergenttiä käyttäytymistä.

Lisäosa A lisää capabilityn.
Lisäosa B muuttaa mappingia.
Lisäosa C ohittaa tarkistuksen.

Lopputulos voi olla permission-malli, jota kukaan ei eksplisiittisesti suunnitellut.

Mapping-järjestelmä ei ole lineaarinen. Se on verkosto.

Multisite: capability mappingin rinnakkaisuniversumi

Multisite tuo järjestelmään uuden ulottuvuuden:

Capabilities eivät ole vain käyttäjäkohtaisia. Ne ovat myös site-kohtaisia.

Mapping-logiikka joutuu huomioimaan:

• verkon laajuiset oikeudet

• site-kohtaiset oikeudet

• super admin -erikoistapaukset

Permission-järjestelmä muuttuu moniulotteiseksi.

Capability mappingin filosofinen ydin

Capability mapping edustaa yhtä kiinnostavaa ohjelmistoarkkitehtuurin ideaa:

Oikeudet eivät ole staattisia.

Ne ovat:

• kontekstisidonnaisia

• ajallisia

• relaatiosidonnaisia

• semanttisia

WordPress ei mallinna vain käyttäjiä ja oikeuksia. Se mallintaa tilanteita.

Ja tämä on huomattavan kypsä ratkaisu CMS-järjestelmältä.

Lopuksi: capability mapping ei ole mustaa magiaa

Se näyttää monimutkaiselta, koska todellisuus on monimutkainen.

Oikeudet eivät ole yksinkertaisia binäärisiä totuuksia. Ne ovat sääntöjen, kontekstien ja suhteiden verkosto.

Capability mapping ei ole WordPressin outo sisäinen temppu.

Se on järjestelmän tapa mallintaa maailmaa, jossa:

“Sama toiminto ei tarkoita samaa asiaa kaikille.”

Kun tämän ymmärtää, WordPressin permission-järjestelmä lakkaa olemasta mystinen ja alkaa näyttää siltä, mitä se oikeasti on:

Dynaaminen päätöksentekokone.

Ja yllättävän elegantti sellainen.

WordPress-kehityksessä tulee ennemmin tai myöhemmin vastaan kysymys, joka jakaa mielipiteitä lähes filosofisella tasolla:

“Tarvitsemmeko oman tietokantataulun?”

Moni kehittäjä yrittää välttää custom-tauluja viimeiseen asti. Toiset taas rakentavat niitä innokkaasti heti kun data ei mahdu siististi post meta -malliin. Totuus, kuten yleensä, ei ole mustavalkoinen.

Kyse ei ole vain teknisestä valinnasta. Kyse on arkkitehtuurista, suorituskyvystä, skaalautuvuudesta ja datan luonteesta.

WordPressin oletusmalli: kaikki on postaus

WordPressin tietomalli on elegantin radikaali. Lähes kaikki on postaus:

• sivut

• artikkelit

• custom post typet

• tuotteet

• tapahtumat

• portfolio-itemit

Lisädata tallennetaan:

• post meta -tauluun

• term meta -tauluun

• options-tauluun

Tämä tekee WordPressistä joustavan. Ei tarvitse skeemamuutoksia. Ei tarvitse migraatioita. Data vain… lisätään.

Mutta joustavuus ei ole ilmainen.

Milloin post meta alkaa hajota?

Post meta on loistava yleiskäyttöinen ratkaisu. Mutta se ei ole universaali tietokantarakenne.

Post meta alkaa muuttua ongelmalliseksi, kun:

• dataa on paljon

• kyselyt ovat monimutkaisia

• tarvitaan relaatioita

• suorituskyky on kriittinen

• data ei ole luonteeltaan “sisältöä”

Post meta on käytännössä key-value -varasto. Se ei ole optimoitu analyyttiseen tai rakenteellisesti raskaaseen dataan.

Klassinen oire: meta_query-helvetti

Kun järjestelmä alkaa sisältää:

• useita meta-ehtoja

• range-hakuja

• lajitteluja meta-arvojen mukaan

• aggregaatioita

SQL alkaa näyttää siltä kuin joku olisi pudottanut lautasellisen spagettia näppäimistölle.

Ja suorituskyky kärsii.

Custom-taulu: mitä oikeasti saadaan?

Custom database table ei ole vain “uusi paikka datalle”. Se on täysin eri tietomalli.

Custom-taulu tarjoaa:

• tarkasti määritellyn skeeman

• oikeat datatyypit

• indeksit

• tehokkaat kyselyt

• relaatiorakenteet

• skaalautuvuuden

Post meta on joustava. Custom-taulu on strukturoitu.

Kyse on kompromissista joustavuuden ja tehokkuuden välillä.

Milloin custom-taulu on järkevä?

Custom-taulu alkaa olla perusteltu ratkaisu, kun data on:

• määrällisesti suurta

• rakenteellisesti monimutkaista

• query-intensiivistä

• ei-luonteeltaan “postaus”

Esimerkkejä:

• logit

• analytiikka

• tapahtumastreamit

• transaktiodata

• relaatiopohjainen data

• suuret listat

• tilastot

• rankingit

• käyttäytymisdata

Post meta ei ole suunniteltu miljoonien rivien tehokkaaseen käsittelyyn.

Custom-taulu on.

Suorituskyky: elephant in the server room

Tietokantarakenne on suorituskykyarkkitehtuuria.

Post meta -mallissa jokainen haku tarkoittaa usein:

• useita join-operaatioita

• string-pohjaisia vertailuja

• indeksirajoitteita

Custom-taulussa:

• oikeat sarakkeet

• oikeat indeksit

• oikeat datatyypit

Tietokanta tekee sen, missä se on hyvä.

Skaalautuvuus ei ole teoreettinen ongelma

Pienessä projektissa post meta toimii lähes aina.

Kun data kasvaa:

• queryt hidastuvat

• CPU kuormittuu

• välimuisti alkaa paikata arkkitehtuuria

Custom-taulu ei ole optimointi. Se on joskus välttämättömyys.

Datan semantiikka: kaikki ei ole sisältöä

WordPressin postausmalli on sisältökeskeinen.

Mutta kaikki data ei ole sisältöä.

Esimerkiksi:

• käyttäjäaktiviteetit

• API-vastaukset

• sensoridata

• laskennalliset tulokset

• tilastot

• session data

Näiden mallintaminen postauksiksi on usein semanttisesti kömpelöä.

Custom-taulu antaa datalle oman identiteetin.

Relaatiot: post meta vs oikea tietomalli

Post meta ei ole relaatiomalli. Se on attribuuttivarasto.

Jos tarvitset:

• monimutkaisia suhteita

• viittauksia

• aggregaatioita

• tehokkaita join-kyselyitä

Custom-taulu alkaa näyttää houkuttelevalta.

Tietokannat on suunniteltu relaatiodatalle. Post meta on kompromissi.

Miksi custom-tauluja vältellään?

Koska ne tuovat vastuuta.

Post meta:

• ei vaadi skeemasuunnittelua

• ei vaadi migraatioita

• ei vaadi versiokontrollia rakenteelle

Custom-taulu:

• vaatii skeeman

• vaatii päivityslogiikan

• vaatii uninstall-logiikan

• vaatii indeksisuunnittelun

• vaatii ylläpidon

Custom-taulu on arkkitehtuuripäätös, ei koodikikka.

Ekosysteemin yhteensopivuus

WordPressin oletusrakenne toimii suoraan:

• WP_Queryn kanssa

• REST API:n kanssa

• admin-näkymien kanssa

• core-työkalujen kanssa

Custom-taulu:

• ei integroidu automaattisesti

• vaatii oman querylogiikan

• vaatii oman API-kerroksen

• vaatii oman admin-logiikan

Saat suorituskykyä. Menetät automaatiota.

Hybridimallit: yleinen käytännön ratkaisu

Monet kypsät WordPress-arkkitehtuurit käyttävät hybridimallia.

Postaukset:

• sisältö

• URLit

• editori

• käyttöliittymä

Custom-taulu:

• raskas data

• logit

• analytiikka

• relaatiorakenteet

Tämä yhdistää WordPressin UX-edut ja tietokannan tehokkuuden.

Klassinen väärinkäyttö: custom-taulu ilman syytä

Custom-taulu ei ole automaattisesti “parempi”.

Huono perustelu:

• “Haluan tehdä tämän oikein”

Hyvä perustelu:

• “Post meta ei skaalaudu tähän käyttötapaukseen”

Yksinkertainen data + custom-taulu = turha kompleksisuus.

Tulevaisuusajattelu vs premature optimization

Yksi vaikeimmista kysymyksistä:

Optimoidaanko tulevaisuutta varten vai nykytilaa varten?

Liian aikainen custom-taulu:

• lisää kompleksisuutta

• hidastaa kehitystä

• kasvattaa ylläpitokustannuksia

Liian myöhäinen custom-taulu:

• suorituskykyongelmia

• migraatio-ongelmia

• teknistä velkaa

Kyse ei ole säännöstä. Kyse on kontekstista.

Lopuksi: custom-taulu on datamallipäätös

Custom database table ei ole WordPress-temppu. Se on tietomallipäätös.

Se kysyy:

• millaista dataa käsittelemme?

• kuinka paljon dataa tulee?

• miten dataa haetaan?

• miten data kasvaa?

• mikä on suorituskykyvaatimus?

Post meta on joustava yleisratkaisu.

Custom-taulu on spesialisoitu työkalu.

Hyvä arkkitehtuuri ei kysy:
“Kumpi on parempi?”

Hyvä arkkitehtuuri kysyy:
“Kumpi sopii tähän ongelmaan?”

Ja juuri siinä kohtaa WordPress-kehitys muuttuu koodauksesta systeemiajatteluksi.

WordPress-kehityksessä törmää ennemmin tai myöhemmin hetkeen, jolloin pitäisi koskea tiedostojärjestelmään. Kirjoittaa tiedosto. Lukea tiedosto. Päivittää tiedosto. Ja juuri siinä kohtaa moni kehittäjä tekee klassisen PHP-refleksin:

file_put_contents() ja menoksi.

Teknisesti toimii. Arkkitehtuurisesti… ei aina.

WordPress Filesystem API on WordPressin oma abstraktiokerros tiedostojärjestelmän käsittelyyn. Se ei ole olemassa siksi, että core-kehittäjät olisivat päättäneet tehdä elämästä monimutkaisempaa. Se on olemassa, koska web-palvelinympäristöt ovat kaoottisia, epäyhtenäisiä ja toisinaan suorastaan eksistentiaalisen epäluotettavia.

Filesystem API on WordPressin tapa sanoa:

“Emme luota siihen, että tiedostojärjestelmä toimii kuten odotat.”

Miksi suora tiedostokäsittely ei riitä?

PHP:n perusfunktiot olettavat tietynlaisen ympäristön:

• oikeat käyttöoikeudet

• suora levyaccess

• ei erikoisia hosting-rajoitteita

Todellisuus WordPress-maailmassa:

• FTP-only -hosting

• omituiset permissionit

• container-ympäristöt

• read-only -tiedostojärjestelmät

• SELinux-iloittelut

Suora tiedostokäsittely toimii täydellisesti omalla kehityskoneella ja hajoaa asiakkaan tuotantopalvelimella kuin posliinikuppi betonilattialla.

Filesystem API ratkaisee tämän abstraktiolla.

Filesystem API:n perusidea

Filesystem API ei käsittele tiedostoja suoraan. Se delegoi.

WordPress valitsee ympäristön perusteella sopivan metodin:

• Direct (suora levyaccess)

• FTP

• FTPS

• SSH2

Koodi ei muutu. Toteutus muuttuu.

Tämä on klassinen ohjelmistoarkkitehtuurin temppu: erotetaan “mitä tehdään” ja “miten tehdään”.

Kehittäjän näkökulmasta

Kun käytät Filesystem APIa, et sano:

“Kirjoita tämä tiedosto levylle.”

Sanot:

“WordPress, hoida tämä tavalla, joka toimii tässä ympäristössä.”

Se on käytännössä portability-kerros.

Filesystem API:n käyttö käytännössä

Filesystem API:n käyttö sisältää aina pienen seremonian. Tämä ei ole sattumaa – kyse on turvallisuudesta ja yhteensopivuudesta.

Tyypillinen virta:

1. Pyydä Filesystem-objekti

2. WordPress varmistaa käyttöoikeudet

3. Filesystem-metodi valitaan

4. Operaatiot suoritetaan

Tärkeä pointti: Filesystem API voi vaatia käyttäjältä tunnistetietoja.

Ei bugi. Feature.

Jos WordPress tarvitsee FTP-yhteyden, sen on saatava tunnukset.

Miksi tämä tuntuu joskus kömpelöltä?

Koska olemme tottuneet suoraan kontrolliin.

Suora PHP-ajattelu:

• kutsu funktiota

• tiedosto syntyy

Filesystem API -ajattelu:

• pyydä abstraktiokerrosta

• odota mahdollisia tunnuskyselyitä

• käsittele useita toteutuspolkuja

Se tuntuu hitaammalta, raskaammalta, byrokraattisemmalta.

Mutta se toimii ympäristöissä, joissa suora levyaccess ei ole mahdollista.

Ja WordPress elää juuri tällaisissa ympäristöissä.

Filesystem API ja turvallisuus

Filesystem API ei ole vain yhteensopivuuskerros. Se on myös turvakerros.

Se auttaa:

• käyttöoikeuksien hallinnassa

• virheiden käsittelyssä

• ympäristöriippuvuuksien abstrahoinnissa

Suora tiedostokäsittely voi:

• epäonnistua hiljaisesti

• rikkoa permissionit

• ohittaa WordPressin logiikan

Filesystem API toimii WordPressin ekosysteemin sisällä.

Se kunnioittaa järjestelmän sääntöjä.

Direct vs FTP: näkymätön ero

Kun kaikki toimii, Filesystem API käyttää usein Direct-metodia. Tämä näyttää identtiseltä suoran PHP:n kanssa.

Mutta kun Direct ei ole mahdollinen…

WordPress vaihtaa strategiaa.

Tämä on Filesystem API:n suurin vahvuus. Koodi ei tarvitse if-helvettiä:

“Jos FTP-ympäristö → tee näin…”

WordPress hoitaa tämän.

Yleisimmät käyttötapaukset

Filesystem API on erityisen hyödyllinen:

• lisäosien päivityksissä

• teemojen päivityksissä

• cache-tiedostojen kirjoituksessa

• dynaamisessa tiedostogeneroinnissa

• export/import -toiminnoissa

Erityisesti tilanteissa, joissa koodi päätyy tuntemattomiin hosting-ympäristöihin.

Eli käytännössä aina.

Klassiset kompastuskivet

Filesystem API -ongelmat eivät yleensä ole API-ongelmia, vaan odotusongelmia.

Esimerkiksi:

• oletetaan Direct-access

• ei käsitellä virhetiloja

• ei ymmärretä credential-flow’ta

• kirjoitetaan väärään hakemistoon

Filesystem API ei ole “vain file wrapper”. Se on järjestelmä.

Ja järjestelmät vaativat ajattelumallin muutoksen.

Filesystem API ja arkkitehtuurinen ajattelu

Filesystem API on hyvä muistutus yhdestä tärkeästä periaatteesta:

Ympäristö ei ole vakio.

Web-kehityksessä tämä on lähes universaali totuus. Filesystem API sisäänrakentaa tämän epävarmuuden WordPressiin.

Se ei oleta. Se adaptoituu.

Ja se on harvinaisen kypsä design-valinta alustalta, jota joskus syytetään vanhanaikaisuudesta.

Lopuksi: Filesystem API ei ole ylimääräinen kerros

Filesystem API voi tuntua turhalta lisätyöltä.

Kunnes se pelastaa projektin.

Se on infrastruktuurikerros, joka ratkaisee ongelmia, joita ei näe kehitysympäristössä. Se on WordPressin tapa selviytyä villissä hosting-ekosysteemissä.

Filesystem API ei ole monimutkaisuutta monimutkaisuuden vuoksi.

Se on realismia.

Web ei ole laboratorio. Web on viidakko.

Ja Filesystem API on WordPressin machete.

WordPressin Hooks-järjestelmä on yksi niistä mekanismeista, jotka tekevät koko alustan mahdolliseksi. Ilman hookeja WordPress olisi pelkkä monoliitti: jäykkä, suljettu ja nopeasti vanheneva. Hookit muuttavat kaiken. Ne tekevät WordPressistä tapahtumavetoisen järjestelmän, jossa logiikka ei ole vain “mitä tapahtuu”, vaan ennen kaikkea “milloin tapahtuu”.

Ja juuri tässä kohtaa alkaa se osa, joka aiheuttaa kehittäjille lievää eksistentiaalista levottomuutta: suoritusjärjestys ja sivuvaikutukset.

Hookit eivät ole vaikeita siksi, että ne olisivat monimutkaisia. Ne ovat vaikeita siksi, että ne muuttavat ajattelumallia. Lineaarinen ohjelmointi vaihtuu tapahtumien orkesteriin.

Hook ei ole funktio, vaan ajallinen piste

Hook ei ole koodi. Hook on hetki.

WordPress ei sano: “Suorita tämä funktio.”
WordPress sanoo: “Tässä kohtaa elinkaarta tapahtuu jotain. Jos joku haluaa reagoida, nyt on tilaisuus.”

Tämä on fundamentaalinen ero. Hookit eivät ole suorituspolkuja, vaan reaktiopisteitä. Kun tämän sisäistää, WordPressin sisäinen logiikka alkaa näyttää vähemmän mystiseltä ja enemmän biologiselta. Järjestelmä sykkii, tapahtumat laukeavat, callbackit reagoivat.

WordPress ei ole lineaarinen ohjelma. Se on tapahtumakenttä.

Suoritusjärjestys: determinismi ilman kaaosta

Hook-järjestelmä voi ulkopuolelta näyttää kaoottiselta. Callbackeja tulee lisäosista, teemoista, coresta ja joskus jopa käyttäjän omasta koodista. Silti järjestelmä ei ole kaoottinen. Se on täysin deterministinen.

Suoritusjärjestys perustuu priority-arvoihin. Callbackit ajetaan numerojärjestyksessä. Pienempi numero tarkoittaa aikaisempaa suoritusta.

Tämä on puhdasta logiikkaa. Ei arpapeliä. Ei satunnaisuutta.

Kaaoksen tunne syntyy siitä, että harvoin tiedämme kaikkia osallistujia. Hook-järjestelmä on kuin kokous, jossa huoneeseen voi astella uusia puhujia kesken keskustelun.

Priority: ajallinen säätöruuvi

Priority ei tarkoita tärkeyttä. Se tarkoittaa ajoitusta.

Kun asetat priorityksi 5, sanot:
“Tämä tapahtuu aikaisemmin.”

Kun asetat priorityksi 999, sanot:
“Tämä tapahtuu lähes kaiken jälkeen.”

Priority on ajallinen säätöruuvi. Se ei arvota logiikkaa, vaan sijoittaa sen aikaan.

Tämä saattaa tuntua triviaalilta, mutta käytännössä priorityt ovat WordPress-arkkitehtuurin näkymätön kieli. Ne kertovat riippuvuuksista, oletuksista ja joskus epätoivosta.

WordPressin elinkaari: hookien aikajana

WordPress ei vain “aja koodia”. Se kulkee elinkaaren läpi.

Karkeasti ajateltuna:

• ympäristö käynnistyy

• lisäosat latautuvat

• teema latautuu

• query rakennetaan

• sisältö renderöidään

• response lähetetään

Hookit ovat sijoitettu tähän aikajanaan. Jokainen hook edustaa hetkeä tässä virrassa.

Tämä tarkoittaa, että hookien ymmärtäminen on ajallista kartoitusta. Et vain kysy, mitä hook tekee. Kysyt, missä kohtaa universumia se tapahtuu.

Filterit: funktionaalinen illuusio

Filterit näyttävät puhtailta. Data sisään, data ulos.

Arvo kulkee callbackien läpi kuin esine liukuhihnalla. Jokainen filter muokkaa sitä hieman.

Tämä on kaunis, lähes funktionaalinen malli.

Todellisuus on usein… vähemmän puhdas.

Filter voi tehdä tietokantakyselyn. Filter voi muuttaa globaalia tilaa. Filter voi rekisteröidä uusia hookeja. Filter voi aiheuttaa sivuvaikutuksia, jotka eivät liity alkuperäiseen arvoon millään tavalla.

Filteristä tulee hybridiolento: osa transformaatio, osa toiminto.

Sivuvaikutusten syntymekanismi

Sivuvaikutus syntyy, kun callback tekee jotain muuta kuin palauttaa arvon.

Se voi:

• muuttaa globaalia muuttujaa

• päivittää asetuksia

• tehdä I/O-operaatioita

• käynnistää uusia hookeja

Tämä ei ole sinänsä väärin. Mutta se muuttaa järjestelmän luonnetta.

Filter ei ole enää vain datan muokkaaja. Se on järjestelmän manipuloija.

Actionit: sivuvaikutusten kotikenttä

Actionit ovat luonteeltaan sivuvaikutuspohjaisia. Ne eivät palauta arvoa. Ne tekevät asioita.

Ja tässä kohtaa hook-järjestelmä alkaa muistuttaa enemmän fysiikkaa kuin ohjelmointia.

Action ei vain suorita logiikkaa. Se voi muuttaa koko järjestelmän tilaa.

Se voi:

• lisätä uusia callbackeja

• poistaa callbackeja

• muuttaa queryä

• vaikuttaa renderöintiin

• käynnistää uusia tapahtumia

Hookit eivät ole pelkkä suoritusmekanismi. Ne ovat dynaamisen järjestelmän ohjausverkko.

Emergentti käyttäytyminen: kun kokonaisuus alkaa elää omaa elämäänsä

Kun useita lisäosia käyttää hookeja, syntyy emergenssiä.

Emergenssi tarkoittaa ilmiötä, jossa järjestelmän käyttäytyminen ei ole suoraan pääteltävissä yksittäisistä komponenteista.

Lisäosa A muokkaa queryä.
Lisäosa B lisää meta-ehtoja.
Lisäosa C muuttaa järjestystä.

Lopputulos on query, jota kukaan ei suunnitellut kokonaisuutena.

Tämä on modulaarisuuden luonnollinen seuraus. Hook-järjestelmä tekee tästä mahdollisen.

Ja samalla… joskus painajaismaisen.

Sivuvaikutusten näkymätön verkosto

Sivuvaikutukset ovat hook-järjestelmän varjopuoli.

Callback voi vaikuttaa:

• myöhemmin ajettavaan logiikkaan

• toisen lisäosan käyttäytymiseen

• WordPressin sisäiseen tilaan

• täysin eri kontekstiin

Tämä tekee järjestelmästä voimakkaan mutta vaikeasti hahmotettavan.

Koodi ei ole enää lineaarinen kertomus. Se on verkosto vaikutuksia.

Globaali tila: WordPressin perusrealiteetti

WordPress käyttää paljon globaalia tilaa. Tämä ei ole vahinko. Se on historiallinen ja pragmaattinen design-valinta.

Hookit operoivat usein globaalin tilan päällä.

Kun callback muuttaa $wp_query-objektia, vaikutus ei rajoitu yhteen funktioon. Se voi muuttaa koko renderöintiketjun.

Sivuvaikutukset eivät ole poikkeus. Ne ovat normaali tila.

Reentranssi ja rekursio: hookien syvempi kerros

Hook-järjestelmä mahdollistaa tilanteet, joissa callback laukaisee hookin, joka laukaisee callbackin, joka laukaisee hookin.

Järjestelmä voi kutsua itseään epäsuorasti.

Tämä ei ole virhe. Mutta se vaatii kurinalaisuutta.

Ilman huolellista suunnittelua syntyy klassinen loputon silmukka, joka kuluttaa CPU:n kuin nälkäinen musta aukko.

Hookit eivät estä rekursiota. Ne mahdollistavat sen.

Suoritusjärjestys ja odotusten törmäys

Yksi yleisimmistä hook-ongelmista ei ole tekninen vaan psykologinen.

Callback olettaa, että:

• jokin arvo on tietyssä tilassa

• jokin muutos on jo tehty

• jokin logiikka ei ole vielä ajettu

Kun nämä oletukset eivät täsmää, syntyy bugi.

Hook-järjestelmä tekee ajasta osan ohjelmalogiikkaa.

Virhe ei ole vain väärä arvo. Virhe voi olla väärä hetki.

Priority-sota: kehittäjän selviytymisstrategia

Kun callbackit törmäävät, priority-arvoista tulee aseita.

Priority 10 ei toimi.
Priority 20 ei toimi.
Priority 999 toimii.

Teknisesti ratkaisu. Rakenteellisesti oire.

Priorityt ovat usein implisiittisiä riippuvuuksia. Ne kertovat, että logiikka tarvitsee tietyn ajallisen kontekstin.

Liiallinen priority-kikkailu on merkki siitä, että järjestelmässä käydään näkymätöntä neuvottelua.

Hookit ja suorituskyky: pieni overhead, suuri kertymä

Hook-järjestelmä itsessään on kevyt. Mutta jokainen hook lisää hieman työtä.

Kun järjestelmässä on:

• satoja hookeja

• tuhansia callbackeja

• raskasta logiikkaa

syntyy kertymä.

Yksittäinen callback ei ole ongelma. Ekosysteemi voi olla.

Raskas logiikka väärässä paikassa

Callback, joka tekee raskaan tietokantakyselyn hookissa, joka ajetaan jokaisella pyynnöllä, on suorituskykypommi.

Hook ei ole ongelma. Ajoitus on.

WordPressin suorituskykyongelmat ovat usein ajallisia virheitä, eivät laskennallisia.

Debuggaus: miksi hook-bugit tuntuvat niin liukkailta?

Koska syy ja seuraus eivät ole vierekkäin.

Virhe voi syntyä:

• callbackissa A

• näkyä callbackissa B

• laukaistua hookissa C

Hook-järjestelmä hajauttaa logiikan.

Bugia ei löydy yhdestä rivistä. Se löytyy vuorovaikutuksesta.

Hook-bugit ovat systeemisiä ilmiöitä.

Hookien kognitiivinen malli

Hookit pakottavat ajattelemaan ohjelmointia tapahtumina.

Imperatiivinen ajattelu:
“Tee tämä, sitten tuo.”

Hook-ajattelu:
“Kun tämä tapahtuu, tee tuo.”

Se on reaktiivinen malli.

Kun tämän hyväksyy, hookit lakkaavat olemasta mystisiä ja alkavat tuntua luonnollisilta.

WordPress ei ole skripti. Se on tapahtumamoottori.

Sivuvaikutusten hallinta: arkkitehtuurinen kypsyys

Sivuvaikutuksia ei voi poistaa. Mutta niitä voi hallita.

Kypsä hook-käyttö tarkoittaa:

• oletusten minimointia

• globaalin tilan kunnioittamista

• ajallisen kontekstin ymmärtämistä

• callbackien eristämistä

Hookit eivät ole temppuja. Ne ovat arkkitehtuuria.

Hookien paradoksi

Hookit tekevät WordPressistä:

• laajennettavan

• joustavan

• modulaarisen

Ja samalla:

• vaikeasti ennustettavan

• vaikeasti debugattavan

• emergentisti kompleksisen

Tämä ei ole ristiriita. Tämä on hinta.

Modulaarisuus ei poista kompleksisuutta. Se hajauttaa sen.

Lopuksi: hookit ovat järjestelmän kieli

Kun hook-järjestelmän näkee WordPressin sisäisenä kielenä, moni asia kirkastuu.

Hookit eivät ole lisäominaisuus. Ne ovat infrastruktuuri.

Suoritusjärjestys ei ole tekninen detalji. Se on ajallinen logiikka.

Sivuvaikutukset eivät ole virheitä. Ne ovat dynaamisen järjestelmän luonnollinen seuraus.

WordPress ei ole kone, joka suorittaa rivejä. Se on ekosysteemi, jossa tapahtumat, callbackit ja tila muodostavat jatkuvasti muuttuvan verkoston.

Hookit ovat tämän verkoston hermosignaalit.

Joskus harmonisia. Joskus kaoottisia. Mutta aina loogisia.

Ja kun logiikka ymmärretään, musta magia katoaa. Jäljelle jää järjestelmä, joka on yhtä aikaa insinööritiedettä ja emergenttiä käyttäytymistä.

Hieman kuin ohjelmisto. Hieman kuin elämä.

WordPressin Hooks-järjestelmä on kuin näkymätön hermosto, joka yhdistää koko sovelluksen. Ilman hookeja WordPress olisi jäykkä, vaikeasti laajennettava ja käytännössä modernin ekosysteemin vastakohta. Hookit tekevät WordPressistä sen, mitä se on: modulaarisen, muokattavan ja välillä… hämmentävän.

Hookien ymmärtäminen ei ole vain WordPress-kehittäjän perustaito. Se on lähes kognitiivinen siirtymä. Kun sisäistää, miten suoritusjärjestys toimii ja millaisia sivuvaikutuksia syntyy, koko järjestelmä alkaa näyttää paljon vähemmän mystiseltä.

Ja paljon enemmän loogiselta.

Mikä hook oikeastaan on?

Hook on tapahtumapiste.

WordPress sanoo:
“Tässä kohtaa suoritusvirtaa tapahtuu jotain. Haluatko tehdä jotain mukana?”

Hookit jakautuvat kahteen päätyyppiin:

• action

• filter

Action tekee asioita.
Filter muokkaa asioita.

Käytännössä molemmat ovat callback-mekanismeja, mutta semanttinen ero on tärkeä.

Suoritusjärjestys: kuka ehtii ensin?

Kun useita callbackeja kiinnitetään samaan hookiin, WordPress tarvitsee järjestyksen. Tätä varten käytetään priority-arvoa.

Priority:

• pienempi numero → suoritetaan ensin

• suurempi numero → suoritetaan myöhemmin

• oletus → 10

Callbackien suoritusjärjestys ei ole sattumaa. Se on deterministinen.

Priority ei ole “tärkeys”

Tämä on yleinen väärinkäsitys.

Priority ei tarkoita:

“Tämä funktio on tärkeämpi.”

Se tarkoittaa:

“Tämä funktio ajetaan aikaisemmin.”

Kyse on ajallisesta järjestyksestä, ei arvottamisesta.

Determinismi ja illuusio kaaoksesta

Hook-järjestelmä voi näyttää kaoottiselta, koska:

• callbackit tulevat eri lisäosista

• callbackit voivat muokata samoja arvoja

• callbackit voivat lisätä uusia hookeja

• callbackit voivat poistaa hookeja

Silti järjestelmä on täysin deterministinen.

Jos tunnet:

• hookin

• callbackit

• priorityt

voit ennustaa kaiken.

Kaaos on usein vain näkyvyyden puutetta.

Filterit ja datan mutaatio

Filterit muodostavat suoritusketjun.

Data kulkee:

arvo → filter 1 → filter 2 → filter 3 → lopputulos

Jokainen filter:

• vastaanottaa arvon

• muokkaa sitä

• palauttaa sen

Tämä on funktionaalinen malli.

Sivuvaikutusten synty

Ongelmat alkavat, kun filter ei olekaan puhtaasti funktionaalinen.

Puhtaan filterin idea:

• ei muuta globaalia tilaa

• ei tee I/O-operaatioita

• palauttaa vain muokatun arvon

Todellisuus:

• tietokantakyselyitä

• globaaleja muuttujia

• sivuvaikutuksia

• logiikkaa, joka vaikuttaa muuhun järjestelmään

Filteristä tulee mini-action.

Ja tästä seuraa yllätyksiä.

Actionit ja järjestelmän dynamiikka

Actionit eivät palauta arvoa. Ne suorittavat toimintoja.

Esimerkiksi:

• enqueue script

• logitus

• asetusten päivitys

• session manipulointi

Actionit ovat luonteeltaan sivuvaikutuspohjaisia.

Tämä on täysin normaalia.

Actionit voivat muuttaa tulevaa suoritusvirtaa

Tässä kohtaa hook-järjestelmä muuttuu todella kiinnostavaksi.

Action voi:

• lisätä uusia hookeja

• poistaa hookeja

• muuttaa globaalia tilaa

• vaikuttaa tuleviin filtereihin

Hook-järjestelmä ei ole vain lineaarinen ketju. Se on verkosto.

Suoritusjärjestys ja emergenssi

Kun useita lisäosia käyttää hookeja, syntyy emergenttiä käyttäytymistä.

Emergenssi tarkoittaa:

Kokonaisuus tekee asioita, joita yksittäiset osat eivät suoraan ennusta.

Esimerkki:

• Lisäosa A muokkaa queryä

• Lisäosa B lisää meta-queryn

• Lisäosa C muuttaa orderby-logiikkaa

Lopputulos:

Query, jota kukaan yksittäinen kehittäjä ei suunnitellut.

Tämä ei ole bugi. Tämä on modulaarisuuden luonnollinen seuraus.

Priority-sota: klassinen kehittäjäilmiö

Kun callbackit törmäävät, priority-arvoista tulee strateginen työkalu.

Tyypillinen kehityskaari:

Priority 10 → ei toimi
Priority 20 → edelleen ei
Priority 999 → nyt toimii

Teknisesti validi. Arkkitehtuurisesti huolestuttava.

Priorityt ovat riippuvuuksien ilmaus

Kun käytät korkeaa prioritya, sanot implisiittisesti:

“Tämän pitää tapahtua muiden jälkeen.”

Se on piilotettu riippuvuus.

Liiallinen priority-kikkailu on usein merkki rakenteellisesta ongelmasta.

Hookien sivuvaikutukset: näkymätön kompleksisuus

Hook-järjestelmä tuo mukanaan erikoisen haasteen:

Koodi ei ole enää lineaarisesti luettavissa.

Funktio voi vaikuttaa:

• kaukana olevaan logiikkaan

• tulevaan suoritusvaiheeseen

• toisen lisäosan käyttäytymiseen

Tämä tekee debuggaamisesta psykologisesti vaikeampaa.

Virta ei ole näkyvä.

Globaali tila: hookien polttoaine ja kirous

WordPress käyttää paljon globaalia tilaa:

• $post

• $wp_query

• $wpdb

• kontekstuaaliset muuttujat

Hookit manipuloivat usein tätä tilaa.

Tämä on tehokasta.

Ja riskialtista.

Sivuvaikutusten klassinen malli

Callback:

• muuttaa globaalia muuttujaa

• toinen callback olettaa alkuperäisen tilan

• syntyy outo bugi

Hook-järjestelmä tekee globaalista tilasta dynaamisen pelikentän.

Hookit ja suorituskyky

Hook-järjestelmä ei ole ilmainen.

Jokainen hook:

• käy callback-listan läpi

• suorittaa funktiot

• käsittelee priorityt

Useimmiten overhead on minimaalinen.

Mutta mittakaavassa:

• kymmeniä lisäosia

• satoja hookeja

• raskaita callbackeja

syntyy kertymä.

Raskas logiikka väärässä hookissa

Yksi yleisimmistä suorituskykyvirheistä:

Raskas operaatio hookissa, joka ajetaan usein.

Esimerkiksi:

• init

• wp

• the_content

Hook ei ole ongelma. Sijoittelu on.

Hookien ajallinen psykologia

Hook-järjestelmä pakottaa ajattelemaan aikaa.

Ei vain “mitä tapahtuu”, vaan:

“Milloin tämä tapahtuu?”

Tämä on olennainen ajattelutavan muutos.

Imperatiivinen ajattelu:

Suorita A → B → C

Hook-ajattelu:

Kun X tapahtuu → tee Y

Se on tapahtumapohjainen malli.

Debuggaus: miksi tämä tuntuu joskus painajaiselta?

Koska vaikutukset ovat hajautettuja.

Bugia ei löydy:

• yhdestä funktiosta

• yhdestä tiedostosta

• yhdestä lisäosasta

Se löytyy:

• callbackien vuorovaikutuksesta

• suoritusjärjestyksestä

• sivuvaikutuksista

Hook-bugit ovat usein systeemisiä.

Hookien elegantti voima

Kaikesta kompleksisuudesta huolimatta Hooks-järjestelmä on WordPressin suurimpia vahvuuksia.

Se mahdollistaa:

• laajennettavuuden

• yhteensopivuuden

• modulaarisuuden

• ekosysteemin räjähdysmäisen kasvun

Ilman hookeja WordPress ei olisi WordPress.

Lopuksi: hookit ovat arkkitehtuuria, eivät temppuja

Hookeja voi käyttää kahdella tavalla.

Temppuina:

• “Lisätään tämä tähän, koska toimii”

Tai arkkitehtuurina:

• “Tämä logiikka kuuluu tähän tapahtumapisteeseen”

Kun hook-järjestelmän näkee tapahtumavirran mallina, mystiikka katoaa. Jäljelle jää järjestelmä, joka on täysin looginen, mutta vaatii ajallista ajattelua.

WordPress ei ole lineaarinen ohjelma. Se on tapahtumien orkesteri.

Hookit ovat kapellimestarin eleet.

Ja sivuvaikutukset? Ne ovat musiikin luonnollinen seuraus.

Joskus harmonisia. Joskus… jazzia.

WordPressissä tapahtuu jatkuvasti asioita, joita käyttäjä ei näe. Sivut latautuvat, skriptit suorittavat tehtäviään, ja taustalla pyörii pieniä mekanismeja, jotka pitävät järjestelmän hengissä. Yksi näistä hiljaisista työmyyristä on Heartbeat API.

Nimi kuulostaa dramaattiselta, ja jollain tavalla se onkin osuva. Heartbeat API on kirjaimellisesti WordPressin syke. Se on järjestelmä, joka lähettää säännöllisiä signaaleja selaimen ja palvelimen välillä.

Ei näyttävä. Ei glamouria. Mutta ratkaisevan tärkeä.

Mikä Heartbeat API oikeastaan on?

Heartbeat API on JavaScript-pohjainen mekanismi, joka lähettää AJAX-pyyntöjä palvelimelle säännöllisin väliajoin. Ajatus on yksinkertainen:

Selain sanoo: “Hei palvelin, olen edelleen täällä.”
Palvelin vastaa: “Hyvä. Tässä hieman dataa takaisin.”

Tämä tapahtuu yleensä 15–60 sekunnin välein riippuen kontekstista.

Heartbeat ei ole virhe, ei bugi eikä mystinen kuormituspiikki. Se on design-valinta.

Miksi WordPress tarvitsee “sykettä”?

Moderni web ei ole enää staattinen dokumenttikokoelma. Se on jatkuvaa vuorovaikutusta.

WordPress käyttää Heartbeat APIa muun muassa:

• autosave-toimintoihin

• editorin lukituksiin

• sessionhallintaan

• ilmoituksiin

• reaaliaikaiseen synkronointiin

Ilman Heartbeat APIa monet tutut toiminnot lakkaisivat olemasta “reaaliaikaisia”.

Autosave – näkymätön henkivakuutus

Kun kirjoitat artikkelia ja selain kaatuu, autosave pelastaa päivän. Heartbeat API:

• lähettää luonnoksen palvelimelle

• tekee tämän automaattisesti

• estää työn katoamisen

Autosave ei ole vain mukavuus. Se on katastrofienhallintaa.

Editorin lukitus: kuka muokkaa mitä?

WordPressin editorissa näkyvä ilmoitus:

“Tätä artikkelia muokkaa toinen käyttäjä”

on Heartbeat API:n ansiota.

Heartbeat:

• tarkistaa, kuka on aktiivinen

• päivittää lukitustiedot

• estää päällekkäiset muokkaukset

Ilman tätä syntyisi klassinen yhteistyöhelvetti:

“Kuka tallensi päälle?”

Reaaliaikaisuus ilman WebSocketteja

Heartbeat API on tavallaan WordPressin “kevyt reaaliaikaisuus”.

Se ei ole jatkuva avoin yhteys kuten WebSocket, vaan:

• jaksottainen kommunikaatio

• riittävän nopea UX:n kannalta

• huomattavasti yksinkertaisempi infrastruktuuriltaan

Pragmaattinen ratkaisu. Hyvin WordPressmäinen.

Heartbeat ja suorituskyky

Tässä kohtaa alkaa usein paniikki.

“Heartbeat kuormittaa palvelinta!”
“Heartbeat tappaa CPU:n!”
“Heartbeat tekee sivustosta hitaan!”

Totuus on vähemmän dramaattinen ja enemmän kontekstisidonnainen.

Heartbeat API:

• on kevyt per pyyntö

• mutta tapahtuu säännöllisesti

• ja kertyy mittakaavassa

Yksi pyyntö ei ole ongelma. Sata käyttäjää voi olla.

Kuormituksen psykologia

Heartbeat-ongelmat eivät yleensä johdu siitä, että Heartbeat olisi huonosti suunniteltu.

Ne johtuvat siitä, että:

• liikenne kasvaa

• hosting on rajallinen

• lisäosat lisäävät omaa logiikkaansa heartbeat-kutsuihin

Heartbeat toimii kuten pitää. Ympäristö ei aina pysy mukana.

Miksi Heartbeat tuntuu joskus “turhalta”?

Koska se on näkymätön.

Kun selain lähettää heartbeat-pyynnön:

• mitään ei näy

• mitään ei muutu visuaalisesti

• käyttäjä ei koe hyötyä

Silti taustalla tapahtuu asioita:

• session päivitykset

• lukitukset

• autosave

• ilmoitukset

Ihmismieli arvostaa näkyviä asioita. Heartbeat on infrastruktuuria.

Heartbeat API ja lisäosat

Heartbeat API on laajennettavissa. Lisäosat voivat:

• lisätä dataa pyyntöihin

• lukea vastauksia

• käyttää sykettä omiin tarkoituksiinsa

Tämä on voimakas ominaisuus.

Ja kuten aina voimakkaiden ominaisuuksien kanssa…

Se voidaan käyttää hyvin tai huonosti.

Klassinen ongelma: raskas heartbeat-logiikka

Jos lisäosa:

• suorittaa raskaita kyselyitä

• jokaisella heartbeat-kutsulla

• jokaiselle käyttäjälle

Heartbeat muuttuu nopeasti CPU-myllyksi.

Ongelma ei ole APIssa. Ongelma on logiikassa.

Heartbeat API vs “reaaliaikainen web”

Heartbeat ei ole oikea reaaliaikajärjestelmä.

Se on:

• polling-mekanismi

• jaksottainen tarkistus

• viiveellinen synkronointi

Mutta käytännössä se on usein riittävä.

Kaikki ei tarvitse millisekunnin tarkkuutta.

Autosave ei tarvitse. Editorilukitus ei tarvitse. Useimmat admin-toiminnot eivät tarvitse.

Heartbeat API ja sessionhallinta

Heartbeat toimii myös “elossaolotarkistuksena”.

Se auttaa WordPressiä ymmärtämään:

• onko käyttäjä aktiivinen

• onko sessio voimassa

• pitäisikö jotain päivittää

Ilman tätä monet asiat olisivat kömpelömpiä:

• vanhentuneet sessiot

• epäselvät lukitukset

• synkronointiongelmat

Heartbeat on hiljainen järjestyksenpitäjä.

Milloin Heartbeatista tulee ongelma?

Heartbeatista tulee ongelma, kun:

• käyttäjiä on paljon

• palvelinresurssit ovat rajalliset

• heartbeat-kutsuihin on liitetty raskasta logiikkaa

• admin-paneeli on jatkuvasti auki monella käyttäjällä

Heartbeat itsessään ei ole raskas. Kertymä on.

Skaalaus paljastaa kaiken

Monet WordPress-mekanismit toimivat täydellisesti pienessä mittakaavassa.

Heartbeat mukaan lukien.

Mutta kun:

• käyttäjiä on satoja

• admin on aktiivinen

• lisäosia paljon

Pienet toistuvat operaatiot alkavat näkyä.

Heartbeat API:n elegantti rooli

Heartbeat API edustaa WordPressin filosofiaa parhaimmillaan:

• yksinkertainen

• yhteensopiva

• laajennettava

• riittävän hyvä useimpiin tarpeisiin

Se ei ole teknologinen ihme. Se on käytännöllinen työkalu.

Lopuksi: Heartbeat ei ole vihollinen

Heartbeat API saa usein syyt niskoilleen, koska se on helppo kohde.

Se näkyy verkonvälilehdellä. Se näkyy lokissa. Se näkyy kuormituksessa.

Mutta Heartbeat on harvoin varsinainen ongelma.

Se on enemmänkin kuormituksen vahvistin. Se paljastaa:

• raskaan logiikan

• heikon hostingin

• huonon optimoinnin

• resurssirajat

Heartbeat ei riko järjestelmää. Se näyttää, missä järjestelmä jo valmiiksi on hauras.

Ja siinä on jotain lähes diagnostista kauneutta.

WordPressissä on monia suorituskykyyn vaikuttavia tekijöitä, joista osa on dramaattisia ja helposti havaittavia. Hitaat SQL-kyselyt. Raskaat lisäosat. Kuvien optimointi. Mutta sitten on tämä hiljainen, lähes näkymätön mekanismi, joka voi tehdä sivustosta tahmean ilman että mikään yksittäinen asia näyttää olevan rikki.

Autoloaded options.

Kyse ei ole bugista, vaan design-valinnasta. Ja juuri siksi se on kiinnostava.

Mikä autoloaded option oikeastaan on?

WordPress tallentaa asetukset wp_options-tauluun. Jokaisella optionilla on autoload-kenttä:

• autoload = yes

• autoload = no

Kun WordPress käynnistyy, se tekee jotain hyvin ratkaisevaa:

Se lataa kaikki autoload = yes -asetukset yhdellä kyselyllä muistiin.

Ajatus on elegantti. Jos jokin asetus tarvitaan lähes jokaisella sivulatauksella, sen hakeminen etukäteen on tehokasta.

Yksi kysely → kaikki tärkeä data.

Kaunis teoria.

Designin alkuperäinen tarkoitus

Autoload-järjestelmä on optimointi. Ei hidaste.

Se on tarkoitettu pienille, usein tarvittaville arvoille:

• sivuston nimi

• URL

• aktiiviset lisäosat

• teemaan liittyvät asetukset

Ilman autoloadia WordPress tekisi jatkuvasti pieniä lisäkyselyitä. Autoload niputtaa nämä yhteen.

Kun data on pientä → ratkaisu on loistava.

Kun data ei ole pientä → syntyy ongelma.

Näkymätön suorituskykysyöppö syntyy

Autoload ei kysy:

“Kuinka suuri tämä arvo on?”

Se kysyy vain:

“Ladataanko tämä aina?”

Jos lisäosa tallentaa massiivisen datarakenteen ja asettaa:

autoload = yes

WordPress lataa sen jokaisella pyynnöllä.

Myös silloin kun dataa ei käytetä.

Tässä kohtaa optimointi muuttuu painolastiksi.

Muistin kulutus kasvaa salakavalasti

Autoloaded options -data:

• ladataan aina

• pidetään muistissa koko pyynnön ajan

• vaikuttaa jokaiseen sivulataukseen

Tämä tarkoittaa:

• suurempi muistinkäyttö

• pidempi initialisaatio

• hitaampi TTFB (time to first byte)

Ja mikä petollisinta:

Yksittäinen option ei näytä dramaattiselta.

Ongelma on kertymä.

Kuinka ongelma syntyy käytännössä?

Tyypillinen skenaario:

Lisäosa tarvitsee tallennustilaa. Kehittäjä käyttää Options APIa. Kaikki toimii. Sitten data kasvaa.

Esimerkiksi:

• API-vastaukset

• välimuistit

• raportit

• logit

• massiiviset konfiguraatiot

Ja koska autoload = yes on usein oletus tai helppo valinta…

Boom.

Hiljainen suorituskykyeroosio.

Miksi tämä on niin vaikea havaita?

Autoloaded options -ongelmat ovat harvoin dramaattisia.

Ei virheilmoituksia. Ei kaatumisia. Ei selkeää savua konepellin alta.

Sen sijaan:

• sivusto tuntuu hitaammalta

• admin tuntuu tahmealta

• CPU-kuorma kasvaa

• muistirajat paukkuvat satunnaisesti

Se on kuin digitaalinen painonnousu. Ei huomaa päivässä, huomaa vuodessa.

Debuggaus on epämiellyttävän epäsuoraa

Kun sivusto hidastuu, epäily kohdistuu yleensä:

• tietokantaan

• lisäosiin

• hostingiin

• PHP-versioon

Harva ajattelee ensimmäisenä:

“Kuinka paljon autoloaded options -dataa ladataan?”

Silti usein juuri siellä piilee syyllinen.

Autoload ja TTFB:n psykologia

TTFB ei ole vain tekninen metriikka. Se on käyttäjäkokemuksen hermokeskus.

Autoloaded options vaikuttavat aivan pyynnön alkuun:

• WordPress käynnistyy

• options ladataan

• muisti täyttyy

• logiikka jatkuu

Jos autoload-data on massiivista, viive syntyy ennen kuin mitään näkyvää tapahtuu.

Käyttäjä kokee:

“Sivusto reagoi hitaasti.”

Vaikka HTML-generointi olisi nopeaa.

Klassinen antipattern: välimuisti options-taulussa

Yksi yleisimmistä virheistä:

Transienttien tai välimuistin tallentaminen optioniksi autoload = yes.

Välimuistin idea:

• dataa käytetään joskus

• data vanhenee

• dataa ei tarvita aina

Autoloadin idea:

• data tarvitaan aina

Näiden yhdistäminen on looginen ristiriita.

Silti sitä tapahtuu jatkuvasti.

Miksi kehittäjät päätyvät tähän ansaan?

Syyt ovat inhimillisiä.

Options API on:

• helppo

• nopea

• tuttu

• ei vaadi skeemasuunnittelua

Autoload:

• toimii oletuksena

• ei näytä vaaralliselta

• ei aiheuta välitöntä ongelmaa

Ja koska vaikutus näkyy vasta mittakaavassa…

Virhe on hiljainen.

Kuinka iso on “liian iso”?

Ei ole yhtä maagista rajaa, mutta käytännön havaintoja on.

Autoloaded options yhteensä:

• muutama kymmenen kilotavua → normaalia

• satoja kilotavuja → varoitusmerkki

• megatavuja → ongelma

• useita megatavuja → suorituskykykatastrofi

Muista: tämä ladataan joka pyynnöllä.

Etusivu. Admin. AJAX. REST.

Kaikki.

Autoload ja muistimalli

Kun autoloaded options ladataan:

• ne jäävät PHP-muistiin

• ne kopioidaan tarvittaessa

• ne vaikuttavat garbage collectioniin

Suurempi muistijalanjälki ei ole vain RAM-kysymys. Se vaikuttaa koko suorituksen dynamiikkaan.

Muisti ei ole neutraali resurssi.

Näkymätön kertymä: monta pientä syntiä

Todellinen ongelma ei usein ole yksi massiivinen option.

Se on:

• 200 keskikokoista optionia

• useita lisäosia

• vuosien kertymä

• uninstall-logiikan puute

WordPress-sivustot vanhenevat. Lisäosia vaihdetaan. Data jää.

Autoload ei unohda.

Autoload ja legacy-sivustot

Vanhoilla sivustoilla tämä on erityisen yleistä.

Historia:

• lisäosa asennettu 2018

• lisäosa poistettu 2020

• optionit jäljellä

• autoload = yes

WordPress lataa ne edelleen.

Digitaalinen kummitustalo.

Hyvä käytäntö: mitä autoloadiin kuuluu?

Autoloadiin kuuluu data, joka on:

• pieni

• usein tarvittu

• kriittinen lähes kaikille pyynnöille

Ei kuulu:

• välimuisti

• suuret datarakenteet

• harvoin käytetty data

• laskennalliset tulokset

Autoload on premium-muistia. Sinne ei dumpata kaikkea.

Arkkitehtuurinen ajattelutapa

Autoload ei ole vain tekninen flagi. Se on arkkitehtuuripäätös.

Kun asetat autoload = yes, sanot:

“Tämä data kuuluu jokaiselle sivulataukselle.”

Se on vahva väite.

Kannattaa olla varma.

Suorituskyvyn ironia

Autoload-järjestelmä on tehty nopeuttamaan WordPressiä.

Silti väärin käytettynä se on yksi yleisimmistä hidasteista.

Optimoinnista tulee pullonkaula.

Teknologian klassinen paradoksi.

Lopuksi: hitauden hiljainen ekosysteemi

WordPress-hitaus on harvoin yhden asian syy.

Se on ekosysteemi:

• hieman raskas teema

• muutama hidas kysely

• liian paljon lisäosia

• ja autoloaded options paisuneena taustalla

Autoloaded options ovat petollisia, koska ne ovat:

• näkymättömiä

• hiljaisia

• aina läsnä

Kun sivusto hidastuu ilman ilmeistä syytä, siellä ne usein odottavat. Ei dramaattisesti. Ei aggressiivisesti. Vain rauhallisesti kuluttaen resursseja jokaisella pyynnöllä.

Täydellinen suorituskykysyöppö.

Välimuisti on ohjelmistokehityksen hiljainen sankari. Kukaan ei kirjoita siitä runoja, mutta ilman sitä moderni web tuntuisi siltä kuin jokainen sivulataus kulkisi käsijarru päällä. WordPress-maailmassa Transients API on yksi keskeisistä työkaluista tämän näkymättömän tehokkuuden rakentamiseen.

Transients API ei ole vain tekninen rajapinta. Se on filosofinen kompromissi ajan, resurssien ja epävarmuuden välillä. Se on järjestelmä, joka sanoo: “Tämä tieto ei muutu usein – säästetään vaivaa.”

Ja juuri tässä kohtaa astuu esiin välimuistin psykologia.

Mikä Transients API oikeastaan on?

Teknisesti Transients API on WordPressin tapa tallentaa väliaikaista dataa. Dataa, jolla on:

• arvo

• elinikä

• mahdollinen vanheneminen

Transient ei ole pysyvää tallennusta. Se ei ole tietokannan “totuus”. Se on enemmänkin muistilappu jääkaapin ovessa: hyödyllinen, mutta ei ikuinen.

Kun käytät transienttia, sanot WordPressille:

“Tallenna tämä arvo hetkeksi. Jos se on olemassa, käytä sitä. Jos ei, luodaan uudelleen.”

Yksinkertainen idea. Syvälliset seuraukset.

Välimuistin perusfilosofia

Välimuisti perustuu yhteen havaintoon, joka on lähes universaali tietojenkäsittelyssä:

Sama asia kysytään usein uudelleen.

Tietokantakyselyt, API-kutsut, raskaat laskelmat. Ilman välimuistia jokainen pyyntö aloittaisi kaiken alusta. Välimuisti rikkoo tämän kaavan.

Se kysyy: “Tarvitseeko tämä oikeasti laskea uudelleen?”

Aika vs laskenta

Välimuisti on ajan ja laskennan vaihtokauppaa.

• Laskenta on kallista

• Tallennus on halpaa

• Aika on rajallista

Transientit ovat käytännössä aikaperusteista muistia. Data saa eliniän. Kun aika loppuu, arvo katoaa.

Tämä tekee välimuistista dynaamisen. Se ei ole arkisto. Se on virta.

Transientit käytännössä

Transientti sisältää kolme asiaa:

• avain

• arvo

• vanhenemisaika

Kun transientti haetaan:

• Jos löytyy → käytä

• Jos ei löydy → generoi

Kaava on elegantti.

Se tekee ohjelmakoodista kiinnostavan hybridin: osa logiikasta käsittelee “oikeaa dataa”, osa “ehkä olemassa olevaa dataa”.

Ja juuri tämä “ehkä” on välimuistin psykologian ydin.

Välimuistin epistemologia: mitä me oikeastaan tiedämme?

Välimuisti tuo järjestelmään epävarmuuden.

Tieto voi olla:

• tuoretta

• vanhentunutta

• puuttuvaa

• juuri uudelleenrakennettua

Ilman välimuistia järjestelmä on deterministisempi. Jokainen kysely antaa “uusimman totuuden”. Välimuisti muuttaa tämän:

Saat todennäköisesti riittävän hyvän vastauksen.

Huomaa sanavalinta. Ei absoluuttinen totuus, vaan käytännöllinen riittävyys.

Ihmismieli toimii samoin

Tässä kohtaa välimuisti alkaa muistuttaa kognitiivista psykologiaa.

Ihmisaivot eivät laske kaikkea alusta joka hetki. Ne käyttävät heuristiikkoja, oletuksia ja muistia. Välimuisti on ohjelmistojen heuristiikka.

Se olettaa, että maailma ei ole muuttunut sekunnin murto-osassa.

Useimmiten tämä on totta.

Transienttien kauneus: pragmaattinen älykkyys

Transients API edustaa käytännöllistä älykkyyttä.

Se ei kysy: “Onko tämä data täydellisen ajantasaista?”

Se kysyy: “Onko tämä data riittävän ajantasaista?”

Tämä pieni muutos on valtava suorituskyvyn kannalta.

Raskaat operaatiot

Transientit loistavat tilanteissa, joissa:

• laskenta on kallista

• data muuttuu harvoin

• viive on merkittävä

Esimerkiksi:

• ulkoiset API-kutsut

• monimutkaiset raportit

• aggregoidut tilastot

• hitaat tietokantakyselyt

Transientti tekee raskaasta kevyen – ainakin hetkeksi.

Välimuistin ikuinen kirous: invalidointi

Tietojenkäsittelyssä on kuuluisa vitsi:

Ohjelmistokehityksen vaikeimmat ongelmat ovat nimeäminen ja välimuistin invalidointi.

Välimuistin invalidointi tarkoittaa hetkeä, jolloin tallennettu tieto ei enää ole luotettava.

Transientin vanhenemisaika on karkea ratkaisu tähän. Se sanoo:

“Unohdetaan tämä arvo X sekunnin kuluttua.”

Se ei tiedä, onko data muuttunut. Se vain olettaa, että ehkä on.

Täydellistä invalidointia ei ole

Täydellinen invalidointi vaatisi:

• täydellisen tiedon järjestelmän tilasta

• reaaliaikaisen synkronoinnin

• nollaviiveen

Tämä olisi absurdi tavoite.

Transientit hyväksyvät epätäydellisyyden. Ja juuri tämä tekee niistä käyttökelpoisia.

Välimuistin psykologia: miksi tämä tuntuu joskus pelottavalta?

Monille kehittäjille välimuisti aiheuttaa outoa levottomuutta.

Ilman välimuistia logiikka on selkeä:

• hae data

• näytä data

Välimuistin kanssa:

• hae ehkä-data

• jos ei ole → generoi

• ehkä vanhentunut

• ehkä ei

Determinismi muuttuu todennäköisyydeksi.

Kontrollin illuusio

Ohjelmistokehitys antaa usein tunteen täydellisestä kontrollista. Välimuisti rikkoo tämän.

Se tuo järjestelmään tilan, jossa:

• arvo voi kadota

• arvo voi olla vanha

• arvo voi olla olematta

Tämä ei ole bugi. Tämä on design.

Välimuisti on hallittua epävarmuutta.

Transientit ja suorituskyvyn psykologia

Suorituskyky ei ole vain tekninen mittari. Se on kokemus.

Ihminen ei koe millisekunteja lineaarisesti. Viiveet tuntuvat epälineaarisilta:

• 50 ms → näkymätön

• 300 ms → havaittava

• 1000 ms → ärsyttävä

• 3000 ms → “miksi tämä on rikki?”

Transientit toimivat käyttäjäkokemuksen tasolla. Ne leikkaavat pois viivepiikkejä.

Nopeus on tunne

Kun sivu tuntuu nopealta, käyttäjä olettaa:

• sivusto on laadukas

• järjestelmä on vakaa

• sisältö on luotettava

Suorituskyky muuttaa psykologista kokemusta koko sovelluksesta.

Transientti ei siis optimoi vain CPU-aikaa. Se optimoi käyttäjän mielentilaa.

Välimuisti ja resurssien moraalinen talous

Palvelinresurssit eivät ole ilmaisia.

Jokainen:

• tietokantakysely

• API-kutsu

• raskas laskenta

kuluttaa energiaa, aikaa ja rahaa.

Välimuisti on resurssien säästäväisyysperiaate.

Se sanoo: “Älä tee turhaa työtä.”

Tässä on lähes ekologinen ulottuvuus. Vähemmän laskentaa → vähemmän kuormaa → vähemmän energiaa.

Transientit ja järjestelmän dynamiikka

Transientit tekevät järjestelmästä joustavamman.

Ilman välimuistia jokainen pyyntö kuormittaa järjestelmää yhtä paljon. Välimuisti tasoittaa kuormaa.

Se muuttaa liikenteen profiilia:

• vähemmän piikkejä

• vähemmän raskaita operaatioita

• enemmän ennustettavuutta

Ennustettavuus on vakauden perusta

Järjestelmät eivät kaadu keskiarvon vuoksi. Ne kaatuvat piikkien vuoksi.

Transientit ovat piikkien vaimentimia.

Välimuisti ja totuuden relativismi

Välimuisti tuo järjestelmään kiinnostavan filosofisen piirteen:

Totuus muuttuu ajalliseksi.

Data voi olla:

• totta nyt

• epätotta hetken kuluttua

• riittävän totta

Tämä ei ole virhe. Tämä on käytännöllinen kompromissi.

Täydellinen ajantasaisuus on kallista. Riittävä ajantasaisuus on tehokasta.

Transienttien elegantti minimalismi

Transients API on tarkoituksella yksinkertainen.

Ei monimutkaista konfiguraatiota. Ei massiivista abstraktiokerrosta. Vain:

• set

• get

• delete

Tämä tekee siitä vaarallisen tehokkaan. Pieni rajapinta, suuret vaikutukset.

Yksinkertaisuus on voimaa

Monimutkaiset välimuistijärjestelmät voivat olla joustavia, mutta ne ovat myös hauraita.

Transientit ovat minimalistinen ratkaisu yleisiin tarpeisiin.

Välimuisti ja kehittäjän mielenrauha

Hyvin käytetty välimuisti tekee järjestelmästä:

• nopeamman

• vakaamman

• halvemman

• miellyttävämmän käyttää

Huonosti käytetty välimuisti tekee järjestelmästä:

• epädeterministisen

• vaikeasti debugattavan

• satunnaisesti hajoavan

Välimuisti ei ole vain tekninen optimointi. Se on arkkitehtuurinen vastuu.

Lopuksi: välimuisti on luottamusta

Transientit toimivat, koska ne perustuvat luottamukseen.

Luottamus siihen, että:

• data ei muutu jatkuvasti

• pieni viive totuudessa on hyväksyttävä

• järjestelmä hyötyy muistamisesta

Välimuisti on järjestelmän tapa sanoa:

“En aloita kaikkea alusta joka kerta.”

Ja jollain oudolla tavalla tämä on hyvin inhimillistä.

WordPressin Rewrite API on yksi niistä järjestelmistä, joka tuntuu aluksi siltä kuin joku olisi piilottanut sivuston logiikan savuverhon taakse. URLit muuttuvat, parametrit katoavat, ja yhtäkkiä /index.php?post_type=kirja&kirja=dyyni muuttuu muotoon /kirjat/dyyni/. Näyttää taikuudelta. Ei ole taikuutta. On vain sääntöjä.

Rewrite API on WordPressin tapa kääntää ihmisten luettavaksi suunnitellut URLit sisäiseen kyselylogiikkaan. Ihminen näkee siistin osoitteen, WordPress näkee kyselyparametrit. Kaikki ovat tyytyväisiä.

Mikä Rewrite API oikeastaan tekee?

Perusidea on yksinkertainen. Rewrite-järjestelmä:

• lukee saapuvan URLin

• vertaa sitä sääntöihin

• muuntaa URLin queryksi

• antaa queryn WordPressin käsiteltäväksi

Kun selain pyytää sivua, WordPress ei oikeasti etsi tiedostoa /kirjat/dyyni/. Sen sijaan se ajattelee: “Ahaa, tämä vastaa sääntöä X → tämä tarkoittaa kyselyä Y.”

Rewrite API on siis tulkki URLien ja WordPressin kyselymoottorin välillä.

Kauniit permalinkit eivät ole sattumaa

Kun otat permalinkit käyttöön, Rewrite API astuu näyttämölle. Ilman rewrite-sääntöjä WordPress toimisi täysin querypohjaisesti:

/?p=123

Teknisesti toimiva. Ihmiselle karmea.

Rewrite API mahdollistaa:

• /blogi/artikkeli/

• /tuotteet/kategoria/

• /kirjat/dyyni/

Kyse ei ole vain estetiikasta. Kauniit URLit:

• ovat luettavampia

• ovat SEO-ystävällisempiä

• ovat helpompia jakaa

• näyttävät vähemmän 2003-vuosimallin webiltä

Rewrite ei muuta dataa – vain reitin

Tärkeä oivallus. Rewrite API ei muuta tietokantaa eikä sisältöä. Se muuttaa vain sitä, miten pyyntö ohjataan.

Sama sisältö, eri reitti.

Tämä tekee rewrite-järjestelmästä elegantin. Se on kerros logiikan päällä, ei logiikan sisällä.

Rewrite-säännöt: logiikka URLien takana

Rewrite API toimii sääntöjen varassa. Jokainen sääntö kertoo:

“Jos URL näyttää tältä → käsittele se näin.”

Käytännössä sääntö sisältää:

• patternin (miltä URL näyttää)

• queryn (mitä WordPressille annetaan)

Ajattele rewrite-sääntöjä karttana. URL on lähtöpiste, query on määränpää.

Miksi kaikki tuntuu joskus hajoavan?

Rewrite-järjestelmä tallennetaan tietokantaan. Kun:

• lisäät custom post typen

• lisäät custom taxonomy

• muutat slugia

• rekisteröit rewrite-sääntöjä

WordPress ei automaattisesti päivitä sääntöjä joka pyynnöllä. Se olisi tehotonta.

Siksi joskus tarvitaan klassinen rituaali:

Asetukset → Permalinkit → Tallenna

Ei mystiikkaa. Rewrite cache flushataan.

Custom Post Type ja Rewrite API

Custom post typet ovat rewrite-järjestelmän lempiasiakkaita. Kun rekisteröit CPT:n, WordPress luo rewrite-säännöt automaattisesti.

Kun määrittelet:

• slug

• archive

• rewrite-asetukset

Määrittelet samalla URL-arkkitehtuurin.

URL-arkkitehtuuri on UX-suunnittelua

URL ei ole vain tekninen detalji. Se on käyttöliittymä.

Vertaa:

• /post/?id=42

• /kirjat/scifi/dyyni/

Toinen kertoo ihmiselle jotain. Toinen kertoo vain koneelle.

Hyvin suunniteltu URL:

• viestii rakennetta

• kertoo kontekstin

• vähentää kognitiivista kitkaa

Rewrite API ei ole vain backend-työkalu. Se on informaatiodesignia.

Rewrite API ilman pelkoa

Rewrite APIa vältellään usein, koska se näyttää monimutkaiselta. Regexejä, sääntöjä, queryjä. Mutta peruslogiikka pysyy samana:

Pattern → Query

Kun tämän sisäistää, rewrite muuttuu hallittavaksi.

Ajatusmalli, joka helpottaa elämää

Rewrite ei ole magiaa. Rewrite on reititystä.

URL on vain merkkijono. WordPress yrittää sovittaa sen sääntöihin. Jos sääntö täsmää, WordPress tietää mitä tehdä.

Jos mikään ei täsmää → 404

Ei mysteeriä. Ei kohtaloa. Ei kosmista epäoikeudenmukaisuutta.

Yleisimmät rewrite-kompastuskivet

Rewrite-ongelmat noudattavat yleensä tuttuja kaavoja.

Slug-konfliktit.
Kaksi asiaa yrittää käyttää samaa URL-tilaa.

Unohdettu flush.
Säännöt eivät päivity.

Liian geneerinen pattern.
Regex nappaa liikaa.

Väärä query.
WordPress ei saa oikeaa dataa.

Rewrite-ongelmat ovat harvoin satunnaisia. Ne ovat loogisia – joskus vain armottoman loogisia.

Rewrite API ja suorituskyky

Rewrite-järjestelmä ei ole ilmainen. Jokainen pyyntö käy sääntölistan läpi.

Hyvä uutinen: WordPress optimoi tätä aggressiivisesti.

Huono uutinen: Tuhannet rewrite-säännöt voivat hidastaa sivustoa.

Tämä näkyy erityisesti:

• massiivisissa multisite-asennuksissa

• erittäin monimutkaisissa CPT-rakenteissa

• plugin-viidakossa

Rewrite on tehokas, mutta ei ääretön.

Lopuksi: Rewrite API on arkkitehtuuria, ei temppuja

Rewrite APIa ei kannata ajatella kikkailuna. Se on osa sovellusarkkitehtuuria.

Hyvin suunniteltu rewrite-rakenne:

• tekee URLit ymmärrettäviksi

• tekee sivustosta loogisemman

• tekee debuggaamisesta helpompaa

• tekee käyttäjäkokemuksesta sulavamman

Huonosti suunniteltu rewrite-rakenne:

• synnyttää 404-helvetin

• aiheuttaa slug-konflikteja

• tekee sivustosta hauraan

Rewrite API ei ole mustaa magiaa. Se on järjestelmällistä reititystä. Kun logiikka on selkeä, rewrite muuttuu tylsän luotettavaksi. Ja tylsä luotettavuus on ohjelmistokehityksen korkein hyve.