Architektura a multi-tenancy

Jedna instalace Laravixu provozuje libovolný počet webů. Tento článek vysvětluje multi-tenant architekturu — jak se hledá web, jak se k webům vážou uživatelé a oprávnění a jak požadavek putuje od prohlížeče k vykreslené stránce.

Weby jsou tenanti#

Ústředním modelem je Laravix\Cms\Models\Site. Každý web vlastní svůj obsah, média, taxonomie, nastavení, navigaci, uživatele (přes role) a API tokeny — mezi weby nic neprosakuje. Ve Filament administraci je web tenant: URL vypadají jako /admin/{siteId}/... a přepínač vlevo nahoře přepíná mezi weby.

Web má:

• name — veřejný název,
• domain — hostname, na kterém web odpovídá (unikátní v rámci instalace),
• mode — theme (frontend vykresluje Laravix přes Blade) nebo headless (obsah se servíruje přes REST API),
• theme — název adresáře aktivní šablony (režim šablony),
• locales — další jazyky obsahu nad rámec výchozího.

Hledání webu podle domény#

Frontend hledá web podle hostname požadavku: SiteResolver porovnává $request->getHost() se sloupcem domain. Bez shody je výsledek 404. Proto se pole domény webu musí přesně rovnat adrese, kterou návštěvníci používají — i na localhostu.

Pro více webů nasměrujte všechny domény na tutéž aplikaci (stejný document root) a v administraci založte web pro každou doménu.

Tip: S více produkčními doménami nastavte CMS_CROSS_DOMAIN_SWITCHER=true — přepínač tenantů v administraci pak odkazuje na vlastní doménu každého webu (https://{domain}/admin/{id}).

Uživatelé, role a super admin#

Uživatelé jsou globální; přístup se uděluje per web přes pivot site_user s rolí:

Uživatel s is_super_admin = true tohle všechno obchází: má přístup ke každému webu a k oblastem jen pro super adminy — resource Weby a zakládání webů. Vynucení žije v policies (ContentPolicy, MediaPolicy, TaxonomyPolicy) a v override canViewAny() u správcovských resources.

Do panelu se přihlásí ten, kdo je super admin, nebo je členem alespoň jednoho webu.

Životní cyklus požadavku (režim šablony)#

1. Middleware HandleRedirects porovná cestu s tabulkou přesměrování a případně vrátí 301/302/307/308.
2. Následují pluginové routy registrované přes RouteRegistry (např. /docs/...), zbytek chytá catch-all routa cms.show.
3. CmsController najde web podle hostname, rozpozná jazykový prefix v URL a načte publikovaný obsah podle slugu (ContentResolver).
4. PageDataBuilder poskládá vše, co view potřebuje — nastavení, navigaci, mapu médií, překlady, hydratované HTML z builderu.
5. Vykreslí se view themes.{theme}::{type}.show (fallback themes.{theme}::default).

V headless režimu je frontend vypnutý (404) a obsah se servíruje z /api/v1 — viz Headless režim a API tokeny.

Body rozšíření#

Laravix se rozšiřuje přes registry — statické registrační body pro typy obsahu, pole, bloky, nastavení, taxonomie, navigace, routy a Filament pluginy. App\Filament\Resources, Pages a Widgets vaší aplikace se do panelu discoverují automaticky a App\Providers\Filament\AdminPanelProvider dědí z Laravix\Cms\Filament\BaseAdminPanelProvider, takže lze přepsat i konfiguraci panelu. Podrobnosti v článcích Vývoj pluginů a Přehled registrů.

Mašinerie na pozadí#

• Scheduler — laravix:publish-scheduled běží každou minutu a publikuje naplánovaný obsah.
• Fronta — varianty obrázků generuje úloha GenerateImageVariants.
• Eventy — ContentCreated, ContentUpdated, ContentPublished, ContentUnpublished, ContentDeleted, ContentRestored (namespace Laravix\Cms\Events) umožňují napojit se na životní cyklus obsahu.
• Audit — změny se zaznamenávají per web do activity logu; soft-deletnuté záznamy končí v obnovitelném Koši.

Související články#

• Obsahový model
• Headless režim a API tokeny
• Nasazení do produkce