Přestaňte znovu vytvářet každý WordPress web

Shrnutí

Většina agentur vytváří každý WordPress web od prázdného motivu, i když by sdílený základ ušetřil týdny v harmonogramu. Tento článek tvrdí, že theme.json, blokové vzory a dynamické bloky vám umožní standardizovat strukturální vrstvu při zachování osobitého designu každého klienta. Přímo se zabývá pěti námitkami, které týmům brání ve změně: „máme různé klienty“, „vlastní bloky jsou drahé“, „editor je matoucí“, „přijdeme o své hooky a filtry“ a „FSE není připraveno na produkci“. Každá námitka dostane praktický protiklad a konkrétní vzor, který můžete zavádět postupně. Výsledkem je opakovatelný proces tvorby, který stále ctí zakázkovou práci tam, kam patří. Varování: neslibujeme žádná tlačítka pro reset jedním kliknutím.

Kolik z webů vašich klientů sdílí alespoň jeden řádek kódu? Ne řádek s copyrightem – skutečný kód. Pokud je odpověď „skoro žádný“, už jste tu bolest zažili: stejná hero sekce postavená posedmé, stejný markup pro týmovou mřížku zkopírovaný z projektu do projektu, stejné úpravy preprocessingu procházené napříč půltuctem motivů. Slyšeli jste také obhajobu: „Každý klient má jiné potřeby.“ Pravda. Závěr, který si ale každý odvodí – že každý web potřebuje zakázkový základ – je nesprávný. Ekosystém WordPress nyní nabízí způsob, jak standardizovat strukturální prvky bez standardizace designu: theme.json pro designové tokeny, blokové vzory pro opakované rozložení a dynamické bloky pro hrstku funkcí, které vyžadují skutečnou serverovou logiku. Tento článek je o námitkách, které brání agenturám v tomto kroku, a o tom, co skutečně funguje, když se proti nim postavíte.

Námitka „ale každý klient je jiný“

Základní princip: standardizujte základ, ne povrch. Důvod, proč držet strukturu ve sdílené knihovně, je právě v tom, aby vizuální vrstva zůstala volná. Soubor theme.json není design – je to sada designových tokenů. Barvy, mezery a typografie jsou hodnoty, ne markup. To je klíčový posun: můžete sdílet markup, zatímco theme.json pro konkrétní web způsobí, že web vypadá úplně jinak pro jinou značku.

Vezměte si dva klienty: advokátní kancelář a prodejce outdoorového vybavení. Jejich designové jazyky jsou na hony vzdálené. Oba ale potřebují hero sekci, mřížku s referencemi a pás pro výzvu k akci. Místo přestavby markupu pro každého spravujte tři blokové vzory a nechte theme.json každého klienta definovat barvy, písma a mezery. Struktura zůstává identická; designové tokeny ji promění z jedné značky na druhou. Když prodejce příští jaro změní svou barevnou paletu, upravíte na jeho webu jeden soubor – ne markup v šesti šablonách.

V praxi to znamená, že váš tým vytváří vzory jako kód, registruje je ve sdíleném pluginu a nechá theme.json na každém webu klienta, aby se postaral o vzhled. Názvy tříd ve vzoru se stanou vaší architekturou; hodnoty se stanou proměnnými. Můžete jít dokonce dál a rozšířit theme.json o vlastní nastavení pro typy příspěvků nebo výstup pluginů, ale v určitém okamžiku spíše vytváříte konfigurační rozhraní než web – což je past, o které pojednává náš článek o rozšíření theme.json. Udržujte sdílenou vrstvu úspornou: měla by obsahovat jen to, co se napříč klienty opakuje. Ve chvíli, kdy si řeknete, že přidáváte nastavení „pro případ, že by to někdo jednou chtěl“, vytvořili jste abstrakci, která bude stát víc na údržbu, než ušetří.

Když nastavujete nového klienta, prvních třicet minut by mělo být: klonování sdíleného pluginu se vzory, vytvoření nového theme.json s paletou klienta a velikostí písma a registrace jeho loga a patičky. To není zakázkový build; je to konfigurační úkol. Zbývající klientská práce jde do obsahu, struktury a skutečně zakázkových funkcí. To je rozdíl mezi stavbou každého domu od nuly a sadou prefabrikovaných půdorysů, které můžete přetřít a vytapetovat. Přirovnání je volné, ale princip platí: čím více toho přesunete do hodnot theme.json, tím méně se musíte dotýkat markupu.

Jedním z nejjednodušších vítězství je podívat se, jak blokové vzory fungují. Vzor je jen kolekce bloků s předdefinovaným obsahem a stylem. Můžete uložit jakoukoli konfiguraci bloku jako vzor, a klient pak může vzor vložit, aniž by věděl, jak je postaven. To znamená, že se vzor stává „vstupním bodem“ pro netechnické uživatele. Když váš tým udržuje základní vzor v kódu, klient získá konzistentní knihovnu, aniž by se dotkl jediné PHP značky.

A teď upozornění, ke kterému se stále vracím: nepřehánějte centralizaci. theme.json s nastavením pro každou představitelnou nuanci je bažina údržby. Sdílené vzory by měly být názorové, ne všemocné. Pokud klient potřebuje radikálně jiné rozložení – řekněme domovskou stránku magazínu s velkou mřížkou pro doporučené články – nemusí se vejít do vaší standardní knihovny vzorů. To je v pořádku. Standardizace znamená, že vyhráváte u 80 % projektů, které jsou podobné, ne že nutíte každý web do stejné formy.

Námitka „vlastní bloky vyhodí rozpočet“

Tady je protiprincip, který zní nudně, ale šetří peníze: většina věcí, o kterých si myslíte, že potřebují vlastní blok, ho nepotřebuje. Základní bloky plus vzor pokryjí naprostou většinu rozložení. Vlastní blok je poslední možnost, ne první záměr.

Klasickým příkladem je týmová mřížka. Pokud jde o jednorázovou záležitost, použijte základní bloky „sloupce“ (columns) a „skupina“ (group) a nechte klienta, aby si prázdné místo pro portrét vyplnil ručně. Pokud tři klienti požadují stejnou mřížku se stejnou strukturou „sociální odkazy pod jménem“, máte kandidáta na blokový vzor. Když tento vzor začne shromažďovat nové možnosti – hover efekty, řazení, hvězdičky hodnocení – stane se z něj nezvladatelný mix všeho, a pak je čas napsat vlastní blok. Chyba, která bolí rozpočet, je skočit rovnou na vlastní blok při první žádosti.

Zákeřnější scénář: klient požádá o „karusel případových studií“. První instinkt je pomyslet si: „Potřebuji blok karuselu.“ Ale opravdu karusel potřebuje? Možná potřebuje horizontálně posouvatelnou skupinu příspěvků, což základní bloky zvládnou pomocí bloku „skupina“ a trochy CSS. Nebo možná potřebuje dynamický seznam posledních případových studií, což je dynamický blok, který dotazuje vlastní typ příspěvku (CPT). Otázka nezní „jakou funkci klient chce?“ ale „na jakých datech závisí?“ Pokud jsou data statická a klient je může upravovat, postačí vzor. Pokud data pocházejí z databázového dotazu, je dynamický blok oprávněný. Pokud se data musí aktualizovat v reálném čase z API, možná se díváte na integraci REST API – to už spadá do jiného druhu buildu.

Když už blok stavíte, block.json je váš přítel. Je to jediný zdroj pravdy pro atributy, skripty a styly, díky čemuž je blok přenosný mezi projekty. Také vám umožní čistě deklarovat závislosti a překlady, což je nezbytné, když distribuujete knihovnu napříč mnoha weby klientů. Pro obsah, který závisí na živých datech, se dynamický blok vykresluje na serveru, takže nemusíte na každé zobrazení stránky posílat JavaScriptový balíček. A pokud se váš blok vyvíjí, můžete ošetřit deprecations elegantně, aby se stávající obsah nerozbil – náš průvodce deprecation bloků ukazuje přesný postup.

Než cokoli postavíte, projděte si rozhodnutí pomocí této tabulky:

Přístup	Nejlepší pro	Vyhněte se, když
Základní blok	Jednorázový obsah, jednoduché stránky	Rozložení se opakuje napříč mnoha klienty a potřebuje bohaté možnosti
Blokový vzor	Opakovatelná rozložení bez logiky	Rozložení potřebuje podmínky, dynamická data nebo komplexní interakce
Vlastní blok	Opakované, datově řízené nebo vysoce specifické chování	Jediným důvodem je jednorázová sekce, kterou lze vyřešit pomocí třídy

Také byste měli myslet na pojmenování bloků od prvního dne. Název bloku je v podstatě smlouva s vaším obsahem. Pokud ho nazvete wagent/team-grid a později ho přejmenujete na wagent/team-carousel, rozbijete stávající obsah, pokud nezajistíte cestu pro deprecation. Vybírejte obecné, účelové názvy, které se nestanou falešnou reklamou s tím, jak se blok vyvíjí. Je to odrůda disciplíny pojmenovávání, kterou jsme se všichni naučili z předpon pluginů, a platí stejně tak pro názvy bloků.

Protikladný pohled, který zde nabízím, je to nejužitečnější, co mohu říct: vlastní blok, který postavíte, protože klient chtěl „jen jednu věc“, je téměř vždy chyba. Slušně odmítněte, nasaďte základní blok s třídou a ušetřete hodiny. Získáte si větší respekt klienta – a menší položku v rozpočtu na údržbu.

Námitka „klienti rozbijí editor“

Tato námitka je z poloviny pravdivá. Editor bloků sám o sobě není problém; problém je dát klientům příliš mnoho volnosti. theme.json může uzamknout, co je editovatelné: zakázat editor šablon, omezit povolené bloky a nastavit výchozí styly tak, aby špatně umístěný sloupec způsobil menší škody. Někteří klienti se stejně pokusí něco rozbít, ale můžete stránku jedním kliknutím vrátit na uložený vzor – něco, co klasický editor nenabídl.

Představte si scénář. Klient zavolá a řekne: „Posunul jsem sekci a teď celá stránka vypadá špatně.“ U klasického motivu byste se přihlásili, prozkoumali CSS a pravděpodobně strávili hodinu opravou rozložení. S nastavením bloků můžete otevřít stránku, vybrat oblast obsahu a obnovit ji na uložený vzor. Vzor je základní linie; změny klienta jsou překryvná vrstva. Když se překryvná vrstva zvrtne, odstraníte ji. To není jen lepší pracovní postup; je to zásadně shovívavější editor.

A teď nuance: většina klientů nechce moc editovat. Chtějí změnit text, vyměnit fotky a možná přesunout sekci. Blokový vzor vám to umožní bez odhalení celé struktury webu. V tomto smyslu není editor hračka; je to hledáček. Vaším úkolem je kalibrovat, co klienti vidí. To znamená, že můžete zakázat nastavení „Šablony“ (Templates), omezit vkládání bloků na vybraný seznam a dokonce předvyplnit prázdné vzory náhradní prací. Editor se stane formulářem pro zadávání obsahu spíše než plátnem pro webový design.

Na straně přístupnosti je správa fokusu a podpora klávesnice editoru bloků obecně lepší než pole šablon klasického editoru. Stále však musíte zajistit, aby vzory měly správnou hierarchii nadpisů a přístupná jména. Protože je vzor sdílený napříč klienty, tyto problémy opravíte jen jednou, což je další skrytá výhoda standardizace.

Skutečně obtížná část je interní. Váš tým se musí odnaučit zvyk „dělat to v PHP“, aby se naučil prototypovat s bloky. To je reálná cena, ale je to jednorázová cena na osobu. Není to důvod se tomuto přístupu vyhýbat; je to důvod začít s jednou knihovnou vzorů a jedním shovívavým klientem, než to rozjedete všude. Nenechte refrén „moji klienti neumí pracovat s bloky“ zakrýt skutečnost, že jste ještě nenastavili blokové prostředí tak, aby jim vyšlo vstříc.

Námitka „už máme hooky a filtry“

Princip zde zní: nevyhazujete hooky; přidáváte další vrstvu. Bloky jsou hranicí prezentace; hooky jsou stále způsobem, jak vkládáte logiku. Renderovací zpětné volání dynamického bloku běží v PHP, což znamená, že můžete volat stejné funkce a používat stejné filtry, kterým už důvěřujete.

Představte si plugin, který pomocí filtru umožní přidat do libovolného příspěvku pole „doporučený produkt“. S dynamickým blokem můžete zahrnout blok vykreslovaný na serveru, který tento filtr spustí a vypíše výstup do obalu bloku. Klient vloží blok; stávající logika PHP udělá těžkou práci. Nic se nevyhodí. Ještě konkrétnější příklad: vlastní blok, který vypisuje nedávné projektové příspěvky. V jeho renderovacím zpětném volání zavoláte get_posts(), pak projdete smyčkou a použijete the_title() a the_permalink() – stejné šablonové značky, které používáte léta.

Tady je také namístě být upřímný, co se nepřevádí. Některé chytré staré motivy používají template-parts se složitými podmínkami, které přijímají argumenty podle kontextu stránky. Znovu to vytvořit jako blok může být nepořádek. Ale nemusíte to všechno rekonstruovat najednou. Inkrementální cesta spočívá v tom, že ponecháte logiku PHP, zabalíte ji do dynamického bloku a přesunete markup do šablony bloku. Často zjistíte, že vaše stávající vzory filtrů zvládnou nový výstup. A pokud je logika pevně svázána s hierarchií šablon (např. „ve výsledcích vyhledávání to zobraz jinak“), můžete pro tyto konkrétní pohledy stále použít klasickou šablonu a pro běžné stránky použít bloky.

REST API také otevírá další dveře: můžete vytvářet bloky, které načítají data z jiných webů WordPress nebo služeb třetích stran. Dynamický blok může zavolat wp_remote_get() pro získání JSON a vykreslit ho na frontendu. To je užitečný vzor pro agenturní weby, kde klienti chtějí zobrazovat sociální feedy, seznamy produktů nebo interní data bez správy samostatné integrace. Kompromisem je ukládání do mezipaměti a řešení chyb – pokud je vzdálené API pomalé, je pomalá i vaše stránka. Bloky založené na API držte mimo kritický obsah nad záhybem stránky nebo použijte vykreslování na straně klienta se správným stavem načítání.

Akce a filtry stále běží při ukládání a vykreslování; architektura hooků nezmizí, když přijmete bloky, jen se přesune do nového kontextu. Pokud si potřebujete osvěžit, kde se akce a filtry setkávají s tímto novým blokovým světem, náš hluboký ponor do hooků je užitečným opakovacím materiálem.

Námitka „FSE není připraveno na produkci“

Férová námitka, ale zeptejte se, co „rizikový“ vlastně znamená. Full Site Editing prošel několika verzemi a theme.json se ustálil na stabilním schématu. Riziko není v tom, že se editor „náhle rozbije“ – riziko je, že váš vlastní kód může spoléhat na staré PHP šablony, které s blokovými šablonami koexistují neohrabaně. Také některé pluginy třetích stran stále předpokládají klasický editor nebo customizer. To je rozhodnutí o kompatibilitě, ne důvod zahodit celý model.

Užitečný způsob, jak o tom přemýšlet: jednoduché, opakovatelné weby s obsahem napsaným v blocích jsou nejméně rizikové. Vysoce rizikoví klienti jsou ti s hluboce upravenými klasickými motivy nebo proprietárními pluginy, které si samy vykreslují svůj front-end. To je oprávněný důvod zůstat u klasických motivů pro tento malý výsek. Chyba je předstírat, že „připravené pro produkci“ je jediný přepínač, který je buď zapnutý, nebo vypnutý.

Než navrhnete klientovi blokový motiv, projděte si rychlý kontrolní seznam:

• Má klient vysoce upravený motiv, který by vyžadoval migraci?
• Podporují nezbytné pluginy Site Editor a REST API?
• Umožňuje hostingové prostředí přístup k souborům, který blokový motiv očekává?
• Vyhradili jste si čas na design vzorů, ne jen na registraci bloků?
• Bude tým klienta tolerovat změny v editoru, nebo potřebuje uzamčenou šablonu?

Pokud je odpověď na cokoli ne, upravte rozsah nebo použijte hybridní přístup. To není kompromis; je to inženýrský úsudek. A pokud stavíte hybridní řešení, pamatujte na příběh o hácích a filtrech výše – starou logiku můžete stále zabalit do dynamických bloků, zatímco theme.json se postará o globální vzhled.

Verzování theme.json není jen teoretická záležitost. Viděl jsem, jak se knihovna vlastních bloků agentury rozbila, když klient aktualizoval WordPress a soubor style bloku registrovaný pomocí wp_register_style() pod změněným handle. Oprava byla snadná, ale panika byla skutečná. Jednoduchý testovací proces – spusťte aktualizaci na stagingové kopii webu, proklikejte klíčové stránky a pak pusťte do produkce – vyřeší většinu těchto překvapení.

Námitka, kterou jste si sami nepoložili

Tady je meta-námitka, která brání agenturám ve standardizaci: „Je to velká změna a na to není čas při práci pro klienty.“ To je pravda – tak to nedělejte při práci pro klienty. Vyberte si interní projekt nebo malého klienta a vytvořte jednu knihovnu vzorů. Použijte theme.json jako systém designových tokenů. Přidejte vlastní blok pouze tehdy, když je to opodstatněné. Zabalte staré hooky tam, kde pomáhají. Iterujte.

Tady je hrubý plán prvních 30 dní:

1. Proveďte audit svých posledních pěti klientských projektů a vyjmenujte deset nejčastěji se opakujících částí rozložení.
2. Proměňte těchto deset částí na blokové vzory s malou sadou CSS tříd.
3. Vytvořte sdílený plugin (nebo mu-plugin), který tyto vzory registruje. Pokud jste se ještě nezamysleli nad organizací pluginů, nejprve si projděte tento průvodce vytvářením robustních pluginů.
4. Vytvořte jeden theme.json, který odpovídá vašemu základnímu designu; přidejte hodnoty specifické pro klienta, když zakládáte projekty.
5. Vyberte jeden malý interní projekt nebo přátelského klienta a migrujte ho na tento stack.
6. Zdokumentujte jeden úspěšný příběh o klientovi, který si upravil svou domovskou stránku, aniž by vám volal.

Na konci tohoto experimentu nebudete mít na zdi pověšený odznak „block-first“. Budete mít tým, který dokáže rozjet nový klientský web ze sdíleného základu, aniž by se omlouval za harmonogram. Také budete v lepší pozici říci ne žádosti klienta o 42. vlastní blok – protože přesně víte, co základní bloky umí, nebo protože dokážete ukázat, proč by dynamický blok byl skutečně rychlejší.

Budete stále stavět některé zakázkové weby? Ano. Někteří klienti budou vždy potřebovat vlastní šablonu, zakázkovou stránku nebo proprietární integraci, kterou se nevyplatí nutit do sdíleného modelu. Cílem není eliminovat zakázkovou práci – je to udělat z ní výjimku spíše než standard.

Opakovatelnost pochází z nudných částí: solidní schéma theme.json, jasná knihovna vzorů a disciplína udržovat sdílenou vrstvu úspornou. To není ta lesklá verze, kterou slyšíte na webinářích. Je to ta, která poráží pondělní rána s prázdným motivem.