Suurin osa WordPress Multisite -asennusta koskevista ohjeista lähtee liikkeelle väärästä lähtökohdasta. Ne alkavat wp-config.php, kerrotaan, mihin vakioarvo liitetään, ja verkostoa käsitellään teknisenä päivityksenä.
Se on väärinpäin.
Monisivustoarkkitehtuuri on arkkitehtoninen sitoumus. Se voi yksinkertaistaa hallintoa, julkaisutoimintaa ja alustan ylläpitoa. Se voi myös sitoa toisistaan riippumattomat sivustot yhteen toimintamalliin, yhteen käyttöönottotapaan ja yhteen vikakokonaisuuteen. Asennus kestää vain muutaman minuutin. Päätöksen seuraukset tuntuvat vuosien ajan.
Table of Contents
Tällä on merkitystä, koska WordPressin käyttö on valtavan laajamittaista. WordPress on käytössä 43,5 %:ssa kaikista verkkosivustoista maailmanlaajuisesti, ja maaliskuussa 2025 verkossa oli noin 1,19 miljardia verkkosivustoa, minkä vuoksi Multisite-ominaisuus on edelleen merkityksellinen yrityksille, jotka ylläpitävät monikielisiä, monialueisia tai monipaikkaisia sivustokokonaisuuksia tällä hallitsevalla sisällönhallintajärjestelmällä (Pantheonin WordPress-tilastokatsaus). Ominaisuus on kypsä. Suurempi kysymys on, onko organisaatiosi sitä.
Milloin WordPress Multisitea kannattaa käyttää ja milloin sitä tulisi välttää
Tiimit turvautuvat usein Multisite-ratkaisuun, vaikka todellisuudessa ne tarvitsisivat parempaa hallintoa, eivätkä yhteistä arkkitehtuuria. Nämä ovat eri ongelmia.
Käytä Multisite-ominaisuutta, kun tarvitset useita sivustoja, jotka toimivat yhden hallitun alustan sisällä. Tämä sopii yleensä franchising-ketjuille, yliopistoille, toimistoille, julkaisijaverkostoille ja yritysryhmille, joilla on toistuvia sivustomalleja, yhteisiä todennusvaatimuksia, yhteisiä suunnittelujärjestelmiä ja keskitettyä laajennusten hallintaa. WordPress Multisite on kehitetty juuri tällaista mittakaavaa varten. Yksi verkosto voi isännöidä useita sivustoja yhdestä asennuksesta, ja jotkut organisaatiot ylläpitävät ”satoja tai jopa tuhansia” sivustoja yhdessä verkostossa (Fellowship on WordPress Multisite).
Vältä sitä, jos sivustot näyttävät samankaltaisilta vain esitysmateriaalissa. Jos liiketoimintayksiköt tarvitsevat erillisiä julkaisuaikatauluja, erilaisia laajennuspaketteja, itsenäisiä hosting-päätöksiä, tiukkaa oikeudellista erottelua tai vapautta poiketa yhteisestä teemajärjestelmästä, Multisite-ratkaisu aiheuttaa ongelmia.
Hyvät sovitussignaalit
- Keskitetty hallinta on tärkeää: Yhden alustatiimin on hallinnoitava teemoja, laajennuksia ja käyttäjäkäytäntöjä useilla sivustoilla.
- Rakennuskohteiden mallit toistuvat: Uudet kohteet ovat hyväksytyn suunnitelman muunnelmia, eivät räätälöityjä rakennuksia.
- Yhteistoiminta on etu: turvallisuus-, ylläpito- ja toimituksellisia standardeja tulisi valvoa keskitetysti.
- Laajentumista on odotettavissa: Joukkueet, jotka suunnittelevat alueellisia lanseerauksia tai luovat skaalautuvia mikrosivustoja, hyötyvät usein toistettavasta verkostomallista.
Huonon istuvuuden merkit
- Jokainen sivusto toimii ikään kuin se olisi oma tuotteensa: Erilliset kehityssuunnitelmat ja räätälöidyt integraatiot edellyttävät yleensä erillisiä asennuksia.
- Laajennusten itsenäisyys on olennaisen tärkeää: Multisite-järjestelmä rajoittaa vapautta jo suunnittelultaan.
- Organisaatio on poliittisesti hajautettu: tekninen keskittäminen selviää harvoin hallinnon kaaoksesta.
- Tietojen erottelu on ehdoton vaatimus: Erilliset asennukset ovat usein toiminnallisesti ja sopimusperusteisesti selkeämpiä.
Käytännön sääntö: Jos tiimisi arvostaa yhteistä hallintaa enemmän kuin yhteistä käyttömukavuutta, Multisite-ratkaisu saattaa sopia. Jos tiimisi arvostaa yhteistä käyttömukavuutta, mutta odottaa paikallisia poikkeuksia kaikkialla, se ei yleensä sovi.
Yritystiimeille, jotka tarvitsevat asiantuntijoiden apua tämän kompromissin punnitsemisessa ennen kehitystyön aloittamista, yrityskäyttöön tarkoitetut WordPress-ratkaisut ovat usein hyödyllisempiä kuin pelkkä asennuksen tarkistuslista.
Kriittisten päätösten alialueet vs. alihakemistot
Multisite-asennuksessa ensimmäinen pysyvä valinta ei ole koodi, vaan URL-rakenne.
Useimmat oppaat ohittavat tämän aiheen liian nopeasti, vaikka väärä päätös voi aiheuttaa pitkäaikaisia siirtymisongelmia. Jopa WordPressin omissa oppaissa on tässä kohtaa aukko. Tiimeille opetetaan, miten verkko otetaan käyttöön, mutta ei sitä, miten arvioidaan, sopiiko pysyvä aliverkkotunnus vai alihakemisto paremmin heidän toimintamalliinsa (WordPress.org:n Multisite-asennusopas).
Mitä muutoksia kuhunkin rakenteeseen liittyy
| Rakenne | Parempi, kun | Yleensä vaikeampaa, kun |
|---|---|---|
| Aliverkkotunnukset | Sivustoille tarvitaan selkeämpi erottelu, erilaiset julkaisuvälit tai lopulta omat verkkotunnukset | DNS, SSL-suunnittelu ja ympäristön määrittäminen |
| Alakansiot | Sivustojen tulisi edustaa yhtä emobrändiä ja niiden tulisi tuntua yhtenäisen kokonaisuuden osilta | Tulevat erottelut, toimialueiden muutokset ja eräät siirtymäkuviot |
Alakansiot pitävät kaiken näkyvästi yhden pääbrändin alla. Tämä on usein selkeämpää keskitetyn markkinointitiimin kannalta. Se myös vähentää alkuvaiheen DNS-koordinointitarvetta ja yleensä helpottaa ensimmäistä käyttöönottoa.
Aliverkkotunnukset luovat selkeämpiä rajoja. Ne ovat usein turvallisempi ratkaisu yritysverkoissa, joissa jokaisella alueella, osastolla tai liiketoimintalinjalla tarvitaan nykyään oma identiteettinsä, vaikka kaikkea hallinnoidaankin keskitetysti taustalla.
SEO ja vaikutukset brändiin
Tämä valinta ei ole koskaan pelkästään tekninen.
Alihakemistot ovat yleensä järkevä ratkaisu, kun pääverkkotunnus edustaa brändiä ja jokainen sivusto on olemassa vahvistamaan kyseistä brändiä. Maakohtaiset osiot, liiketoimintayksiköiden sisältökeskittymät tai kampanja-alueet voivat toimia hyvin tässä mallissa, jos hallinnointi on tiukkaa ja käyttäjäpolku on yhtenäinen. Tiimit, jotka pohtivat sivuston rakennetta tällä tasolla, tulisi myös tarkastella, miten navigointi ja URL-osoitteiden suunnittelu vaikuttavat löydettävyyteen. Tätä varten kannattaa tutustua tähän oppaaseen, joka käsittelee URL-osoitteiden SEO-potentiaalia verkkosivuston navigoinnissa.
Aliverkkotunnukset ovat järkevämpiä silloin, kun jokaisen sivuston on tarkoitus näyttäytyä jonkin verran itsenäisenä. Franchising-verkosto, kumppaniohjelma tai alueellisesti itsenäinen toiminta hyötyy usein tällaisesta erottelusta. Se helpottaa verkkotunnusten määrittelyä myöhemmin ja vähentää hankalia kompromisseja sivustojen kehittyessä.
Valitse alihakemistot, kun verkosto koostuu yhdestä brändistä, jolla on useita osioita. Valitse aliverkkotunnukset, kun kyseessä on yksi alusta, jolla on useita identiteettejä.
Toiminnalliset seuraukset, joita tiimit aliarvioivat
Aliverkkotunnukset lisäävät infrastruktuuriin liittyvää työtä. Sinun on pohdittava villikorttien toimintaa, SSL-suojausta ja sitä, miten uudet sivustot tunnistetaan, ennen kuin toimittajat pääsevät edes käyttämään hallintapaneelia.
Alihakemistot näyttävät aluksi yksinkertaisemmilta, mutta niistä voi tulla kalliita, jos sivusto joudutaan myöhemmin siirtämään omalle verkkotunnukselleen tai irrottamaan verkosta. Tämä on se piilokustannus, jonka useimmat pikaoppaat jättävät huomiotta.
Hyödyllinen testi on seuraava: kysy, tarvitsisiko jokin sivusto lähivuosina omaa brändiä, verkkotunnusta tai osittain itsenäistä hallintoa. Jos vastaus on kyllä, aliverkkotunnukset ovat yleensä turvallisempi lähtökohta. Jos vastaus on ei ja yritys haluaa yhden tiiviisti yhtenäisen verkkosivuston, alihakemistot toimivat usein paremmin pitkällä aikavälillä.
Verkkopalvelin- ja DNS-ympäristön valmistelu
Monisivustojärjestelmän käyttöönotto epäonnistuu jo kauan ennen kuin WordPress itse pettää. Epäonnistuminen johtuu DNS-asetuksista, varmenteiden suunnittelusta, välimuistia koskevista oletuksista ja huonoista hosting-valinnoista.
Jos kyseessä on tuotantokäyttöön tarkoitettu verkko, käsittele isännöintitasoa osana sovelluksen suunnittelua. Älä suhtaudu siihen kuin putkistoon, jonka hoidat myöhemmin.
Mitä tuotantovalmius oikeastaan tarkoittaa
Vakavasti otettavassa verkossa ympäristön on tuettava toistettavaa käyttöönottoa, hallittuja käyttöönottoja ja ennustettavaa reitityskäyttäytymistä. Tämä tarkoittaa, että infrastruktuuritiimisi ja WordPress-tiimisi tulisi sopia siitä, miten verkkotunnukset, varmenteet, uudelleenohjaukset, välimuistikerrokset ja testausympäristöt toimivat, ennen kuin verkko otetaan käyttöön.
Puutteellinen suunnittelu johtaa usein siihen, että monet projektit suistuvat raiteiltaan. Kehittäjät voivat asentaa WordPress Multisite -järjestelmän oikein, mutta jos DNS-tietueita, varmenteiden kattavuutta ja käänteisen välityspalvelimen toimintaa ei ole lainkaan suunniteltu, ensimmäisen verkkotunnuksen julkaisu muuttuu tukipyyntöjen ketjuksi.
Asennusta edeltävä tarkistuslista
- Valitse hosting-palvelu, joka ymmärtää WordPressin toiminnallisuutta: Tavallinen jaettu hosting ei ole oikea perusta verkostolle, jonka on tarkoitus tukea useita brändejä tai markkinoita.
- Suunnittele villikorttien toiminta jo varhaisessa vaiheessa: Jos käytät aliverkkotunnuksia, infrastruktuurin on tuettava sitä, miten uudet sivustot tullaan osoittamaan.
- Määritä SSL-vastuut: Päätä, kuka vastaa varmenteiden hallinnasta: isäntä, alustatiimi vai ulkoinen operatiivinen tiimi.
- Varmista uudelleenkirjoituksen yhteensopivuus: Apache- tai Nginx-sääntöjen on oltava yhdenmukaisia sen kanssa, miten WordPress reitittää verkkosivustoja.
- Erota testausympäristö tuotanto-odotuksista: Testausverkoston tulisi jäljitellä verkkotunnuksen ja välimuistin toimintaa riittävän tarkasti, jotta käyttöönottoon liittyvät ongelmat tulevat esiin ennen kuin ne vaikuttavat käyttäjiin.
Lavastus ei ole vapaaehtoista
Monisivustoinen staging-ympäristö ei ole tarkoitettu pelkästään koodin testaamiseen. Sen avulla voit varmistaa, että koko prosessi sivuston luomisesta verkkotunnuksen määrittämiseen ja turvalliseen julkaisemiseen sujuu moitteettomasti. Ilman sitä ensimmäisestä varsinaisesta julkaisustasi tulee testitapaus.
Joukkueiden, jotka eivät ole vielä vakiinnuttaneet tätä käytäntöä, tulisi ainakin noudattaa selkeää staging-sivuston prosessia, jotta DNS-oletukset, SSL-asetukset ja käyttöönottijärjestys testataan hallituissa olosuhteissa.
Jos hosting-tiimisi sanoo, että ”voimme hoitaa verkkotunnuksen kohdistuksen asennuksen jälkeen”, keskeytä projekti. Asennuksen jälkeiset infrastruktuurikorjaukset ovat se vaihe, jossa siistit Multisite-suunnitelmat alkavat mennä sekaisin.
Mitä on päätettävä ennen kuin ryhdyt käyttämään WordPressiä
| Alue | Päätös sulkea alue |
|---|---|
| Verkkotunnukset | Mitkä sivustot ottavat verkko-URL-osoitteet käyttöön ensimmäisinä, ja mitkä sivustot julkaistaan kartoitettujen verkkotunnusten alla? |
| Sertifikaatit | Miten SSL-varmenteita myönnetään, uusitaan ja vahvistetaan verkossa |
| Välimuisti | Ovatko välimuistisäännöt sivustokohtaisia vai erillisiä |
| Ympäristöt | Miten kartoitettujen verkkotunnusten käsittely tapahtuu lavastus-, esituotanto- ja tuotantovaiheissa |
| Tukimalli | Kuka vastaa DNS-muutoksista, käyttöönottoaikatauluista ja palautuspäätöksistä? |
Vakaa Multisite-asennus ei ole niin riippuvainen define() riviin kuin usein luullaan. Vaikeinta on tehdä ympäristöstä riittävän ennustettava, jotta jokaisen uuden sivuston julkaisu noudattaa samaa toimintamallia.
WordPress-verkoston käyttöönotto ja konfigurointi
Itse asennus on suoraviivaista. Tärkeää on oikea suoritusjärjestys.
WordPress-Multisite-asennus on kaksivaiheinen prosessi. Ensinnäkin ominaisuus otetaan käyttöön lisäämällä define('WP_ALLOW_MULTISITE', true); kohtaan wp-config.php. Valitse sitten Työkalut → Verkoston asetukset -valikosta verkoston rakenne ja luo lopullinen koodi, jota tarvitaan sekä wp-config.php ja .htaccess (MultilingualPress-asennusopas).
Aloita varmuuskopiosta ja puhtaasta järjestelmänvalvojan istunnosta. Poista laajennukset käytöstä ennen verkon ottamista käyttöön. Tämä vähentää häiriöitä asennuksen aikana ja välttää sellaisten laajennusten vianmäärityksen, joiden toiminta ei liity itse Multisite-ominaisuuteen.
Ensimmäinen vaihe: ominaisuuden ottaminen käyttöön
Muokkaa wp-config.php ja lisää:
define('WP_ALLOW_MULTISITE', true);
Sijoita se rivin yläpuolelle, jossa lukee /* That's all, stop editing! */.
Tuo rivi ei luo verkkoa itsessään. Se tuo esiin Verkkoasetukset-näytön WordPress-hallinnassa, jotta sovellus voi luoda loput asetuksista valitsemasi rakenteen perusteella.
Toinen vaihe: verkkomääritysten luominen
Siirry hallinta-alueella kohtaan Työkalut → Verkon asetukset.
Valitse aliverkkotunnukset tai alihakemistot, syötä verkon nimi ja järjestelmänvalvojan tiedot ja anna WordPressin luoda tarvittavat koodinpätkät. Saat yhden lohkon wp-config.php ja toisen .htaccess.
Luodut säännöt eivät ole pelkkää koristelua. Ne kertovat WordPressille, miten tunnistaa verkko-pyynnöt, reitittää ne oikein ja käsitellä uudelleenkirjoitettua URL-rakennetta, josta verkko riippuu.
Tässä on luotettavasti toimiva työnkulku:
- Tee ensin varmuuskopio: tiedostot ja tietokanta.
- Poista laajennukset käytöstä: Erityisesti kaikki, mikä liittyy uudelleenohjauksiin, tietoturvaan tai sivujen välimuistiin.
- Lisää Multisite-vakio: Tallenna
wp-config.php. - Suorita verkkoasetukset: Valitse jo aiemmin päättämäsi URL-malli.
- Liitä luotu koodi huolellisesti: Aseta kukin lohko oikeaan tiedostoon.
- Kirjaudu sisään uudelleen: WordPress päivittää käyttöoikeudet ja avaa uuden verkkokäyttöliittymän.
Videopohjainen opas voi olla avuksi, jos haluat verrata omia toimiasi visuaaliseen asennusprosessiin:
Yleisiä virheitä asennuksen aikana
- Pluginien jättäminen aktiivisiksi: Tämä aiheuttaa usein vääriä hälytyksiä ensimmäisen kirjautumisen yhteydessä muunnoksen jälkeen.
- Koodin liittäminen väärään paikkaan:
wp-config.phpja.htaccesstekevät eri tehtäviä. Älä sekoita niitä keskenään. - Olemassa olevien uudelleenkirjoitussääntöjen huomiotta jättäminen: Jos sivustolla oli jo mukautettu palvelimen käyttäytyminen, yhdistä ne huolellisesti sen sijaan, että korvaisit ne sokeasti.
- Kirjautumisen päivityksen käsittely virheenä: Uudelleentodentaminen asennuksen jälkeen on odotettavissa.
Mitä luotu koodi tekee
Lisätyt wp-config.php arvot kertovat WordPressille, että sivusto on nyt verkko, ja määrittelevät, miten verkon tulisi toimia. .htaccess säännöt hoitavat URL-uudelleenkirjoituksen, jotta pyynnöt päätyvät oikealle sivustolle verkon sisällä.
Sinun ei tarvitse opetella ulkoa jokaista direktiiviä, mutta sinun on noudatettava järjestystä ja tiedostojen rajoja. Useimmat epäonnistuneet asennukset johtuvat siitä, että joku on kopioinut oikean koodinpätkän väärään paikkaan tai luonut rakenteen ennen kuin infrastruktuuripäätös oli tehty.
Verkoston hallintapaneelin hallitseminen
Asennuksen jälkeinen ensimmäinen päivä kertoo, pysyykö verkosto järjestyksessä.
Superjärjestelmänvalvoja kirjautuu sisään, avaa Omat sivustot -kohdan ja näkee uuden hallintapaneelin. Siinä vaiheessa monisivusto lakkaa olemasta pelkkä asennusharjoitus ja alkaa muuttua toimintamalliksi.
Ensimmäisen päivän prioriteetit
Ensimmäinen tehtävä ei ole uusien sivustojen rakentaminen. Se on sen määrittäminen, mitä sivuston ylläpitäjät saavat tehdä.
Luo alustava sivustorakenne. Lisää yksi tai kaksi edustavaa sivustoa, älä kaksikymmentä. Asenna vain ne teemat ja laajennukset, joita verkko on valmis tukemaan. Päätä, mitkä laajennukset aktivoidaan verkostotasolla ja mitkä ovat käytettävissä paikallisella sivustotasolla. Jos ohitat tämän hallintavaiheen, toimittajat ja asiakashallinnoijat alkavat kohdella verkostoa kuin tavallista yksisivustoista WordPress-asennusta, ja vietät seuraavan kuukauden selvittämällä vältettävissä olleita poikkeustilanteita.
Kurinalainen ensimmäisen päivän toimintasarja näyttää tältä:
- Luo perustasoiset sivustot: pääbrändi, yksi alueellinen sivusto, yksi testisivusto.
- Rajoita laajennusvalikoimaa: Asenna vain ne, joiden tukemisesta verkosto on sopinut.
- Määritä käyttäjäroolit harkitusti: Erota superjärjestelmänvalvojan oikeudet sivuston järjestelmänvalvojan oikeuksista välittömästi.
- Tarkista rekisteröintiasetukset: Älä jätä avoimia reittejä sivustojen tai käyttäjien luomiseen, ellei se ole tarkoituksellista.
Hallintapaneeli muuttaa vastuun jakautumista
Tavallisessa asennuksessa jokainen sivuston ylläpitäjä voi tuntea olevansa itsenäinen. Monisivustojärjestelmässä tämä itsenäisyys on osittaista.
Verkoston ylläpitäjä vastaa laajennusten asennuksesta, teemojen saatavuudesta ja yleisestä käyttäjäpolitiikasta. Sivuston ylläpitäjät hallinnoivat sisältöä, valikoita, widgettejä ja paikallisia asetuksia heille annettujen käyttöoikeuksien puitteissa. Tämä jako on terveellistä, kun se on dokumentoitu. Se on kaoottista, kun se oletetaan.
Vakaassa Multisite-verkostossa on vähemmän vapauksia kuin löyhässä yksittäisten sivustojen kokoelmassa. Se on ominaisuus, ei puute.
Käytännöllinen hallintamalli
Yksi hyödyllinen malli on kohdella verkostoa kuin alustatuotetta:
| Tehtävä | Omistaa |
|---|---|
| Pääkäyttäjä | Ydinpäivitykset, teemat, laajennusten luettelo, verkkoasetukset |
| Sivuston ylläpitäjä | Sisältö, media, valikot, paikallisten laajennusten aktivointi, jos se on sallittua |
| Alustan vastuuhenkilö | Standardit, lanseerausluvat, julkaisukäytäntö |
| Pääkirjoitukset | Taksonomiat, työnkulut, sisällön laatu |
Tämä rakenne auttaa virastoja ja yritysten tiimejä välttämään yleisimmän hallintapaneelin virheen. Ne ottavat Multisite-ratkaisun käyttöön keskittämisen vuoksi, mutta myöntävät sitten käyttöoikeuksia, jotka johtavat jälleen hajanaisuuteen.
Toinen alusta lähtien noudatettava tapa, jota kannattaa jatkaa, on nimityskäytäntöjen noudattaminen. Sivustojen slugien, järjestelmänvalvojan sähköpostiosoitteiden, ympäristöjen tunnisteiden ja verkkotunnussuunnitelmien tulisi kaikkien noudattaa tiettyä mallia. Jos näin ei ole, jopa teknisesti moitteettoman verkon auditointi ja tuki vaikeutuvat.
SSL-sertifikaattien liittäminen verkkotunnuksiin ja verkkosivustojen julkaiseminen
Tässä vaiheessa useimmat asennusohjeet eivät enää ole hyödyllisiä.
Verkon käyttöönotto on helppoa. Tärkeintä on kuitenkin todellisten sivustojen julkaiseminen todellisilla verkkotunnuksilla ilman virheellisiä uudelleenohjauksia, varmenneongelmia, välimuistin sekaannuksia tai SEO-vaikutuksia. Mainostoimistoille ja yritysryhmille keskeinen haaste ei ole pelkästään Multisite-toiminnon käyttöönotto. Haasteena on sen turvallinen käyttöönotto eri markkinoilla ja verkkotunnuksissa, mukaan lukien DNS, SSL, välimuistin eristäminen ja siirtosuunnittelu (Pagely WordPress Multisite -toiminnoissa).
Verkkotunnuksen kohdistaminen on käyttöönottoprosessi, ei valintaruutu
Kun verkko on otettu käyttöön, jokaiselle tuotantokäytössä olevalle sivustolle on edelleen tehtävä omat verkkotunnuspäätöksensä. Käytännössä tämä tarkoittaa, että verkkotunnuksen on osoitettava oikeaan ympäristöön, kartoitettu sivusto on määritettävä oikein verkon sisällä ja SSL-varmenteen on oltava voimassa ennen sivuston julkaisua.
Se kuulostaa yksinkertaiselta, kunnes mukaan tulee useita tiimejä. Markkinointiosasto vastaa brändin verkkotunnuksesta. IT-osasto vastaa DNS:stä. Palveluntarjoaja myöntää varmenteet. WordPress-tiimi päivittää sivuston asetukset. Jos näitä vaiheita ei suoriteta oikeassa järjestyksessä, julkaisupäivä muuttuu nopeasti kaaokseksi.
Toistettava käynnistysjärjestys
Luo sivusto Network Admin
-hallintapaneelissa. Rakenna sivusto ensin väliaikaisella verkko-URL-osoitteella. Varmista teema, laajennukset ja sisältörakenne ennen kuin otat tuotantodomainin käyttöön.Valmistele mukautettu verkkotunnus
. Verkkotunnuksen on oltava valmis ohjaamaan verkoston isännöintiympäristöön. Älä ajoita sisällön jäädytysjaksoja, ennen kuin verkkotunnuksen omistussuhteet ovat selvillä.Määritä kartoitettu verkkotunnus sivustolle
. Yhdistä verkossa kyseinen verkkotunnus oikeaan sivustoon. Varmista huolellisesti, ettet kartoita väärää verkkotunnusta samannimiseen alisivustoon.SSL:n käyttöönotto ennen julkista julkaisua
. Kartoitettu verkkotunnus, jolla ei ole voimassa olevaa HTTPS-yhteyttä, ei ole valmis julkaistavaksi. Sertifikaatin tila on tarkistettava ennen uudelleenohjauksien kytkemistä.Testaa poikkeustilanteita.
Tarkista käyttöliittymä, järjestelmänvalvojan kirjautuminen, media-URL-osoitteet, kanonisen URL-osoitteen toiminta, lomakkeiden toiminnot sekä kaikki kiinteästi koodatut viittaukset, jotka osoittavat edelleen väliaikaiseen verkko-URL-osoitteeseen.
Verkkotunnuksen kohdistusvirheet johtuvat harvoin itse WordPressistä. Ne johtuvat siitä, että tiimit muuttavat DNS-, SSL- ja sovellusasetuksia väärässä järjestyksessä.
Olemassa olevan erillisen sivuston siirtäminen verkkoon
Tätä seikkaa aliarvioidaan usein. Itsenäisellä sivustolla on jo oma historiansa. Siinä on indeksoitavia URL-osoitteita, uudelleenohjauksia, laajennuksiin liittyviä oletuksia, kiinteästi koodattuja resursseja sekä käyttöönottomalli, joka on rakennettu sivuston itsenäisen toiminnan ympärille.
Ennen siirtoa on päätettävä, siirretäänkö sivusto verkkoon hallinnollisista syistä vai pelkästään käytännöllisyyden vuoksi. Jos kyse on vain käytännöllisyydestä, sivusto kannattaa pitää erillisenä. Vakiintuneen sivuston siirtäminen Multisite-ympäristöön tuo mukanaan URL-osoitteisiin, verkkotunnuksiin ja toimintaan liittyviä riippuvuuksia, joiden perustelut on esitettävä.
Käytännöllinen siirtymän tarkistuslista:
- Sisällön ja median tarkistus: Varmista, että tuonnin yhteydessä rakenne ja viittaukset säilyvät.
- Laajennusten tarkastus: Jotkin laajennukset toimivat eri tavalla monisivustoympäristössä tai vaativat verkkotason hallintaa.
- Uudelleenohjaussuunnitelma: Vanhat polut säilytetään siellä, missä niillä on merkitystä.
- ”Etsi ja korvaa” -tarkistuksen arvio: Tunnista ympäristö-URL-osoitteet, mediaviittaukset ja sarjoitettujen tietojen ongelmat.
- Rollback-määritelmä: Selvitä, mitä ”keskeytä ja palauta” tarkoittaa, ennen kuin siirrät liikennettä tuotantoympäristöön.
SSL:n ja välimuistin eristämiselle tarvitaan nimenomainen omistusoikeus
SSL-palveluiden käyttöönotto vaikeutuu, kun verkossa on useita verkkotunnuksia, joiden käyttöönottoaikataulut vaihtelevat. Jonkun on vastattava varmenteiden myöntämisestä, uusimisen seurannasta ja varmenteiden oikeellisuuden tarkistamisesta. Jos tällaista vastuuhenkilöä ei ole nimetty, projektipäällikkö joutuu tahattomasti toimimaan varmennekoordinaattorina.
Myös välimuistin eristäminen on tärkeää. Yhden sivuston välimuistilogiikka ei saisi aiheuttaa odottamatonta käyttäytymistä toisella sivustolla, jolla on erilaiset evästeet, lokalisointisäännöt tai kirjautuneiden käyttäjien liikennemallit. Jos palvelin tai välimuistikerros käsittelee verkkoa liian laajasti, yhden markkina-alueen vianetsintä voi vaikuttaa toiseen.
Aikaa säästävä käyttöönottotarkistuslista
| Tarkista | Mitä on tarkistettava |
|---|---|
| Verkkotunnuksen tunnistus | Kartoitettu verkkotunnus ulottuu tavoiteltuun ympäristöön |
| HTTPS | Sertifikaatti on voimassa, eikä sekasisältöongelmia ilmene |
| Järjestelmänvalvojan käyttöoikeudet | Toimittajat voivat kirjautua sisään oikean verkkotunnuspolun kautta |
| Uudelleenohjaukset | Vanhat URL-osoitteet ja ensisijaiset kanoniset URL-osoitteet toimivat odotetulla tavalla |
| Varat | Mediatiedostot, skriptit ja lomakkeet ladataan oikealta verkkotunnukselta |
Multisite-sivuston käyttöönotto sujuu parhaiten, kun verkkotunnusten kohdistamista käsitellään hallittuna julkaisuprosessina, ei asetuksena, jonka voi vain kytkeä päälle lopuksi.
Suorituskyky, tietoturva ja verkon skaalaus
Multisite-järjestelmän haastavin vaihe alkaa asennuksen jälkeen.
Verkosto muuttaa WordPressin toimintamallia. Suorituskykyongelmat eivät enää ole paikallisia. Turvallisuuspäätökset eivät enää koske vain yksittäisiä sivustoja. Jokainen poikkeus, jonka sallit yhdelle brändille, alueelle tai asiakkaalle, aiheuttaa lisätyötä tiimille, joka vastaa verkoston muusta osasta.
Toimintahäiriöt eivät juurikaan rajoitu vain kyseiseen kohteeseen
Yksi huonosti toimiva laajennus, yksi resursseja kuluttava kyselymalli tai yksi massatuonti voi heikentää hallintapaneelin suorituskykyä useilla sivustoilla. Esittelysivustolla se on vain ärsyttävää. Verkostossa, jossa on aktiivisia toimittajia, kampanjaliikennettä ja aikataulutettua julkaisutoimintaa, siitä tulee toiminnallinen häiriö.
Suunnittele jaettu infrastruktuuri alusta alkaen. Tämä tarkoittaa yleensä pysyvää objektien välimuistia, huolellisesti määriteltyjä sivuvälimuistisääntöjä, hallittua cron-toimintaa sekä kyselyjen seurantaa testausympäristössä ennen kuin mitään otetaan käyttöön tuotantoympäristössä. Se tarkoittaa myös rehellisyyttä laajennusten kustannusvaikutuksista. Laajennus, joka on hyväksyttävä yhdellä erillisellä sivustolla, voi osoittautua liian kalliiksi, kun se moninkertaistuu kymmenille sivustoille ja tuhansille pyynnöille.
Tuotantokäytössä toimiva skaalausmalli sisältää yleensä seuraavat osat:
- Pluginien keskitetty hyväksyntä: Käsittele jokaista pluginia alustan riippuvuutena, jolla on vaikutuksia tukeen, päivityksiin ja palautuksiin.
- Sivustokohtaiset välimuistisäännöt: Otetaan huomioon evästeet, kirjautumistilat, kielivaihtoehdot ja verkkotunnuskohtainen käyttäytyminen.
- Taustatehtävien hallinta: Jonoita tai rajoita tuontia, synkronointitehtäviä ja hakutietokannan indeksointia, jotta yksi työkuorma ei vie resursseja muilta.
- Kapea teema ja yhtenäinen standardi: Tukittujen mallien vähäisempi määrä nopeuttaa testausta, julkaisujen toteuttamista ja poikkeustilanteisiin reagointia.
- Tietokannan ylläpito: Automaattisesti ladatut asetukset, orpoiksi jääneet taulukot ja liian suuret lokit muodostavat ajan myötä koko verkoston laajuisen rasitteen.
Turvallisuus alkaa käyttöoikeuksien suunnittelusta
Monisivustojen tietoturva murtuu yleensä huonon hallinnon vuoksi ennen kuin se murtuu kehittyneen hyökkäyksen seurauksena. Super Admin -käyttöoikeudet ovat ilmeinen riski, mutta löyhä roolien suunnittelu aiheuttaa yhtä paljon ongelmia. Toimittajat saavat oikeuksia, joita heidän ei pitäisi olla. Sivuston ylläpitäjät ottavat käyttöön kiertotapoja, jotka eivät ole käytäntöjen mukaisia. Virastot luovuttavat verkon ilman selkeää käyttöoikeusmallia, ja kuusi kuukautta myöhemmin kukaan ei osaa selittää, kuka saa tehdä mitäkin.
Määritä rajat jo varhaisessa vaiheessa. Rajoita pääkäyttäjän oikeudet pieneen ryhmään, joka vastaa alustan muutoksista. Päätä, mitkä teemat ja laajennukset ovat ylipäätään käytettävissä. Tarkista tiedostojen lataussäännöt, rekisteröitymiskäytännöt, API-palveluiden saatavuus ja kaikki sivuston rajat ylittävä mukautettu koodi. Lokitiedot ovat myös tärkeitä. Jos verkosto ei pysty selvittämään, kuka on muuttanut asetusta, aktivoinut laajennuksen tai luonut sivuston, ongelmatilanteiden ratkaisu hidastuu nopeasti.
Myös tietoturvatyökalujen on sovittava arkkitehtuuriin. Nopeuden rajoittaminen, haittaohjelmien skannaus, WAF-säännöt ja auditointilokitus tulisi määrittää ottaen huomioon verkkotunnusten kartoitus ja useiden sivustojen omistajuus, eikä niitä tulisi lisätä jälkikäteen ikään kuin kyseessä olisi yksi yksinkertainen asennus.
Varmuuskopiot ovat hyödyllisiä vain, jos palautus vastaa verkkomallia
Monet tiimit väittävät, että heillä on varmuuskopiot, vaikka todellisuudessa kyseessä on vain toimittajan valintaruutu ilman testattua palautusprosessia.
Monisivustojärjestelmä pakottaa käymään vaikeampia keskusteluja. Voiko yhden sivuston palauttaa vaikuttamatta muihin? Voiko yksittäisen sivuston media-aineiston, taulukot ja määritetyt verkkotunnusasetukset palauttaa epäonnistuneen käyttöönoton jälkeen? Kuinka kauan koko verkon palautus kestää, ja kuka sen hyväksyy, kun useat liiketoimintayksiköt käyttävät samaa alusta-arkkitehtuuria?
Useissa ympäristöissä WordPress-sivustoja hallinnoivat tiimit huomaavat yleensä, että sivuston ulkoasun palauttaminen on tärkeämpää kuin brändin varmuuskopiointi. Kirjoita palautusohjeet muistiin. Testaa ne. Varaudu erilaisiin ratkaisuihin, kun kyseessä on yksittäisen sivuston sisältövirhe verrattuna koko verkoston laajuiseen vikaan.
Skaalaus on yhtä paljon itsehillintää kuin infrastruktuuria
Toimivat verkostot eivät kasva suostumalla jokaiseen poikkeukseen. Ne kasvavat vaihtelua hallitsemalla.
Käytä julkaisuprosessia, jossa jaetut komponentit testataan ennen käyttöönottoa. Tarkista käyttämättömät sivustot ja arkistoi ne, joilla ei enää ole liiketoiminnallista merkitystä. Seuraa, mitkä mukautukset aiheuttavat pitkäaikaisia tukikustannuksia. Jos jokin sivusto vaatii epätavallisia laajennuksia, erityistä isännöintitapaa tai toimituksellisia työnkulkuja, harkitse uudelleen, kuuluuko se lainkaan verkostoon.
Tehokkaimmilla monisivustoympäristöillä on muutamia yhteisiä piirteitä:
- Verkkotason asetusten tiukka muutoksenhallinta
- Pieni, luotettava laajennusvalikoima
- Verkkotunnusten, SSL:n, välimuistin ja DNS:n omistusoikeuden dokumentointi
- Selkeät perehdytys- ja työsuhteen päättymismenettelyt toimipisteille
- Säännölliset tarkastukset käyttämättömien kiinteistöjen, vanhentuneiden sääntöjen ja oikeuksien laajentumisen varalta
Multisite-ratkaisu soveltuu vaativien yritysten tai virastojen alustoiksi. Se voi kuitenkin myös keskittää riskit yhteen koodipohjaan, yhteen tietokantatasoon ja yhteen hallintomalliin. Menestyvät tiimit suhtautuvat verkostoon kuin tuotteeseen, jolla on standardit, vastuuhenkilöt ja toimintakuri.
Jos pohdit, onko Multisite-arkkitehtuuri sinulle sopiva ratkaisu, tai tarvitset apua jo asennetun verkoston muuttamisessa vakaaksi toimintaympäristöksi, IMADO tarjoaa tukea WordPress-ratkaisuille, jotka edellyttävät korkeatasoista teknistä osaamista muun muassa Multisite-arkkitehtuurin, monikielisen käyttöönoton, hallinnon, siirtosuunnittelun ja jatkuvan ylläpidon osalta.
