Transienty jsou jednoduchý způsob, jak do WordPressu odložit výsledek nějaké nákladnější operace: například odpověď z externího API, složitý databázový dotaz, vygenerovaný seznam článků, statistiky nebo mezivýsledek z pluginu.
Smysl je jediný: nezatěžovat zbytečně databázi, server nebo cizí API při každém načtení stránky. WordPress je ukládá buď do databáze, nebo. pokud je nasazená externí objektová cache, do rychlejší cache vrstvy mimo databázi.
Prakticky je to důležité i pro běžné správce webu, nejen pro vývojáře. Mnoho pluginů transienty používá potichu na pozadí. Když je používají špatně, může to znamenat bobtnání wp_options, zbytečný autoload, problémy po migraci webu, zastaralá data nebo zvláštní chování administrace i frontendu.
Transient by prostě neměla být„uložená hodnota“, ale dočasná cache. To je úplně nejdůležitější věta celého tématu. WordPress Transients API slouží k dočasnému ukládání dat s expirací, podobně jako Options API, ale s tím zásadním rozdílem, že transient může zmizet i dřív, než vyprší nastavený čas — zvlášť když web používá externí object cache. WordPress sám výslovně doporučuje brát transienty jako data, která mohou kdykoliv zmizet a musí jít znovu vytvořit.
To je zároveň hlavní „háček“, na který spousta lidí zapomíná: expirace není záruka minimální životnosti, ale jen horní limit. Tedy ne „data budou držet 12 hodin“, ale spíš „nejpozději za 12 hodin je považuj za neplatná, ale klidně mohou zmizet dřív“. To je přesně důvod, proč transienty nejsou vhodné pro nic, co je kritické, nenahraditelné nebo uživatelem vytvořené.
Co to umí
Transient umí uložit téměř libovolná serializovatelná data pod jménem klíče a přidat k nim dobu platnosti v sekundách. Existují klasické transienty pro konkrétní web a také site_transient varianty, které jsou v multisite sdílené napříč sítí. WordPress pro ně nabízí jednoduché funkce set_transient(), get_transient() a delete_transient(), plus síťové varianty.
Velká výhoda je, že při použití externí object cache se transienty mohou obsluhovat rychleji než běžné options. Právě proto se hodí na dočasné cacheování něčeho, co se dá znovu spočítat nebo stáhnout.
Co to neumí
Transient není jisté úložiště, není to databázový záznam, na který se můžete spolehnout jako na „uloženo a hotovo“. WordPress přímo upozorňuje, že transient vůbec nemusí být v databázi, protože může skončit v externí cache. A pokud neexistuje, get_transient() vrátí false. To není chyba, ale očekávané chování.
TIP: Jak ve WordPressu smazat velké množství příspěvků? Ideálně všechny?
Neumí tedy bezpečně držet věci jako licenční stav, dokončené kroky objednávky, uživatelské preference, rozpracované formuláře, bezpečnostní tokeny bez obnovovací logiky nebo cokoliv, co „musí existovat“. Na to patří jiné mechanismy. U transientu se má dát kdykoliv bez problému znovu dopočítat nebo znovu stáhnout hodnota.
Tohle je nejdůležitější část tipu. Hodně lidí si myslí, že když dají transientu expiraci 12 hodin, bude tam 12 hodin. Jenže WordPress říká opak: transient může zmizet kdykoli před vypršením. Externí object cache může obsah vyhodit, server se může restartovat, cache se může čistit, plugin může transient smazat. Expirace je maximální stáří, ne slib dostupnosti.
Další háček: transient bez expirace může škodit výkonu
set_transient() s expirací 0 znamená „bez expirace“. Jenže WordPress zároveň uvádí, že transienty bez expirace jsou autoloaded, zatímco transienty s expirací ne. To může být problém: autoloadované hodnoty se natahují při každém requestu, takže když plugin uloží velké nebo zbytečné transienty bez expirace, nafukuje tím paměť a zpomaluje web.
Transient bez expirace je často špatný nápad. Když už chcete „trvalejší“ hodnotu, možná jste ve skutečnosti neměli použít transient, ale normální option, nebo jiný způso.
Praktické doporučení: pokud plugin nebo vlastní kód ukládá transient bez expirace, je potřeba zpozornět. U běžného webu to může být nenápadný zdroj problémů s výkonem, hlavně když těch klíčů přibývá hodně nebo obsahují velké pole dat
Kde transienty fyzicky jsou a proč to mate
Bez externí object cache se transienty obvykle ukládají do wp_options pod názvy jako _transient_něco a _transient_timeout_něco. Když je ale aktivní externí object cache, transient se může ukládat úplně mimo databázi. Proto je častá chyba hledat transient v databázi a myslet si, že „tam není, takže se nepoužívá“. Nemusí tam být vůbec.
To je důležité i pro troubleshooting: s Redis/Memcached může být chování jinak rychlé, ale zároveň méně „viditelné“ při ruční kontrole databáze. A když někdo po migraci nebo po vyčištění cache říká, že „se něco samo rozbilo“, často jen zmizely transienty, které plugin neuměl korektně znovu vytvořit. To už je spíš závěr z dokumentovaného chování transientů a externí object cache.
Expired transients se nemusí uklidit hned
Další časté nepochopení: prošlý transient nemusí hned fyzicky zmizet z databáze. WordPress dokumentuje, že mazání expired transients nefunguje jako nějaký spolehlivý okamžitý garbage collector a že transients jsou mazány až při dalších requestech nebo cíleném čištění. Dokonce i reference k object cache upozorňuje, že transient může v DB zůstat, dokud se na něj nesáhne.
Navíc funkce delete_expired_transients() podle dokumentace nic neudělá, když je použitá externí object cache. To je další důvod, proč mechanická kontrola databáze někdy mate.
Nepanikařit jen proto, že v databázi vidíte hromadu _transient_… záznamů. Důležité je, zda jde o staré a opuštěné zbytky, nebo živé transienty používané pluginy. Na diagnostiku je lepší použít nástroje jako Query Monitor, případně WP-CLI, než databázi čistit naslepo. WordPress reference přímo uvádí Query Monitor a Debug Bar jako pomocníky pro analýzu object cache.
Pozor na „false“ a prázdné hodnoty
get_transient() vrací při neexistenci nebo expiraci false. Jenže false, 0, prázdný string nebo prázdné pole se při ledabylé kontrole snadno zamění. WordPress výslovně doporučuje testovat návrat pomocí === false, nikoliv volně. A také upozorňuje, že transienty nejsou vhodné pro ukládání prostého booleanu.
To je výborný materiál pro část „časté chyby“. Plugin může ukládat hodnotu 0, ale při načtení ji vyhodnotit stejně jako „cache chybí“, a pak zbytečně znovu volat API nebo přepočítávat dotaz.
Délka názvu klíče: tichý a záludný problém
WordPress uvádí, že název transientu by měl být 172 znaků nebo méně, protože se k němu přidávají prefixy _transient_ a _transient_timeout_. Delší názvy mohou tiše selhat. To je typická věc, která se neprojeví nahlas chybou, ale „jenom to občas nefunguje“.
Pluginy nebo vlastní řešení nemají do názvu klíče cpát celé URL, JSON parametry, dlouhé hashe plus prefixy plus identifikátory uživatele. Klíče mají být krátké, systematické a předvídatelné.
Site transients a multisite: další místo, kde se to plete
WordPress rozlišuje běžné transienty a site_transient varianty. Na multisite jsou site transienty síťové, tedy sdílené napříč weby v síti. V single-site prostředí to tak dramatické není, ale v multisite je rozdíl zásadní. WP-CLI to přímo rozlišuje přepínačem –network.
Transient uložený „site“ variantou může mít širší dopad, než správce čeká. Na multisite tedy nejde jen o technický detail, ale o rozsah platnosti cache.
Častý problém pluginů: nadměrné množství transientů
Mnoho pluginů transienty používá jako pohodlný odkladiště skoro všeho. Typicky SEO pluginy, page buildery, statistiky, integrace na API, importéry, e-shopy, feedy, licence, dashboard widgety. Samotný WordPress s tím problém nemá, problém je, když plugin transienty neumí uklízet, špatně volí expirace, vytváří příliš mnoho unikátních klíčů nebo ukládá moc velká data.
Když web zpomaluje a v wp_options je nepořádek, podezřelé nejsou jen autoload=yes options, ale i transienty a jejich timeouty. Zvlášť po odinstalaci pluginů mohou v databázi zůstat zbytky. Na mazání je ale lepší použít řízený nástroj než ruční SQL zásah naslepo.
Co dělat a nedělat
Co dělat: používat transienty jen na dočasnou cache; nastavovat rozumnou expiraci; počítat s tím, že obsah může zmizet kdykoliv; mít připravenou logiku „cache miss“; sledovat, zda pluginy zbytečně nenafukují wp_options; na čištění používat WP-CLI nebo specializované nástroje.
Co nedělat: neukládat do transientů nic kritického; nepoužívat je jako trvalé nastavení; nenechávat je bez expirace bez dobrého důvodu; nekontrolovat návrat volným if ( ! $value ); nevěřit, že co nevidíte v databázi, neexistuje; nemazat hromadně vše bez rozmyslu na produkčním webu.
Praktické nástroje a údržba
Na přehled a mazání transientů je užitečné WP-CLI. Dokumentace uvádí příkazy na smazání jednoho transientu, všech expired transientů i všech transientů obecně, včetně síťových variant. To je praktické hlavně při údržbě, migraci nebo po odinstalaci problematického pluginu.
Pro diagnostiku je užitečný Query Monitor nebo Debug Bar, které WordPress reference uvádí u object cache. To je lepší směr než hned sahat do phpMyAdmin a mazat všechno, co začíná _transient_.
Transients Manager je plugin, který vám pomůže transient (a nejenom ty) řešit. Přehledně zjistíte co zabírá zbytečně místo a můžete to vymazat. Pokud si pořídíte plnou verzi, tak to jde dělat i automaticky.
Další tipy týkající se Wordu
