Vlastní téma postavte na obsahovém modelu a designových tokenech, používejte malé znovupoužitelné komponenty a podporovaná WordPress API. Trvalou obchodní logiku umístěte do pluginu. Editor a front end musí používat stejná pravidla a každé vydání musí projít vizuálními, funkčními, výkonnostními a přístupnostními testy. Před nasazením do produkce ověřte také stránku 404, prázdný archiv, dlouhé texty a stav bez obrázku. Nasazujte pouze reprodukovatelný verzovaný artefakt.
Vlastní šablona WordPressu má přenést designový systém a obsahový model do spolehlivých šablon. Nemá se stát místem pro veškerou obchodní logiku webu. Když šablona registruje integrační endpointy, ukládá kritická data a obsahuje desítky jednorázových variant, její výměna ohrozí funkce i obsah. Udržitelný návrh proto odděluje prezentaci, editor a trvalé chování.
Šablona na míru dává smysl u specifické značky, komponent, redakčních pravidel nebo výkonnostních požadavků, které hotové řešení pokrývá jen množstvím přepisů. Tento návod popisuje architekturu od šablon a tokenů přes bloky až po testování a vydání. Nejde o výběr hotové šablony ani o návod na drobnou úpravu cizího balíčku.
Začněte obsahem a maticí šablon
Vypište typy obsahu, archivy, taxonomie, chybové stavy a komponenty, které se na nich zobrazují. Ke každé šabloně přiřaďte povinná a volitelná data. Nejprve otestujte extrémy: dlouhý nadpis, chybějící obrázek, prázdný archiv a mnoho položek. Pixelový návrh bez datových stavů není úplná specifikace.
Rozhodněte mezi blokovou, klasickou nebo hybridní architekturou podle redakčních potřeb a stávajícího ekosystému. Nevybírejte model jen podle novosti. Důležité je, kdo může měnit globální šablonu, co se verzuje v kódu a co redaktor spravuje jako obsah. Hranici zdokumentujte před implementací.
Převeďte design na tokeny a komponenty
Barvy, typografii, rozestupy, šířky a zaoblení definujte jako pojmenované tokeny podle významu. Komponenta nemá používat nahodilou hodnotu jen proto, že se hodí na jedné stránce. Tokeny umožní změnit vizuální identitu bez hledání stovek deklarací a pomohou sladit editor s veřejným výstupem.
Komponentu navrhněte s jasným API: varianta, obsah, stav a povolené vnoření. Navigace, karta, tlačítko či seznam referencí mají zvládnout prázdný, dlouhý i chybový stav. Nevytvářejte novou komponentu pro každý mírně odlišný screenshot; nejprve ověřte, zda jde o skutečnou významovou variantu.
- Pojmenované designové tokeny
- Komponenta s omezenými variantami
- Stavy pro chybějící a dlouhý obsah
- Stejná pravidla v editoru i na webu
Oddělte prezentaci od trvalé funkcionality
Šablona vzhledu registruje šablony, styly a prezentační integrace. Vlastní typ obsahu, integrační proces nebo obchodní pravidlo, které musí přežít změnu designu, patří do samostatného pluginu. Jinak přepnutí šablony vzhledu odstraní data, cron úlohy nebo endpointy a znemožní kontrolovaný redesign.
Využívejte hooky, template hierarchy a veřejné API místo kopírování interních souborů jádra či pluginů. Výstup escapujte podle kontextu a překlady vkládejte přes správnou textovou doménu. Dotazy držte mimo opakované smyčky a cache používejte s jasnou invalidací při změně obsahu.
Optimalizujte assety a přístupnost od začátku
CSS a JavaScript načítejte pouze tam, kde je komponenta potřebuje. Kritickou funkci nezávislou na skriptu zachovejte použitelnou nebo poskytněte srozumitelný fallback. Velikosti obrázků vycházejí ze skutečného layoutu a pořadí ve zdroji z logické struktury, nikoli jen z vizuálního přesouvání pomocí CSS.
Používejte sémantické prvky, viditelný fokus, ovládání klávesnicí a dostatečný kontrast tokenů. Komponentu otestujte se zoomem, dlouhým překladem, čtečkou obrazovky a preferencí omezeného pohybu. Přístupnost je vlastností kontraktu komponenty, takže oprava jednoho základu pomůže všem šablonám.
Zaveďte verzování, náhledy a regresní testy
Šablonu vzhledu udržujte ve verzovacím systému a nasazujte sestavený artefakt, nikoli ručně upravované produkční soubory. Změny databázové konfigurace nebo bloků mají vlastní migraci. Náhledové stránky zobrazí všechny komponenty a varianty nad kontrolovanými daty, takže se vizuální odchylka odhalí ještě před živým webem.
Testovací seznam pokrývá domovskou stránku, detail, archiv, vyhledávání, stránku 404, formulář, navigaci a kritické obrazovky pluginů. Sledujte také výkon a chyby v konzoli. Po nasazení ověřte cache a analytické události a připravte návrat k předchozímu artefaktu. Dokumentace vysvětlí redaktorovi povolené stavební prvky.
Časté dotazy
Patří vlastní typy obsahu do WordPress šablony?
Pokud mají přežít změnu designu, obvykle patří do pluginu. Téma pak poskytuje jejich šablony. Data a administrace tak zůstanou dostupné i při kontrolovaném přepnutí vzhledu.
Je bloková šablona vždy lepší než klasická?
Ne. Volba závisí na redakčních oprávněních, stávajícím obsahu, komponentách a týmu. Oba přístupy mohou být udržitelné, pokud mají jasnou hranici mezi konfigurací a kódem.
Jak aktualizovat vlastní šablonu na produkci?
Vydejte verzovaný a otestovaný artefakt opakovatelným procesem, připravte zálohu a návrat a po nasazení projděte kritické stránky. Ruční úpravy souborů v produkci nepoužívejte jako zdroj pravdy.
Zdroje a další čtení
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
