Multisite CMS ima smisla kada više sajtova deli deo poslovne logike, korisničkih uloga, komponenti ili procesa objavljivanja, ali svaki sajt i dalje treba da ima sopstvenu adresu, sadržaj i uređivački kontekst. Jedan backend tada može da smanji dupliranje posla, dok frontend i pravila po sajtu ostaju dovoljno odvojeni.
To ne znači da svaki projekat sa više domena treba spojiti u jednu aplikaciju. Ako su sajtovi potpuno nezavisni, imaju različite timove, različite bezbednosne zahteve ili samo slučajno pripadaju istoj grupaciji, odvojeni CMS-ovi često su jednostavniji. Prava odluka zavisi od toga šta se zaista deli, a ne od samog broja domena.
Šta multisite CMS zapravo objedinjuje
U multisite arhitekturi postoji zajednički administrativni sloj, ali više javnih sajtova. Zajednički sloj može da obuhvati prijavu korisnika, upravljanje ulogama, medijsku biblioteku, komponente, taksonomije, tok odobravanja i deo poslovnih integracija. Svaki sajt, s druge strane, može imati sopstveni domen, navigaciju, SEO podešavanja, jezik, katalog ili urednički tim.
Važno je razlikovati tri modela koja se često nazivaju multisite:
- Jedna aplikacija, više sajtova: svi sajtovi koriste isti kod i centralni backend, dok se sadržaj razlikuje prema identitetu sajta.
- Zajednička platforma, odvojene instance: sajtovi dele razvojne standarde ili komponente, ali imaju zasebne baze, deploy procese ili administracije.
- Jedan sajt sa više domena: različite domene samo prikazuju varijante istog sadržaja. Ovo nije nužno pravi multisite i može imati drugačije SEO i uredničke posledice.
Na primer, korporativna grupa može imati centralni portal, sajtove poslovnih jedinica i posebne kampanjske ili regionalne sajtove. Ako se logotip, kontakt podaci, navigacioni obrasci ili proces odobravanja održavaju na sličan način, centralizovana platforma može biti opravdana. Ako svaki brend ima potpuno drugačiji model sadržaja i različite vlasnike, centralizacija može napraviti više ograničenja nego koristi.
Kada jedan backend donosi stvarnu vrednost
1. Kada postoji stabilan zajednički model
Najbolji kandidat za multisite CMS ima ponovljive tipove sadržaja i komponente: vesti, lokacije, zaposlene, proizvode, studije slučaja, događaje ili kontakt forme. To ne znači da svaki sajt mora koristiti sve tipove, već da platforma može jasno definisati šta je zajedničko, a šta pripada samo jednom sajtu.
Ako se struktura menja od projekta do projekta i nema stabilnih obrazaca, zajednički model brzo postaje kompromis. Urednici tada dobijaju mnogo opcionalnih polja i pravila koja nisu relevantna za njihov sajt.
2. Kada su centralni procesi važniji od lokalne autonomije
Multisite je koristan kada centralni tim treba da uvede komponentu, promeni pravilo pristupa ili ažurira deo sistema za više sajtova. Primer može biti centralno upravljanje obrascima, saglasnostima, analitikom ili statusima objavljivanja.
Ovo je prednost samo ako je jasno ko donosi odluke. Jedan backend bez definisanog vlasništva često vodi do sporova: jedan tim želi novu funkciju za svoj sajt, dok drugi strahuju da će promena uticati na sve ostale.
3. Kada se sadržaj deli namerno, a ne slučajno
Neki podaci treba da budu dostupni na više sajtova, ali ne nužno u istoj formi. Centralna lokacija može biti prikazana na korporativnom sajtu i na sajtu poslovne jedinice; centralni proizvod može imati različit opis po tržištu; pravni dokument može biti obavezan na svim domenima.
Za svaki takav slučaj treba definisati izvor istine: gde se zapis uređuje, ko ga odobrava, kada se kopija osvežava i šta se dešava ako lokalni sajt mora da odstupi. Bez toga se „deljeni sadržaj“ pretvara u nevidljivu zavisnost.
Ključna arhitektonska odluka: šta je zajedničko, a šta izolovano
Pre izbora tehnologije napravite mapu deljenja. Ona treba da obuhvati najmanje sadržaj, korisnike, medije, konfiguraciju, kod, podatke iz integracija i objavljivanje.
| Oblast | Može biti zajednička | Često treba izolovati |
|---|---|---|
| Sadržaj | Globalni dokumenti, taksonomije, osnovni podaci | Lokalne vesti, kampanje i urednički nacrti |
| Korisnici | Identitet i centralna autentifikacija | Prava po sajtu i po tipu sadržaja |
| Komponente | Design system i validirani blokovi | Specifične funkcije pojedinačnog brenda |
| Mediji | Odabrani centralni resursi | Privatni ili tržišno specifični materijali |
| Konfiguracija | Tehničke podrazumevane vrednosti | Domen, jezik, SEO i navigacija po sajtu |
| Integracije | Centralni monitoring i zajednički servisi | CRM, katalog ili tokovi koji pripadaju jednom sajtu |
Ova matrica je korisnija od opšteg zahteva „da sve bude u jednom CMS-u“. Ona pokazuje gde centralizacija zaista smanjuje rad, a gde bi mogla da ugrozi autonomiju ili bezbednost.
Kako se organizuju sadržaj i identitet sajta
Svaki zapis u multisite sistemu mora imati jasan kontekst. Najčešći pristup je da sadržaj pripada jednom sajtu, više sajtova ili centralnom prostoru. Ta pripadnost mora da utiče na prikaz, pretragu, dozvole, URL i objavljivanje.
Za svaki sajt obično se definišu:
- domeni i dozvoljene varijante domena;
- jezik, lokalizacija, vremenska zona i format datuma;
- navigacija, meniji i struktura URL-ova;
- SEO podrazumevane vrednosti, kanonski URL i pravila indeksiranja;
- brend elementi, šabloni i dozvoljene komponente;
- uredničke uloge i tok odobravanja;
- integracije, forme, primaoci obaveštenja i analitički identifikatori.
Posebno treba paziti na zajedničke komponente. Centralno ažuriranje komponente može biti korisno, ali samo ako postoji kompatibilnost unazad i mogućnost kontrole. Ako se promena automatski primeni na sve sajtove, testiranje mora obuhvatiti svaki aktivni frontend i svaki relevantni sadržajni scenario.
Uloge, dozvole i granice pristupa
Jedan nalog ne bi trebalo automatski da dobije pristup svim sajtovima. Potrebno je odvojiti identitet korisnika od njegovog opsega ovlašćenja. Isti urednik može imati pravo da objavljuje vesti na jednom sajtu, da samo predlaže izmene na drugom i da nema pristup trećem.
Praktičan model može imati centralnog administratora platforme, administratora pojedinačnog sajta, urednika, autora i prevodioca. Pored uloge, dozvole treba vezati za konkretan sajt, tip sadržaja i radnju: kreiranje, izmena, odobravanje, objavljivanje, brisanje ili upravljanje podešavanjima.
Ne treba zanemariti ni pregled aktivnosti. Audit log treba da omogući odgovor na pitanja ko je promenio zapis, na kom sajtu, kada i iz kog statusa u koji. Kod više domena trag promena nije dodatak, već deo operativne kontrole.
Multisite i više jezika nisu ista stvar
Regionalni ili jezički sajtovi često pokreću potrebu za multisite arhitekturom, ali jezik sam po sebi ne određuje model. Jedan sajt može imati više jezičkih verzija, dok odvojeni sajtovi mogu biti potrebni kada se razlikuju tržište, katalog, pravni uslovi ili urednički tim.
Za odluke o prevodima, lokalizaciji i hreflang oznakama korisno je razdvojiti tehničko deljenje od uredničkog vlasništva. Dodatni kontekst pruža tekst Višejezični custom CMS: prevodi, lokalizacija i hreflang. U multisite sistemu treba unapred definisati da li je prevod kopija centralnog sadržaja, zaseban zapis povezan sa originalom ili potpuno nezavisan lokalni sadržaj.
Integracije i deljeni podaci
Backend koji upravlja sa više sajtova često se povezuje sa CRM-om, ERP-om, katalogom, sistemom za prijave ili internim servisima. Najveća greška je pretpostavka da zajednički CMS automatski znači da svi sajtovi treba da dele sve podatke.
Za svaki interfejs treba zabeležiti smer razmene, vlasnika podatka, učestalost sinhronizacije, ponašanje u slučaju greške i pravila pristupa. Na primer, kontakt forma može koristiti zajednički CRM, ali različite forme moraju imati različite izvore kampanje, primaoce i dozvole.
Ako su leadovi, kontakti i personalizacija važan deo sistema, zasebna analiza integracije je korisnija od opšte odluke o multisite modelu. Pogledajte Custom CMS + CRM integracija: leadovi, kontakti i personalizacija za pitanja koja treba razrešiti pre implementacije.
Prednosti i kompromisi
| Potencijalna prednost | Mogući kompromis |
|---|---|
| Jedinstven proces uređivanja | Promena procesa može uticati na više timova |
| Ponovna upotreba komponenti | Previše generičke komponente ograničavaju dizajn |
| Centralna kontrola pristupa | Pogrešno podešena dozvola ima širi domet |
| Deljeni sadržaj i integracije | Greška u sinhronizaciji može se proširiti na više domena |
| Jedinstveno održavanje koda | Deploy zahteva testiranje svih sajtova |
Drugim rečima, multisite smanjuje određene vrste dupliranja, ali povećava potrebu za standardima, testiranjem i jasnim vlasništvom. On nije prečica za loše definisan sadržajni model.
Kada je bolje koristiti odvojene CMS instance
Odvojene instance su često razumniji izbor kada sajtovi imaju različite bezbednosne zone, različite cikluse razvoja ili nezavisne vlasnike budžeta i sadržaja. Isto važi kada jedan sajt mora biti dostupan čak i tokom održavanja drugog, ili kada su zahtevi za skaliranje i integracije bitno različiti.
Odvojena instalacija može značiti više posla oko ažuriranja i komponenti, ali pruža jasniju granicu rizika. Zato odluku ne treba donositi samo na osnovu broja sajtova. Uporedite cenu operativnog održavanja sa cenom koordinacije, testiranja i upravljanja zavisnostima u zajedničkoj platformi.
Kako izgleda dobar plan implementacije
- Popišite sajtove i vlasnike. Zabeležite domene, timove, jezike, sadržajne tipove, integracije i posebna pravila.
- Napravite matricu deljenja. Za svaki podatak označite da li je globalan, vezan za jedan sajt ili deljen uz lokalnu izmenu.
- Definišite granice. Odredite šta administrator jednog sajta može da vidi i menja, a šta ostaje pod centralnom kontrolom.
- Modelujte sadržaj pre interfejsa. URL, statusi, verzije i odnosi između zapisa moraju biti jasni pre izrade ekrana za administraciju.
- Testirajte stvarne scenarije. Uključite objavljivanje, povlačenje sadržaja, grešku integracije, promenu domena, lokalizaciju i oporavak iz rezervne kopije.
- Uvedite kontrolisane promene. Zajedničke komponente i kod treba verzionisati, dokumentovati i puštati kroz okruženja za testiranje.
Prilikom izbora pristupa može pomoći i poređenje headless i klasičnog custom CMS-a, naročito ako više sajtova treba da koristi isti sadržaj kroz različite frontende. Relevantna pitanja obrađena su u tekstu Headless CMS vs klasičan custom CMS: kako izabrati arhitekturu. Ako sadržaj treba da napaja i aplikacije, portale ili druge kanale, pogledajte i API-first CMS: kada sadržaj treba da hrani više kanala.
Koja pitanja treba postaviti pre odluke
- Da li sajtovi dele dovoljno stabilan model sadržaja ili samo pripadaju istoj organizaciji?
- Ko je vlasnik centralnih podataka, a ko lokalnih izmena?
- Da li jedan incident može ugroziti sve domene?
- Da li urednički timovi zaista žele zajedničke tokove rada?
- Kako će se testirati promena zajedničkog koda?
- Da li postoji zahtev da svaki sajt ima nezavisan deploy, backup ili audit?
- Hoće li budući sajtovi koristiti iste komponente ili će svaki zahtevati poseban model?
Ako odgovori pokazuju visok stepen deljenja, sledeći korak je razrada podatkovnog modela, dozvola i granica po sajtu u okviru custom CMS rešenja. Ako se sajtovi razlikuju prvenstveno po strukturi, dizajnu i sadržaju, a ne po centralnoj logici, korisno je prvo razmotriti obim pojedinačne izrade sajta i tek zatim odlučiti da li zajednička platforma donosi opravdanu vrednost.
Dobar multisite CMS počinje od jasne granice: šta treba centralizovati da bi se smanjio rad, a šta mora ostati odvojeno da bi sajtovi zadržali kontrolu. Kada su ta pravila dokumentovana, izbor tehnologije postaje posledica arhitekture, a ne njena zamena.
