WebToDate/Referenční/Správa více virtuálních serverů

Jak funguje podpora více virtuálních serverů

Systém WebToDate Enterprise podporuje správu více virtuálních serverů z jedné instalace tohoto systému. Takto lze generovat stránky na různé virtuální servery ze stejného obsahu a s využitím stejné nebo různé grafické prezentace.

Všechny virtuální servery v zásadě sdílejí jeden obsah, který může být na každém z nich prezentován v různém výběru a s jiným vzhledem.

Nejedná se ovšem o podporu vytváření více naprosto rozdílných webů s navzájem nepropojeným obsahem – všechny objekty redakčního systému jsou společné pro všechny takto spravované virtuální weby.

K čemu lze podporu více virtuálních webů využít

Tento aparát lze využít v případě, že chceme vytvořit několik tematických sekcí daného webu, kde tyto sekce nejsou reprezentovány určitou skupinou stránek na stejném webu, ale různými virtuálními servery, např. s doménami třetí úrovně.

Pokud má být např. součástí stránek dané organizace publikace nějakého časopisu, který tato organizace vydává, lze tyto stránky umístit buď na adresu www.organizace.cz/casopis/ nebo s využitím podpory více virtuálních serverů na adresu casopis.organizace.cz. Stránky se na tomto serveru mohou zobrazovat ve stejném designu jako na hlavním webu organizace nebo může jít o zcela jiný design.

Na takto vytvořeném webu pak uživatel prochází pouze stránky daného časopisu, můžeme tedy libovolně definovat, ke kterým informacím se zde uživatel "prokliká". Takovýchto virtuálních webů lze podle potřeby definovat libovolný počet.

Co podpora více virtuálních webů neumožňuje

Všechny objekty, které redakční systém používá, jsou v jedné databázi a nejsou oddělené podle virtuálních serverů. To znamená, že jak data, tak interní objekty (šablony, styly apod.) všechny weby sdílejí.

Omezení z toho plynoucí jsou zejména následující:

• Nelze bezpečně ošetřit to, aby daný dokument byl zobrazitelný na jednom virtuálním webu a na druhém ne. Dynamická URL jednotlivých zpráv jsou na všech virtuálních webech stejná a nelze zabránit tomu, aby zpráva zobrazitelná na jednom webu nebyla zobrazitelná i na jiném webu. Tato konfigurace je tudíž nevhodná pro případ, kdy bychom chtěli např. z jedné databáze vytvářet obsah internetového a intranetového serveru zároveň.
• Fulltextové hledání je na všech webech jednotné. Pokud zprávy pro jednotlivé weby neoddělíme ještě dalším interním kritériem (např. zařazením do kategorií či publikací) nelze prohledávat pouze zprávy z daného virtuálního webu.
• Nelze programově zajistit, aby daný formátovací prvek (např. šablona či styl) byl použitelný pouze na daném webu. To musí vhodným způsobem definovat administrátor WebToDate.
• Nelze úplně oddělit skupiny uživatelů spravující jednotlivé weby.
• Možnosti obsahového i grafického oddělení výstupů jednotlivých modulů WebToDate na různých virtuálních serverech jsou omezené. Nelze např. zajistit, aby modul Kalendář akcí prezentoval na jednom virtuálním webu jiná data než na jiném, apod. Graficky lze pro daný modul využít pomocí vynucení šablon pro stejné typy stránek různé šablony, ale už ne např. formátovací styly, stejně tak globální nastavení každého modulu je společné pro všechny virtuální servery.

Způsob konfigurace více virtuálních serverů

Podporu více virtuálních serverů je třeba konfigurovat přímo v databázi. Vyplní se obsah jedné databázové tabulky (NEWSSERVER), v zásadě je třeba zadat fyzickou cestu k domovskému adresáři daného serveru a URL, které má tento adresář reprezentovat.

Dále je třeba v příslušném www serveru (Apache nebo IIS) konfigurovat odpovídajícím způsobem jednotlivé virtuální servery, jak je znázorněno na následujícím obrázku.

Při konfiguraci dalšího virtuálního serveru tedy postupujte následovně:

1. Založte nový adresář, který bude nastaven jako domovský adresář dalšího virtuálního serveru. Tento adresář musí být v adresářové struktuře na stejné úrovni vnoření jako adresář wwwroot, který je při výchozí instalaci domovským adresářem výchozího serveru; název je např. wwwroot2. Tento adresář bude domovským adresářem druhého virtuálního serveru.
2. Na druhém virtuálním serveru založte virtuální adresář scripts, který je fyzicky mapován na fyzický adresář scripts stejně jako u výchozího serveru.
3. Na druhém virtuálním serveru založte virtuální adresář assets a namapujte jej na fyzický adresář wwwroot/assets/. Tím bude zajištěno, že všechny soubory z databáze zdrojů budou mít na obou serverech stejné relativní adresy. Takto přesně to ovšem platí pouze při zachování výchozí konfigurace. Přesné uložení souborů ve zdrojích závisí na nastavení konfiguračních konstant v souboru global.php, např. na konstantě ASSETS_PUBLICFILES apod., proto je třeba v tomto případě se přizpůsobit zvolenému způsobu ukládání souborů.
4. Pokud používáte funkci Obrázky, postupujte obdobně jako u zdrojů i pro soubory uložené tímto způsobem (adresář je daný konstantou WWWIMAGES v global.php).
5. Založte nový záznam v databázové tabulce NEWSSERVER, který definuje nový virtuální server.

Záznam je třeba vytvořit s přímým přístupem do databáze, pro tento úkon nemá administrační rozhraní WebToDate žádný interface. Jednotlivé sloupce této tabulky se vyplňují následovně:

• ID: interní unikátní ID serveru, např. číslo 2
• URL: URL home adresáře virt. serveru, např. "http://casopis.organizace.cz" (bez uvozovek a bez posledního lomítka)
• CESTA : fyzická cesta k home adresáři virtuálního serveru, např. "C:\Inetpub\WWWDev\wtd_inst\wwwroot2" (opět bez uvozovek a bez posledního lomítka)
• NAZEV: nějaký název tak jak se bude zobrazovat v redakčním rozhraní
• CESTATXT: nevyplňuje se

Záznamy v databázové tabulce se zakládají jen pro další servery, nikoliv pro první výchozí server, na kterém WebToDate běží.

Generování stránek

Pokud je úspěšně provedena konfigurace podpory více virtuálních serverů, ve formuláři pro definici stránky se zobrazuje nabídka příslušnosti vybrané stránky k danému virtuálnímu serveru. Každá stránka v tomto případě patří právě k jednomu virtuálnímu serveru a do jeho adresáře na serveru se generuje. Všechna další nastavení stránek jsou společná, stránky se tedy nacházejí v jednom stromu stránek, stejným způsobem se nastavují přístupová práva (přístup týmů k oblastem na stránkách) apod.

Každou zprávu pak můžeme ve WebToDate řadit na libovolný počet stránek, tyto stránky mohou náležet různým virtuálním serverům. Každé instanci zprávy na stránce přiřazujeme nějaký styl, na různých stránkách mohou být styly různé, tudíž lze stejnou zprávu formátovat různě na každém virtuálním webu. Pokud chceme, aby po klepnutí na zprávu stránka s tělem dokumentu byla opět na každém serveru v jiném formátování, je třeba v příslušném WebToDate stylu zajistit v URL zpráv vynucení jiné než výchozí šablony.

Příslušnost stránky k virtuálnímu serveru

Příslušnost stránky k virtuálnímu serveru se vybírá ve vlastnostech stránky, pole Server. Podle této volby se stránka generuje do odpovídajícího fyzického adresáře na disku www serveru.

První server, na kterém WebToDate běží, je zde označen jako Výchozí, ostatní názvy serverů se zobrazují tak, jak byly vloženy v tabulce NEWSSERVER.

Doporučení pro implementace využívající více virtuálních serverů

Příslušnost k danému serveru nastavená ve vlastnostech stránky je důležitá zejména pro stránky jednotlivých sekcí www prezentace zobrazované návštěvníkům webu. U šablon či předloh stránek toto nastavení již tak důležité není – WebToDate je schopen např. při generování stránky na daném serveru dohledat i šablonu, která je nastavená pro danou stránku a nachází se fyzicky na jiném virtuálním serveru. Z hlediska přehlednosti celého řešení je ovšem samozřejmě vhodnější stránky související s daným virtuálním serverem ukládat vždy na daný server.

Struktura dalšího virtuálního serveru se zpravidla implementuje jako další část stromu kategorií, kde domovský adresář serveru je reprezentován další kategorií v nejvyšší úrovni vnoření. Takový způsob využití je ovšem třeba vždy ošetřit v XSLT transformacích pro navigace – v příslušné transformaci je třeba nastavit, že se využívá jen daná část stromu příslušná pro daný virtuální server. Transformace dostává jako data vždy XML kód celého stromu kategorií, je tedy vhodné (zpravidla pomocí výběru ID kategorie) omezit zpracování v transformaci na odpovídající část stromu.

Z hlediska implementace designu je zpravidla vhodnější pro šablony dalšího virtuálního serveru volit jiné názvy oblastí než na výchozím virtuálním serveru. Jen tak lze totiž využít toho, že pro každou oblast lze nastavit seznam přípustných stylů. Pro další virtuální server se zpravidla použijí jiné WebToDate styly než na výchozím serveru (pokud mají servery různý grafický design), při stejných názvech oblastí by se musely definovat pro danou oblast přípustné styly používané na obou virtuálních serverech, což by mohlo způsobovat problémy uživatelům – editorům spravujícím obsah těchto oblastí.

Pokud se zprávy zobrazují vždy jen na jednom z virtuálních serverů, lze definovat výchozí předlohy (např. ve stromu kategorií) pro každý virtuální server jinak a není třeba toto nějak speciálně ošetřovat. Pokud je třeba využít stejnou zprávu na různých virtuálních serverech se zobrazením přes různé předlohy, lze využít techniku vynucení jiné předlohy přes parametr tmplid v URL. Ve stylu pro zobrazení zpráv na dalším virtuálním serveru se použije zhruba následující kód (35 je ID zvolené předlohy):

<a href="<!--WTD_F(TITLELINK)-->&tmplid=35"><!--WTD_F(TITLE)--></a>

Pro generování stránek je třeba si uvědomit, že náhled se zobrazuje přes výchozí server, kdežto vygenerovaná stránka bude stahovaná přes další virtuální server. Tato skutečnost má vliv zejména na využívání externích CSS souborů s definicemi stylů. Je třeba zajistit, aby potřebný CSS soubor či soubory měly na obou virtuálních serverech stejnou relativní adresu, v opačném případě dojde k tomu, že buď v náhledu nebo v cílové stránce nebude možné CSS soubor nalinkovat a stránka se zobrazí bez správných CSS stylů.