Jak navrhuji firemní CMS a společný základ aplikací na Laravelu

Při tvorbě webů se opakují stejné potřeby: přihlášení, úpravy obsahu nebo nastavení toho, kdo smí co měnit. Starter kit je připravený základ, který tyto běžné funkce spojuje. Vývojář díky němu nezačíná pokaždé od nuly a může se věnovat tomu, co potřebuje konkrétní klient.

Starter kit popsaný v článku slouží výhradně pro naše firemní projekty. Je rozdělený do několika soukromých balíčků v neveřejné organizaci na GitHubu, kde spravujeme jeho kód. Veřejně si jej nelze prohlédnout ani stáhnout; zde sdílím principy návrhu a zkušenosti z vývoje.

Z pohledu správce jde o systém pro správu obsahu neboli CMS: podobně jako ve WordPressu přes administraci upravuje stránky, články a obrázky. Základem je Laravel, nástroj pro vývoj webových aplikací, který umožňuje doplnit také firemní procesy a funkce na míru. Jde o vlastní systém; doplňky WordPressu v něm použít nelze.

K sepsání článku mě přivedla otázka, jak ušetřit práci při založení webu a současně usnadnit jeho další rozvoj. Ukážu, z čeho se náš společný základ skládá, jak pomáhá při běžné správě a která rozhodnutí mi dala při vývoji nejvíc zabrat.

Od společného skeletonu k modulárnímu základu

Původní skeleton představoval připravenou výchozí aplikaci: společnou kostru, která už v jednom projektu spojovala opakovaně potřebné funkce. Lze si jej představit jako výchozí podobu webu, kterou vývojář přizpůsobil konkrétnímu zadání. Šetřil tak opakovanou přípravu stejného základu a dával projektům společný výchozí bod.

Jak jednotlivé projekty získávaly vlastní úpravy, přenos dalších vylepšení mezi nimi se komplikoval. Tehdy jsem si uvědomil, že společný základ musí pomáhat i dlouho po založení webu. Potřeboval jsem jasněji oddělit sdílené funkce od úprav pro konkrétního klienta. Právě dlouhodobá údržba pro mě byla hlavním důvodem ke změně architektury.

Čtyři části, ze kterých se aplikace skládá

Základem zůstává Laravel. Zatímco oficiální starter kity pomáhají se startem aplikace, modulární platforma navíc sjednocuje opakované funkce, jejich spolupráci a možnosti rozšíření.

Core platforma: společné technické zázemí

Core, tedy společné jádro, propojuje ostatní části. Spravuje pluginy a šablony, kontroluje, co potřebují ke svému fungování, a poskytuje společná pravidla nastavení, práce s jazyky a zapojení do administrace.

Konkrétní obsahové nebo obchodní funkce patří mimo jádro. Core tak nemusí obsahovat logiku blogu ani objednávek a zůstává využitelný pro různé typy aplikací.

Pluginy: funkce podle potřeb projektu

Pluginy přidávají ucelené funkce podle potřeb webu: správu stránek a článků, představení týmu, reference zákazníků, oznámení, vyhledávání nebo e-shop. Každý přináší potřebná data, chování i ovládání v administraci. Menší firemní web si tak vystačí s prezentací služeb a kontaktním formulářem, zatímco obchod využije také produkty, dopravu a platby. Společný základ neznamená, že každý projekt musí používat všechny dostupné funkce.

Technicky si plugin lze představit jako Laravel balíček: samostatný doplněk aplikace. Dodržuje navíc pravidla našeho systému, aby jej jádro umělo zapnout a propojit s administrací. Ne každý běžný Laravel balíček je automaticky takovým spravovaným pluginem.

Šablony: vzhled a prezentace

Šablony určují, jak se obsah a funkce zobrazují návštěvníkům. Patří sem rozložení stránek, vizuální komponenty, styly a další prvky vzhledu. Obchodní pravidla i data zůstávají oddělené, takže změna designu neznamená přepis funkční části aplikace.

Vlastní vzhled může vycházet ze společné šablony a měnit pouze potřebné části. Třeba jinou hlavičku, rozložení stránky nebo kartu produktu.

Projektové úpravy: prostor pro konkrétní zadání

Projektová vrstva spojuje vybrané části a obsahuje to, co je specifické pro danou aplikaci: vlastní pole, doplňující pravidla, integrace nebo upravené chování. Tato rozšíření mají své místo odděleně od sdílených balíčků.

Rozběhnutí webu a srozumitelná instalace

Práce s kitem začíná podle popsaného postupu. Vývojář připraví nastavení, databázi a vzhled webu; kontrolní nástroje mu pomohou odhalit, zda něco chybí. Nový člen týmu tak nemusí objevovat skryté instalační kroky.

Lokální vývoj odděluje skutečná data klienta od ukázkového obsahu pro zkoušení. Čistý web začíná neutrálním obsahem a průvodcem prvními kroky. Pojistky při spuštění brání tomu, aby postup pro obnovu testovacího webu omylem smazal data už používané aplikace.

Provozní připravenost zahrnuje i práci, kterou návštěvník přímo nevidí. Přihlašovací kód potřebuje obdržet hned, zatímco méně naléhavé e-maily se mohou odeslat na pozadí. Když se odeslání nezdaří, správce musí chybu dohledat a mít možnost pokus opakovat.

Zapínání funkcí s předvídatelným výsledkem

Instalace pluginu a jeho aktivace jsou dvě odlišné věci. Funkci lze připravit před jejím zapnutím a při aktivaci se zohledňují potřebné závislosti. Díky tomu je jasné, které části aplikace jsou skutečně v provozu.

Vypnutí funkce zachovává její data; jejich odstranění je samostatné vědomé rozhodnutí. Přidání funkce automaticky nepřiděluje nová oprávnění všem uživatelům. Správce má kontrolu nad tím, kdo ji může používat. Pro údržbu nebo přípravu spuštění lze návštěvníkům zobrazit srozumitelnou informační stránku, zatímco oprávněný správce dál pracuje s webem. Je tak oddělené to, co už je připravené uvnitř aplikace, od toho, co má být právě dostupné veřejnosti.

Administrátorské účty, oprávnění a bezpečnost

Přístup do administrace je oddělený od oprávnění provádět jednotlivé akce. To, že se uživatel přihlásí, ještě neznamená, že smí upravovat každý záznam nebo exportovat všechna data.

Důsledná ochrana účtu pokračuje i po přihlášení. Druhé ověření, například jednorázovým kódem, chrání také neveřejné náhledy; změna hesla ukončí ostatní přihlášení. Důležité zásahy se zapisují do historie. Osobní údaje lze dohledat, exportovat a řízeně vymazat s ohledem na související záznamy, například nedokončené objednávky. Pravidla jejich uchovávání se přizpůsobují provozovateli.

Bezpečnostní nastavení odpovídá konkrétnímu webu. Patří sem ochrana formulářů před zneužitím i omezení příliš častých požadavků. Právo pracovat s údaji se kontroluje také při hromadné změně, tisku nebo exportu.

Administrace, která počítá s rozšířením

Administrace nabízí podobné ovládání napříč funkcemi. Správce si může uložit oblíbené filtry a pohledy, sdílet je s kolegy a podle oprávnění data exportovat nebo vytisknout. Historie změn je u upravovaného záznamu, náhled pomáhá před zveřejněním a vybrané záznamy lze upravovat hromadně. U delších formulářů zůstává ukládání po ruce a při zavírání rozpracovaného formuláře systém upozorní na neuložené změny. Administrace počítá také s menší obrazovkou telefonu.

Projekt může rozšířit vybraná místa formuláře, výpisu nebo exportu. Kvůli jednomu poli nemusí kopírovat celou společnou část a udržovat její vlastní variantu. Rozšíření zůstává součástí konkrétní aplikace.

Příkladem je zvláštní údaj o produktu. Nestačí přidat políčko: musí být jasné, jaké hodnoty přijímá, kdo jej smí upravovat a kde se zobrazí. Připravené vývojářské nástroje pomáhají dodržet stejný způsob ovládání jako u ostatních funkcí.

Jeden web ze tří pohledů

Jak části spolupracují v konkrétním webu

Obsahový web spojuje vybrané funkce se šablonou a úpravami podle zadání klienta. Tentýž zveřejněný obsah může přes připravené rozhraní poskytovat také další aplikaci, například jinému webu nebo mobilnímu katalogu. Toto rozhraní se označuje jako API a lze si je představit jako řízené předávání dat mezi systémy. Přístup respektuje oprávnění i zveřejněné jazykové verze; rozpracované články nebo soukromé údaje zákazníků se tímto způsobem nestávají veřejnými. Pro čtení obsahu není potřeba vytvářet jeho druhou, ručně udržovanou kopii.

U e-shopu se jednotlivé části propojují v celou nákupní cestu. Zákazník vybere produkt, uplatní případný slevový kód, zvolí dostupnou dopravu a platbu a před odesláním vidí výslednou cenu. Obchod pracuje s nastavením daně, nákupem na firmu, doklady i platebními údaji včetně QR platby. U nedostupného produktu může nabídnout upozornění na opětovné naskladnění. Šablona určuje podobu těchto obrazovek, obchodní pravidla však zůstávají ve funkční části. Změna vzhledu proto sama o sobě nemění výpočet ceny.

Spolupráce jednotlivých částí musí zachovat také význam uložených dat. Objednávka si uchovává název produktu, cenu a údaje zákazníka platné při jejím vytvoření. Pozdější změna katalogu nebo adresáře nesmí tuto historii přepsat. Objednávka se ukládá jako ucelená operace a navazující zpracování začíná až po jejím úspěšném uložení.

Jasná pravidla potřebuje také opakované odeslání. Dvojí kliknutí nemá vytvořit dvě objednávky a opakovaný pokus po chybě nemá znovu provést to, co už uspělo.

Správa obsahu a její souvislosti

Správa obsahu počítá s přípravou článku dopředu: redaktor může zkontrolovat náhled a naplánovat zveřejnění. U každého jazyka upravuje také titulek, popisek a obrázek pro sdílení; náhledy pomáhají představit si výsledek ve vyhledávání i na sociálních sítích. Systém udržuje přehled adres pro vyhledávače a propojení jazykových verzí. Přesměrování pomáhají při změně adres a evidence nenalezených stránek ukazuje, kde návštěvníci narážejí na nefunkční odkazy. Vyhledávání na webu propojuje obsah z různých zapnutých funkcí.

Obrázky jsou důležitou součástí redakční práce. Systém z nahrané fotografie připravuje velikosti a úsporné formáty pro různá místa na webu. Redaktor označí důležitou část snímku, která má zůstat vidět při ořezu, a výsledek si prohlédne v náhledu. Oprávněný správce může upravit pravidla zpracování; dotčené obrázky se pak přepočítají na pozadí. Zpracování zahrnuje i zmenšení příliš velkých originálů a odstranění nepotřebných metadat. Není tak nutné ručně chystat každou variantu zvlášť.

Text se zadává na jednom místě a společně se zpracovává pro stránku, výsledky hledání, stručné popisky i předání překladové službě. Díky tomu různé části pracují se stejným významem textu a návštěvník nevidí technické značky editoru. Překladové a AI služby redakci pomáhají, ale jejich návrhy stále kontroluje člověk. Editor zůstává použitelný i bez volitelné externí služby.

Lokalizace: správný jazyk pro každého uživatele webu

Jazykové nastavení ovlivňuje také e-maily, oznámení, doklady a formát cen nebo dat. Jazyk návštěvníka se přitom může lišit od jazyka správce: objednávka vytvořená na anglickém webu neznamená, že český pracovník má dostávat anglická oznámení. Každá zpráva potřebuje respektovat kontext svého příjemce.

Publikování se posuzuje pro každý jazyk zvlášť, aby návštěvník neviděl rozpracovaný překlad. U pomocných textů lze použít náhradní jazyk, ale dosud nevydaná jazyková verze stránky musí zůstat neveřejná.

Kvalita: od jednotlivých kontrol k fungujícímu webu

Kvalitu podporují automatické testy, tedy opakovatelné kontroly očekávaného chování, a nástroje hledající chyby v kódu. Samotný počet úspěšných kontrol ale neprokazuje, že celý web dobře funguje.

Tyto kontroly proto doplňuje používání webu v roli redaktora, zákazníka nebo správce. Zákazník například projde od výběru zboží přes objednávku až k otevření dokladu. Tak se odhalí chyby ve spolupráci funkcí, které samostatně působí v pořádku.

Stejně důležité je ověřit novou instalaci a aktualizaci s vlastními daty i úpravami klienta. Kontrolují se podporované verze navazujících nástrojů, čitelnost, ovládání klávesnicí a použití na mobilu. Úspěch na počítači jednoho vývojáře nestačí.

Výkon složené aplikace

Výkon závisí na celé stránce. Menu, obrázky i produkty mohou jednotlivě fungovat rychle, ale dohromady zbytečně opakovat načítání stejných údajů. Rychlost proto ověřujeme s obsahem odpovídajícím běžnému používání.

Stejný princip platí v administraci: náročnější údaje se načtou až po otevření příslušné části. Pomáhá také mezipaměť, která uchovává připravené výsledky. Při změně obsahu nebo nastavení se musí obnovit, aby rychlý web zároveň ukazoval aktuální informace.

Dokumentace a kontext pro AI agenty

Součástí používaných balíčků jsou návody k běžným úpravám a řešení problémů. Vývojář je může procházet při práci a doplnit postupy konkrétního projektu. Ví tak, kam změna patří a jaké další části ovlivní.

Stejný kontext potřebují AI agenti, tedy nástroje pomáhající psát a upravovat kód. Jasné konvence, dostupná dokumentace a nástroje jako Laravel Boost pomáhají pracovat v hranicích projektu. Podrobněji se tomu věnuji v článku o vibe codingu v Laravelu a guardrailech pro AI agenty.

Dokumentace se mění spolu s aplikací a popisuje ověřené chování. Srozumitelné hranice a konvence pomáhají také při převzetí existující Laravel aplikace.

Aktualizace jako součást návrhu

Core, pluginy a šablony mají vlastní verze a vyjadřují své závislosti. Aktualizace tak respektují kompatibilitu jednotlivých částí a projektové úpravy zůstávají oddělené od aktualizovaného společného kódu.

Způsob aktualizace rozlišuje společné nastavení a vlastní úpravy projektu. Tam, kde to struktura umožňuje, porovnává jednotlivé položky místo celých souborů. Pokud si například projekt doplní vlastní nastavení, nemusí to bránit převzetí nesouvisejícího vylepšení. Jestliže se stejná položka změnila na obou stranách, vývojář vidí konkrétní konflikt a může vědomě zachovat projektovou variantu. Nastavení, které patří výhradně projektu, zůstává pod jeho správou. Tím se omezuje ruční slučování i riziko nechtěného přepsání práce.

Aktualizace se nejdřív ověřuje v pracovní větvi a testovacím prostředí, včetně důležitých scénářů, dat a projektových rozšíření. Do produkce patří ověřená verze s připraveným postupem obnovy. Na tento postup navazuje checklist pro nasazení Laravel aplikace do produkce.

Co mi při vývoji dalo nejvíc zabrat

Nejvíce promýšlení pro mě vyžadovala rozhodnutí, jejichž důsledky se projeví až při dalších změnách aplikace. Při vývoji jsem proto postupně přehodnotil, podle čeho posuzuji dobrý společný základ.

Aktualizace a respekt k projektovým úpravám

U aktualizací se nejvíc změnil můj pohled na celý návrh. Zpočátku jsem řešil hlavně to, jaké funkce má společný základ obsahovat. Postupně pro mě začalo být důležitější, jak se budou měnit a rozšiřovat. Nová verze balíčku sama o sobě nestačí: musím vědět, co udělá s úpravami, které mezitím přidal vývojář. Nejobtížnější bylo vymezit, co ještě udržuje společný základ a o čem už rozhoduje projekt. Návrh aktualizací tak ovlivnil i rozdělení jádra, doplňků a projektového kódu.

Kde končí core a začíná konkrétní funkce

U core platformy bylo náročné odolat přesouvání každého nového požadavku do jádra. Pomáhala mi jednoduchá otázka: potřebuje tuto funkci i web, který nemá blog ani obchod? Pokud ne, zpravidla patří do doplňku nebo konkrétního projektu.

API, se kterým se dobře pracuje

Velkou pozornost jsem věnoval také rozhraní pro vývojáře. Zatímco dříve zmíněné API předává data mezi aplikacemi, zde jde o dohodnutá místa pro rozšíření samotného systému. Vývojář musí rozpoznat, na co se může spolehnout při dalších aktualizacích. Tyto možnosti popisuje dokumentace a jejich zachování hlídají testy.

Při návrhu rozhraní jsem počítal také s AI agenty. Přimělo mě to zachytit pravidla, která by jinak mohla zůstat jen v hlavě autora. To, co mně připadá samozřejmé, nemusí být jasné ani agentovi, ani vývojáři, který projekt vidí poprvé. Proto dávám přednost praktickým příkladům celé změny před izolovanými ukázkami kódu.

Cena flexibility a hranice společného základu

Modularita má i svou cenu. Vědomě jsem přijal, že příprava společného základu bude náročnější než vytvoření jedné hotové aplikace. Oddělení částí, pravidla jejich spolupráce a dokumentace stojí čas, který není na první pohled vidět. Vývojář má mít prostor pro vlastní řešení, ale zároveň vědět, jak si jím nezkomplikovat příští aktualizaci. Tuto předvídatelnost považuji za důležitější než možnost měnit bez omezení cokoli kdekoli. Investice dává smysl hlavně u více dlouhodobě udržovaných projektů; pro malý jednorázový web může být takový základ zbytečně rozsáhlý.

Checklist: co by měl dobrý Laravel starter kit nabídnout

• Rozběhnutí webu podle srozumitelného postupu.

• Administrátorské účty s jasnými pravidly přístupu.

• Administraci s konvencemi a podporovanými možnostmi rozšíření.

• Obsah, SEO a integrace, které lze vybrat podle potřeb projektu.

• Oddělení společného kódu, vzhledu a projektových úprav.

• Předvídatelnou aktivaci a vypínání funkcí se zachováním dat.

• Testy doplněné kontrolou spolupráce funkcí a ověřením instalace i aktualizací.

• Dokumentaci pro tým i AI agenty, která odpovídá skutečnému stavu.

• Aktualizace, při kterých je jasné, co se mění a co patří projektu.

S odstupem bych tyto požadavky při novém začátku dřív ověřil na několika situacích od začátku do konce: založení projektu, přidání vlastní funkce a následné aktualizaci společného základu. Na těchto příkladech se rychle ukáže, zda rozdělení částí skutečně pomáhá. Víc času bych věnoval jejich hranicím a méně počtu připravených funkcí. Dnes je pro mě důležitější, aby se kit dobře rozšiřoval a udržoval, než aby hned obsahoval všechno.