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.
