Kam vložit kód ve WordPressu

Je to jak čůrání na odpočívadle u lesa. Jedete autem a nechcete zastavit na benzínce, stačí vám přece nějaká boční cesta, plácek, kam odstavíte káru a skočíte si odskočit. Až tam zjistíte, že je to velmi populární místo a kolem se to bělá kousky toaletního papíru. Jste tam. Na vyměšovadle. Potřebujete vypustit, ale přitom nešlápnout do starého hovna.

Omlouvám se ze expresivní úvod, ale přesně tak si připadám, když se dostanu na web, který je potřeba zachraňovat. Nejsem osvalenec v lesklé kombinéze, spíše uklízeč ve špinavém mundúru, který nemá platné pracovní povolení.

Rozmohl se nám totiž takový nešvar. Po webech se nám povalují PHP kódy, o které se nikdo nestará a postupem času nikdo neví, proč tam jsou a co dělají. Jsou to takové hromádky na odpočívadlech u zatáčky za lesem. A vy – my – správci je máme uklidit.

Nedávno jsem psal, kam správně vložit měřicí kód, aby v tom nebyl bordel. Dneska chci připomenout, kam se vkládá kód, kterým chcete upravit chování webu. A dejme si záležet, aby do toho pak nikdo nemusel šlapat.

Možná vás to překvapí, ale nikdo to v podstatě nemá moc rád.

Standard: Kód se vkládá pluginem

Vytvořte si vlastní plugin, pokud jsou vaše úpravy dostatečně univerzální. Pořád je dobré opakovat, že plugin je samostatně fungující a přenositelná komponenta, která má být použitelná opakovatelně na různých webech. V našem případě to bude minimálně jeden devel. (Proto v pluginu nemají být absolutní cesty k použitým zdrojům.)

Další vlastností nebo výhodou pluginu je, že ve většině případů neslouží k přímé úpravě designu, ale přidává nové funkce, ovlivňuje koncepci aplikace WordPress nebo výsledných stránek, například

• přidává filtrování nebo ovlivňuje chování filtrů v administraci,
• vytváří nový widget/prvek pro frontend,
• vytváří nové bloky nebo dříve shortcody.

Já vím, že to neplatí univerzálně, ale pamatujme na to, že plugin by měl obsahovat klíčové a funkční úpravy. Design je pak v šabloně.

Design: Do podřízené šablony

Podřízená šablona (child theme) je potomkem hlavní, rodičovské, šablony (parent theme). Je na ní závislá, ale dostatečně samostatná, i když využívá zdroje rodiče, prostě jako ve vztahu rodič-dítě. Nejprve se načítá rodičovská šablona, poté podřízená.

Proto nikdy neměníme rodičovskou šablonu, protože by se její aktualizací naše změny smazaly (a aktualizovat musíme, žejo). Naše úpravy patří do child theme. Vyplatí se to udělat i tehdy, pokud web child theme nemá. Já vím, že většina lidí nainstaluje snippet manager a do něj vloží části PHP, ale považuju to za špatný přístup.

Nastavení šablony se v databázi identifikuje na základě názvu šablony (slugu), který uvedete v souboru style.css. Pokud máte na webu aktivní šablonu, vytvořili jste její child a chcete na child přepnout, obvykle se nastavení rodiče použije i pro child (až na menší výjimky). Takže přechod na child theme nebývá tak dramatický. Získáte tím možnost udržovat rodiče v kondici.

Do podřízené šablony tedy umisťuji takový kód, který je závislý na rodičovské šabloně. Všechno, co může nebo má zmizet v případě změny šablony, tady má své místo. Naopak vše, co má po změně šablony zůstat, by mělo být v pluginu. Takže asi tušíte, že šablony, které vám vytvářejí sekce Projects, Portfolio, Team members a další, vás nutí zůstat, protože po jejich deaktivaci zůstanou tato data pro laiky nedostupná. (Jsou to custom post types a zůstávají v databázi, ale laik si s tím neporadí.)

Must-use pluginy

Trochu speciálním případem použití jsou automaticky spouštěné pluginy, must-use. Spouštějí se před hlavní query, ale až poté, co je načteno jádro WordPressu, takže máte možnost ovlivnit, co se načte z databáze.

Nelze je ani aktivovat, ani deaktivovat, spouštějí se vždy, pokud jsou přítomné v adresáři /wp-content/mu-plugins/. Každý plugin smí být pouze jeden PHP soubor. Hostingy je používají jako součást bezpečnostní ochrany nebo pro nízkoúrovňové nastavení některých parametrů.

Z hlediska WordPressu je jejich použití možné zejména v situacích, kdy

• chcete podmínečně omezit přístup k obsahu,
• potřebujete upravit hlavní query na články,
• nebo máte jiný speciální záměr.

Příklad použití v praxi

Aby to nebylo tak abstraktní, tak uvedu příklad. V informačním systému máme tikety, každý z nich je CPT „ticket“ a mmj. má autora a stav. Když chci filtrovat tikety na výpisu všech tiketů (=archiv CPT), tedy na adrese https://informacnisystem-wp-admin.cz/ticket/, podle stavu nebo autora, pak použiji query var:

• /ticket/?author=55
• /ticket/?status=open
• tedy třeba i takto: /ticket/?author=55&status=open

To zařídí právě MU plugin, který pomocí hooku pre_get_posts upraví hlavní WP_Query a přidá do meta_query dotazy na autora nebo pojmy taxonomie ticket-status.

Proč to nejde v běžném pluginu? Protože ten se spouští později, až poté, co je dotaz proveden a seznam článků už je v globální WP_Query připravený.

Vím, že tohle už je trochu složitější, ale chci tím poukázat na to, že každý kód má své místo. (A to jsem ještě stále trochu out, co se týče práce s bloky pro Gutenberg. Kloním se ale i tady k pluginu, protože na šabloně by závislé být neměly.)

Proč nepoužívat snippet managery

Pokud nemáte pistoli u hlavy… protože to málokdo umí správně nastavit. Většina uživatelů tam nakopíruje jakýkoliv snippet, který si najdou na netu. Už to samo o sobě je celkem nebezpečné, ale problémy se pak obvykle řetězí – na takovém snippetu je postaven nějaký klíčový proces. A jakmile dříve nebo později přestane fungovat, těžko se bude hledat, proč to přestalo fungovat a hlavně kdo za to může!

Takový kód je náchylný na chybu, nezohledňuje kontext (protože jiné úpravy jsou v pluginech na míru a/nebo v child šabloně) a nikdo za něj nenese odpovědnost. Později nikdo neví, proč to tam je a jestli to potřebujeme. Pak přijde nějaký řezník, který to začne kosit a je jenom na něm, jestli ustojí riziko, že rozbil web.

Zkrátka… navzdory hezkým reklamám, kterými se takové pluginy propagují, se držím staré dobré cesty. Udržovat kód na jednom místě, komentovat ho a starý kód odstraňovat. (Pro to se hodí používat git.)

Co ještě s kódem nedělat

Kreativita různých lidí bývá zajímavá a často souvisí s tím, že něco neumí nebo mají špatný návyk. Nikdo je nekontroluje (protože zadavatel tomu nerozumí a nenapadne ho poptat nějakého specialistu na supervizi projektu), takže mají volnou ruku, nějak to prostě spytlíkujem, kdo neskáče, není Čech, žejo!

Chápu to u majitelů, laiků. Ale programátor, profík, si například tohle dovolit nesmí (jo, zase trochu mentoruju, ale děsně mě to.. budí ze spaní):

• Umístit PHP skript do kořenu webu, protože ho potřebuje volat AJAXem a tam automaticky nemá cestu k pluginům; neumí najít a použít funkci wp_localize_script() a související. Skript je tedy exponovaný, není jasné, k čemu patří, kdo se o něj stará, jaké je jeho funkce. Přitom to měl být plugin, nebo jeho součást. Nechtělo se.
• Naskládat CSS kamkoliv to jde. Do customizéru šablony, do dalších políček v šabloně, inline do kódu šablony, do snippet manageru, prostě kamkoliv. Následně přetěžuje definice z původní šablony, používá !important a celé načítání a zpracování tím přivádí do otáček. Speciálové z testovacích webových jednotek používají konkrétní id článků (#article-2465 nebo konkrétní kontejnery Elementoru) a podle toho stylují stránky na míru. Huš, odstup satanáši!
• Vkládat kód do vizuálního editoru, protože tam je taky políčko Vlastní HTML. Prosím, poučme laiky, že tam žádný kód nemá být, připravme jim aspoň shortcode. (Ano, zažil jsem web, kde byl vložen měřicí kód analytiky do patičky vytvořené v Elementoru, předtím ho vkládali ručně do každého článku.)
• Pokud se vám cachuje nějaký JavaScript, který by neměl, pak se podívejte (=vypněte cachování), jestli náhodou není inline. To může být někdy záměr, ale někdy neznalost nebo lenost kodéra. Pokud je CSS/JS ve vlastním souboru, lze s ním transparentně pracovat – např. určovat prioritu zpracování nebo ne/cachování. Taky proto má nejen Elementor možnost vložit CSS buď do kódu inline, nebo do extra souboru. Dává tím možnosti upřednostnit výkon, nebo speciální konfiguraci.

Know-how pro správce

Byl jsem přesvědčený, že vydat knihu pro správce WordPressu je dobrý nápad. Pak se objevil plán na přepracování celé administrace. Zatím se v tom sice aktivně nepokračuje, ale to se těžko píše kniha, když víte, že se vám změní zadání.

A dneska si myslím, že kniha není ideální formát. Možná pracovní sešit nebo e-book.. ale spíše komunitní portál s aktualizovaným know-how pro správce a tvůrce.

Čtete vlastně e-booky, v jakém formátu? Jak by měl vypadat, aby vám sloužil jako pracovní průvodce? Chtěl byste vzdělávací portál? Napište mi na sociální síti nebo mailem.