WordPress Multisite Domain Mapping teknisesti

WordPress Multisite Domain Mapping kokonaisuutena

WordPress Multisite Domain Mapping on ominaisuus, joka näyttää yksinkertaiselta käyttäjän näkökulmasta: jokaisella sivustolla on oma domain. Tekninen todellisuus tämän takana on kuitenkin monikerroksinen yhdistelmä WordPressin sisäistä logiikkaa, HTTP-pyyntöjen käsittelyä, tietokantarakenteita ja palvelinpuolen reititystä. Domain mapping ei ole vain asetus, vaan arkkitehtoninen ratkaisu, joka vaikuttaa koko järjestelmän toimintaan.

Kun domain mapping toteutetaan oikein, Multisite-verkko tuntuu kokoelmalta täysin itsenäisiä WordPress-sivustoja. Kun se toteutetaan väärin, seurauksena on sekavia URL-osoitteita, kirjautumisongelmia, rikkoutuneita linkkejä ja vaikeasti debugattavia edge caseja. Tässä artikkelissa pureudutaan siihen, miten WordPress Multisite Domain Mapping oikeasti toimii teknisesti.

Multisite-verkon perusmalli

Yksi WordPress, monta sivustoa

WordPress Multisite on yksi WordPress-asennus, joka palvelee useita sivustoja. Kaikki sivustot jakavat saman koodipohjan, samat lisäosat ja saman tietokannan, mutta niillä on omat sisältönsä ja asetuksensa.

Teknisesti Multisite tunnistaa sivuston kahden asian perusteella:

• HTTP Host -header (domain)

• URL-polku

Ilman domain mappingia Multisite toimii yleensä joko alidomaineilla tai alihakemistoilla. Domain mapping muuttaa tämän tunnistuslogiikan painopistettä.

wp_blogs ja wp_site

Multisite-verkon ydin elää tietokannassa. Jokainen sivusto on rivi wp_blogs-taulussa, jossa keskeisiä kenttiä ovat domain ja path. WordPress käyttää näitä arvoja määrittääkseen, mihin sivustoon pyyntö kuuluu.

Domain mapping on käytännössä tämän domain-kentän hallintaa ja tulkintaa oikein.

Mitä Domain Mapping oikeasti tekee

Ei uudelleenohjausta, vaan tunnistusta

Yksi yleinen harhaluulo on, että domain mapping olisi vain joukko 301-uudelleenohjauksia. Todellisuudessa kyse on pyyntöjen reitityksestä WordPressin sisällä.

Kun HTTP-pyyntö saapuu palvelimelle, WordPress lukee Host-headerin ja yrittää löytää wp_blogs-taulusta sivuston, jonka domain vastaa tätä arvoa. Jos vastaavuus löytyy, kyseinen sivusto aktivoidaan kyseiselle pyynnölle.

Tämä tapahtuu ennen kuin teemat, lisäosat tai sisältö tulevat mukaan kuvaan.

Absoluuttinen totuus: HTTP Host

Domain mapping nojaa täysin HTTP Host -headeriin. DNS:n, web-palvelimen ja SSL-sertifikaattien täytyy kaikki ohjata pyyntö samaan WordPress-instanssiin. WordPress ei tiedä tai välitä DNS:stä, se luottaa siihen, että pyyntö on jo tullut oikeaan paikkaan.

Jos Host-header on väärä tai puuttuu, domain mapping ei toimi.

Domain mappingin tekniset vaiheet

DNS-taso

Kaikki mapped-domainit täytyy ohjata samaan IP-osoitteeseen tai kuormantasaajaan. Tämä on ehdoton edellytys. WordPress ei voi käsitellä domainia, joka ei osoita samaan ympäristöön.

Teknisesti tämä tarkoittaa yleensä A- tai CNAME-tietueita, jotka osoittavat Multisite-palvelimeen.

Web-palvelin

Nginx tai Apache täytyy konfiguroida hyväksymään kaikki mapped-domainit. Usein käytetään wildcard-konfiguraatiota tai catch-all server blockia.

Web-palvelin ei päätä, mikä sivusto on kyseessä. Sen tehtävä on vain välittää pyyntö WordPressille rikkomatta Host-headeria.

WordPress bootstrap

WordPress käynnistyy, lukee Multisite-konfiguraation ja suorittaa domain–path-mätsäyksen. Tässä vaiheessa päätetään, mikä blog_id aktivoidaan.

Tämän jälkeen kaikki WordPressin sisäiset URL-funktiot alkavat käyttää mapped-domainia automaattisesti.

Moderni domain mapping WordPressissä

Native domain mapping

Vanhemmissa WordPress-versioissa domain mapping vaati erillisiä lisäosia ja monimutkaisia muokkauksia. Nykyisin WordPress tukee domain mappingia natiivisti.

Jokaiselle sivustolle voidaan asettaa oma domain suoraan Network Admin -näkymässä. Tämä tallennetaan wp_blogs-tauluun ja käsitellään ytimessä.

Tämä yksinkertaistus on kuitenkin näennäinen. Tekninen vastuu siirtyy yhä enemmän infrastruktuurille.

Site URL vs. Home URL

Domain mapping tuo esiin yhden Multisite-arkkitehtuurin hienovaraisimmista yksityiskohdista: siteurl ja home eivät aina ole sama asia.

• siteurl kertoo, missä WordPressin core sijaitsee

• home kertoo, mistä sivusto palvellaan

Multisite-ympäristössä nämä voivat erota, ja domain mapping perustuu nimenomaan home-osoitteeseen. Tämä on tärkeää esimerkiksi media-URL:eja, REST API -kutsuja ja kirjautumisia ajatellen.

SSL ja domain mapping

Sertifikaattien hallinta

Jokainen mapped-domain tarvitsee toimivan SSL-sertifikaatin. Tämä ei ole WordPressin ongelma, vaan infrastruktuurin.

Yleisiä ratkaisuja ovat:

• wildcard-sertifikaatit

• SAN-sertifikaatit

• automaattinen sertifikaattien provisiointi

WordPress olettaa, että HTTPS toimii, jos se on määritelty home-URL:iin.

Mixed content -riskit

Jos osa sivustoista käyttää HTTP:tä ja osa HTTPS:ää, domain mapping voi aiheuttaa mixed content -ongelmia. WordPress generoi URL:t aktiivisen sivuston asetusten perusteella, mutta lisäosat eivät aina ole Multisite-tietoisia.

Tämä on yksi yleisimmistä domain mappingin “mystisistä” ongelmista.

Evästeet ja kirjautuminen

Cookie domain -ongelma

WordPressin kirjautuminen perustuu evästeisiin. Multisite-ympäristössä evästeiden domain-asetukset ovat kriittisiä.

Domain mapping tekee mahdottomaksi jakaa kirjautumista kaikkien sivustojen kesken eri domaineissa. Tämä ei ole bugi, vaan selainten turvallisuusmalli.

Network Admin -kirjautuminen tapahtuu aina verkon päädomainin kautta.

Admin-URL:t

Yksi klassinen virhe on yrittää käyttää wp-adminia mapped-domainin kautta. WordPress ohjaa hallintaliikenteen aina verkon päädomainille.

Tämä on tarkoituksellista ja suojaa Multisite-verkon eheyttä.

Suorituskyky ja välimuistit

Object Cache ja domain awareness

Object Cache -ratkaisut täytyy konfiguroida domain-tietoisiksi. Muuten yksi sivusto voi lukea toisen sivuston välimuistia.

Hyvät object cache -ratkaisut eristävät cache-avaruuden blog_id:n perusteella, eivät domainin.

Page cache ja CDN

Page cache ja CDN voivat monimutkaistaa domain mappingia. Välimuistiavainten täytyy sisältää domain, muuten väärä sisältö voi päätyä väärään domainiin.

Tämä on erityisen kriittistä silloin, kun sama sivu löytyy useasta domainista eri sisällöllä.

Yleisimmät virheet domain mappingissa

DNS on oikein, mutta WordPress ei

Yleinen tilanne: domain osoittaa palvelimelle, SSL toimii, mutta WordPress näyttää väärää sivustoa. Tämä on lähes aina wp_blogs-taulun domain–path-yhdistelmän virhe.

Domain mapping ei siedä epämääräisyyttä. Yksi domain = yksi sivusto.

Lisäosat, jotka eivät ymmärrä Multisitea

Kaikki lisäosat eivät ole Multisite-yhteensopivia. Osa käyttää suoraan siteurl-arvoja tai olettaa yhden domainin ympäristön.

Domain mapping paljastaa nämä oletukset nopeasti.

Domain mapping arkkitehtuurisena valintana

Domain mapping tekee Multisitesta vahvan alustan SaaS-tyyppisille ratkaisuille, franchise-malleille ja monibrändiympäristöille. Samalla se tuo mukanaan infrastruktuurivastuuta, jota ei voi ohittaa asetuksilla.

Teknisesti domain mapping on puhdas ratkaisu: WordPress tekee sen, minkä se osaa, ja jättää verkko- ja TLS-maailman sinne minne ne kuuluvat.

Lopuksi: domain mapping on reititystä, ei temppuilua

WordPress Multisite Domain Mapping ei ole kikka eikä lisäosaominaisuus. Se on reititysmekanismi, joka toimii vain, jos koko ketju DNS:stä PHP:hen on kunnossa.

Kun sen ymmärtää näin, ongelmat muuttuvat ennustettaviksi ja ratkaistaviksi. Domain mapping ei ole monimutkainen siksi, että WordPress olisi huono, vaan siksi, että verkkoliikenne, selaimet ja turvallisuus ovat monimutkaisia.

Hyvin rakennettuna domain mapping tekee Multisitesta näkymättömän. Ja juuri se on merkki siitä, että arkkitehtuuri on onnistunut.