Když WordPress padá při aktualizaci, problém nebývá v pluginu

Proč web po aktualizaci padá i tehdy, když „viník“ vypadá jasně

Na první pohled je snadné obvinit poslední aktualizovaný plugin. Jenže WordPress je vrstvený systém, kde se při aktualizaci potkává jádro, šablona, pluginy, PHP verze, databáze, cache i hostingová konfigurace. Pokud dojde k pádu, často nejde o jeden vadný balíček, ale o konflikt prostředí. Typický příklad: plugin je sám o sobě v pořádku, ale po aktualizaci začne používat funkci dostupnou až v PHP 8.1, zatímco server běží na 7.4.

Podle zkušeností z praxe bývá nejčastější příčina těchto selhání kombinace tří faktorů: zastaralé PHP, nekompatibilní šablona a slabě udržovaná cache vrstva. U webů s WooCommerce je navíc častý problém v návaznosti na databázové dotazy a cron úlohy, které se po aktualizaci začnou chovat jinak než předtím.

Je dobré si uvědomit, že aktualizace neznamená jen „nahrání nové verze“. Ve WordPressu se mění i struktura databáze, REST API výstupy, assety načítané v administraci a někdy i pořadí hooků. Když je web dlouhodobě provozován bez údržby, jedna aktualizace jen odhalí technický dluh, který už tam byl.

Nejčastější skutečné příčiny pádu: ne plugin, ale prostředí

Pokud web po aktualizaci spadne, první otázka by neměla znít „který plugin to udělal?“, ale „co se změnilo v celém stacku?“. V praxi sledujte hlavně tyto oblasti:

• Verze PHP – plugin může být kompatibilní s WordPressem, ale ne s konkrétní PHP verzí.
• Limit paměti – běžných 128 MB často nestačí pro rozsáhlejší weby, e-shopy nebo buildery.
• Konflikt se šablonou – staré přepisy šablonových souborů v child theme bývají častý zdroj fatálních chyb.
• Cache a minifikace – po update může zůstat v cache starý JS/CSS, což rozbije administraci i frontend.
• Mod_security nebo WAF – bezpečnostní vrstva na hostingu může blokovat AJAX nebo REST volání.
• Databázová nekonzistence – po aktualizaci plugin provede migraci, ale neúplně nebo s chybou.

U webů, kde se aktualizuje „naslepo“, se často stává, že chyba vypadá jako pád pluginu, ale ve skutečnosti jde o fatální chybu v šabloně nebo o konflikt s jiným pluginem, který pouze přišel na řadu až po aktualizaci. To je důvod, proč samotné vypnutí posledního pluginu často problém nevyřeší natrvalo.

Jak během 10 minut zjistit, kde je problém

První pravidlo: nehádejte. Otevřete logy. Pokud máte přístup k serveru, sledujte error_log a PHP-FPM log. Ve WordPressu si do wp-config.php dočasně zapněte ladění:

define(‚WP_DEBUG‘, true);
define(‚WP_DEBUG_LOG‘, true);
define(‚WP_DEBUG_DISPLAY‘, false);

Chybový záznam se pak ukládá do /wp-content/debug.log. Hledejte hlavně výrazy jako Fatal error, Uncaught Error, Allowed memory size exhausted nebo Call to undefined function. Tyto hlášky většinou přesně ukazují, zda je problém v PHP, v šabloně, nebo v konkrétní knihovně.

Praktický postup je tento:

• Ověřte, zda padá frontend, administrace, nebo obojí.
• Podívejte se do error logu v minutě, kdy jste aktualizaci provedli.
• Dočasně přepněte na standardní šablonu, například Twenty Twenty-Four.
• Deaktivujte cache pluginy a CDN minifikaci.
• Otestujte web v anonymním okně i bez cache prohlížeče.

Pokud se web po deaktivaci cache „spraví“, problém není v pluginu, ale v tom, že se po aktualizaci nepročistily staré assety. To je velmi časté hlavně u webů s kombinací LiteSpeed Cache, WP Rocket, Autoptimize nebo serverové cache na hostingu.

Co kontrolovat před aktualizací, aby web nespadl

Nejspolehlivější řešení je prevence. U menších webů stačí základní kontrolní seznam, u větších projektů už má smysl staging a automatizovaný monitoring. Minimální bezpečný postup před aktualizací by měl obsahovat:

• Plnou zálohu souborů i databáze.
• Kontrolu kompatibility pluginu se současnou verzí WordPressu a PHP.
• Aktualizaci na stagingu, ne přímo na produkci.
• Test základních scénářů: přihlášení, formulář, košík, checkout, vyhledávání.
• Kontrolu logů po update, ne jen vizuální kontrolu webu.

Staging prostředí je zásadní hlavně u webů s vyšší návštěvností nebo e-commerce. U WooCommerce doporučuji testovat minimálně 5 klíčových toků: přidání do košíku, změna dopravy, platba kartou, přihlášení zákazníka a odeslání e-mailu s potvrzením objednávky. Chyba se často neprojeví hned, ale až v checkoutu nebo při zpracování objednávky.

Velmi užitečné je sledovat také čas odezvy serveru před a po aktualizaci. Pokud se TTFB zvedne z 300 ms na 900 ms, nemusí jít o pád, ale o nově zavedený konflikt nebo neefektivní dotaz do databáze. To je signál, že aktualizace změnila výkonovou charakteristiku webu, i když frontend na první pohled funguje.

Jak opravit pád bez zbytečného vypínání všech pluginů

Častá chyba správců webu je vypnout vše najednou. Tím sice web někdy „ožije“, ale ztrácíte informaci o skutečné příčině. Lepší je postupovat systematicky. Začněte poslední změnou, pak se vraťte o krok zpět a ověřte, zda se chyba opakuje. Pokud máte přístup přes FTP nebo file manager, můžete problematický plugin přejmenovat a tím ho deaktivovat bez vstupu do administrace.

Když web hlásí fatální chybu po aktualizaci, pomáhá tento postup:

1. Zapněte debug log.
2. Identifikujte přesný soubor a řádek chyby.
3. Ověřte verzi PHP a doporučené minimum pluginu.
4. Zkontrolujte, zda nepadá přepis v child theme.
5. Vyprázdněte cache webu, serveru i CDN.
6. Pokud je to nutné, vraťte konkrétní plugin na předchozí verzi.

Rollback je často lepší než slepá oprava. Například u pluginů s velkými změnami v administraci nebo databázi bývá bezpečnější vrátit se o jednu verzi zpět a počkat na hotfix. Důležité je mít k dispozici archiv verzí nebo nástroj typu WP Rollback, případně staging kopii, odkud lze porovnat stav databáze a souborů.

U problému s pamětí pomůže navýšení limitu v wp-config.php nebo na hostingu, ale to je jen náplast. Pokud jeden update vyžaduje výrazně víc zdrojů než dřív, je potřeba hledat konkrétní plugin, který generuje příliš těžké dotazy, krátí timeouty nebo načítá nadbytečné skripty.

Jak nastavit aktualizační proces, který vydrží i další změny

Nejspolehlivější weby mají aktualizace řízené procesem, ne intuicí. To znamená jasný plán, kontrolní body a odpovědnost. V praxi se osvědčuje měsíční cyklus: nejdřív aktualizace na stagingu, potom kontrola logů, následně nasazení na produkci v době nižší návštěvnosti. U větších webů je vhodné mít i monitoring dostupnosti, například přes UptimeRobot, Better Uptime nebo vlastní alerting přes server.

Pro WordPress doporučuji sledovat tyto metriky:

• Počet fatálních chyb v logu po aktualizaci.
• Čas načtení hlavní stránky a administrace.
• Funkčnost kritických formulářů a checkoutu.
• Chyby v Search Console, pokud update ovlivnil indexaci nebo strukturovaná data.
• Core Web Vitals, hlavně LCP a INP po změnách skriptů.

Pokud web spravujete dlouhodobě, vyplatí se nastavit i pravidlo, že se nikdy neaktualizuje všechno najednou. Nejprve WordPress core, pak pluginy s největším dopadem, poté šablona. Díky tomu přesně víte, ve které vrstvě se problém objevil. U klientských projektů je to často rozdíl mezi 15minutovým zásahem a několikahodinovým řešením s výpadkem provozu.

Ve výsledku tedy platí jednoduché pravidlo: když WordPress padá při aktualizaci, problém nebývá v jednom pluginu, ale v tom, že web nemá dostatečně řízené prostředí, testování a logování. Jakmile začnete sledovat verze PHP, cache, šablonu, databázi a chybové logy jako jeden celek, většina „záhadných pádů“ se změní v dobře dohledatelný technický problém.