„There has been a critical error on this website“ znamená, že se WordPress zastavil kvůli fatální chybě PHP, kterou obvykle způsobí plugin, šablona nebo nekompatibilní verze PHP. Opravíte ji tak, že otevřete e-mail, který WordPress poslal na adresu správce, přes odkaz přejdete do režimu obnovení a vadný plugin deaktivujete. Pokud žádný e-mail nepřišel, zapněte WP_DEBUG_LOG ve wp-config.php, najděte cestu k souboru ve wp-content/debug.log a přejmenujte složku daného pluginu nebo šablony ve správci souborů nebo přes FTP.
Co znamená „There has been a critical error on this website“
Od WordPressu 5.2 jádro zachytává fatální chyby PHP: místo prázdné stránky návštěvníci uvidí krátké hlášení, server vrátí HTTP 500 a správce dostane e-mail s odkazem do režimu obnovení. Před verzí 5.2 vypadal stejný problém jako „bílá obrazovka smrti“. Bílou obrazovku můžete vidět i dnes, pokud je obsluha chyb vypnutá, paměť došla dřív, než se stihla spustit, nebo cache servíruje prázdnou stránku.
Pokud máte WordPress v češtině, hlášení i e-mail se zobrazí v českém překladu. Zde citujeme původní anglický text, který je stejný v každé instalaci.
| Co vidíte | Kde | Co to znamená |
|---|---|---|
| „There has been a critical error on this website.“ a odkaz na řešení problémů | Veřejná část webu | Fatální chyba PHP; e-mail správci je odeslaný nebo se právě odesílá |
| Stejný text a navíc „Please check your site admin email inbox for instructions.“ | Administrace nebo přihlašovací stránka | Režim obnovení je připravený; odkaz je ve schránce |
| „There has been a critical error on this website, putting it in recovery mode.“ | Administrace po použití odkazu | Vadný plugin nebo šablona jsou pro vaši relaci pozastavené |
| Prázdná bílá stránka | Kdekoli | Chyba nebyla zachycena, nebo cache vrací prázdnou odpověď |
| Jen 500 Internal Server Error | Kdekoli | Selhání ještě před načtením WordPressu: .htaccess, oprávnění, konfigurace PHP |
Krok 1. Využijte e-mail od WordPressu a režim obnovení
Když obsluha chyb zasáhne, WordPress pošle e-mail na adresu z Nastavení > Obecné (admin_email), v angličtině s předmětem „[Site name] Your Site is Experiencing a Technical Issue“. E-mail uvádí plugin nebo šablonu, ukazuje chybu se souborem a řádkem, verze WordPressu a PHP a obsahuje odkaz do režimu obnovení.
- Otevřete odkaz a přihlaste se jako správce.
- Na obrazovce pluginů je vadný plugin označený jako pozastavený. Deaktivujte ho, nebo ho aktualizujte, pokud už existuje opravená verze.
- Pokud je na vině šablona, aktivujte výchozí šablonu ve Vzhled > Šablony.
- Režim obnovení ukončete tlačítkem na horní liště administrace (anglicky „Exit Recovery Mode“) a web zkontrolujte v anonymním okně prohlížeče.
Režim obnovení platí jen pro vaši relaci: návštěvníci vidí chybu, dokud viníka nedeaktivujete. Odkaz platí přibližně jeden den a nový e-mail pošle WordPress nejvýše jednou denně (filtr recovery_mode_email_rate_limit má výchozí hodnotu DAY_IN_SECONDS).
Když e-mail nepřišel
- Podívejte se do spamu a ověřte, že e-mail správce v Nastavení je správný.
- Ověřte, že web vůbec umí odesílat poštu: pokud na serveru nefunguje mail(), e-mail neodejde.
- Nechte e-maily o obnovení posílat na jinou adresu:
define( 'RECOVERY_MODE_EMAIL', 'admin@example.com' ); - Nečekejte den na nový e-mail: přejděte ke kroku 2, který ho nepotřebuje.
Krok 2. Zapněte WP_DEBUG a přečtěte debug.log
Otevřete wp-config.php v kořenové složce webu přes správce souborů v panelu, FTP nebo SSH. Nahraďte define( 'WP_DEBUG', false ); následujícím blokem, a to nad řádkem „That’s all, stop editing!“.
define( 'WP_DEBUG', true ); // enable debug mode
define( 'WP_DEBUG_LOG', true ); // write errors to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // do not show errors to visitors
@ini_set( 'display_errors', 0 );Znovu načtěte nefunkční stránku a podívejte se na konec logu:
tail -n 30 wp-content/debug.log
# fatal errors only
grep "PHP Fatal" wp-content/debug.log | tail -n 5Typický záznam vypadá takto:
[21-Oct-2026 11:02:17 UTC] PHP Fatal error: Uncaught Error: Call to undefined function wc_get_product() in /home/user/web/example.com/public_html/wp-content/plugins/my-shop-addon/includes/class-cart.php:48Rozhoduje cesta: /wp-content/plugins/my-shop-addon/ ukazuje na plugin, /wp-content/themes/theme-name/ na šablonu a /wp-includes/ nebo /wp-admin/ na poškozené soubory jádra. Text za „PHP Fatal error“ vysvětluje příčinu; tabulka níže rozluští ty nejčastější.
Log ve wp-content je dostupný přes URL, proto po dokončení nastavte WP_DEBUG zpět na false a debug.log smažte. Další možnost: od WordPressu 5.1 přijímá WP_DEBUG_LOG cestu k souboru mimo veřejnou složku webu:
define( 'WP_DEBUG_LOG', '/home/user/logs/wp-errors.log' );Pokud debug.log zůstává prázdný, podívejte se do chybového logu domény. Na serverech s ovládacím panelem jde často o /var/log/apache2/domains/example.com.error.log nebo /var/log/nginx/domains/example.com.error.log, kde se chyby PHP-FPM objevují jako „PHP message: PHP Fatal error“.
Krok 3. Vypněte plugin nebo šablonu bez administrace
Správce souborů nebo FTP
Přejmenujte složku pluginu, například wp-content/plugins/my-shop-addon na my-shop-addon.off. WordPress soubor pluginu nenajde a při dalším načtení ho deaktivuje. Pokud log nic neprozradil, přejmenujte celou složku plugins na plugins.off, ověřte, že se web otevře, vraťte původní název a aktivujte pluginy jeden po druhém, dokud se chyba nevrátí. U šablony postupujte stejně se složkou wp-content/themes/theme-name: WordPress přepne na výchozí šablonu, pokud je nějaká nainstalovaná.
Přejmenování pluginů se netýká složky wp-content/mu-plugins (povinné pluginy, must-use) ani drop-inů advanced-cache.php a object-cache.php, které do wp-content přidávají cachovací pluginy. Zkontrolujte i je.
WP-CLI přes SSH
cd /home/user/web/example.com/public_html
wp plugin list --status=active --skip-plugins --skip-themes
wp plugin deactivate my-shop-addon --skip-plugins --skip-themes
# deactivate all plugins at once
wp plugin deactivate --all --skip-plugins --skip-themes
# switch to a default theme
wp theme activate twentytwentyfive --skip-plugins --skip-themes
# verify core and WordPress.org plugin files
wp core verify-checksums
wp plugin verify-checksums --allPřepínače --skip-plugins a --skip-themes zajistí, že WP-CLI nenačte stejný vadný kód a nespadne spolu s webem.
Databáze
Bez SSH a FTP, ale s phpMyAdminem vypnete všechny pluginy jediným dotazem. Nejdřív vyexportujte tabulku options a prefix wp_ nahraďte vlastním z wp-config.php:
UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';
Časté příčiny kritické chyby a jejich řešení
| Text v debug.log | Příčina | Řešení |
|---|---|---|
| Allowed memory size of … bytes exhausted | Skript překročil memory_limit | Zvyšte WP_MEMORY_LIMIT nebo memory_limit v PHP a zjistěte, co paměť spotřebovává |
| Call to undefined function | Chybí potřebný plugin, rozšíření PHP nebo byla funkce odstraněna | Nainstalujte závislost nebo rozšíření, plugin aktualizujte nebo vyměňte |
| Uncaught TypeError, ArgumentCountError | Starý kód na novější verzi PHP | Aktualizujte plugin nebo šablonu, případně se dočasně vraťte k předchozí verzi PHP |
| Cannot redeclare function | Stejná funkce deklarovaná dvakrát: duplicitní plugin nebo úryvek ve functions.php | Odstraňte duplikát nebo úryvek |
| syntax error, unexpected | Chyba v souboru, který jste právě upravili | Obnovte předchozí verzi souboru |
| Class … not found, Failed opening required | Aktualizace se přerušila a chybí soubory | Přeinstalujte plugin nebo jádro |
| Maximum execution time of … seconds exceeded | Skript běžel déle než max_execution_time | Najděte pomalou úlohu; náročné úlohy spouštějte přes WP-CLI nebo cron |
Pokud paměť dochází pravidelně, vyšší limit problém jen odkládá. Nastavte ho ve wp-config.php a potom hledejte plugin, který paměť spotřebovává; celý postup popisujeme v návodu na chybu Allowed memory size exhausted. Tytéž pluginy často vysvětlují i to, proč je váš WordPress pomalý.
define( 'WP_MEMORY_LIMIT', '256M' );
Kritická chyba po aktualizaci PHP nebo WordPressu
Většina kritických chyb se objeví hned po aktualizaci. WordPress 7.0, vydaný 20. května 2026, vyžaduje minimálně PHP 7.4 a doporučuje 8.4 nebo 8.5, přičemž některé starší pluginy a šablony na PHP 8.x selhávají kvůli přísnější kontrole typů.
- Pokud chyba začala po změně verze PHP, přepněte doménu zpět na předchozí verzi, aktualizujte pluginy a šablony a pak verzi změňte znovu.
- Pokud web rozbila aktualizace pluginu, nainstalujte předchozí verzi ze stránky pluginu na WordPress.org (Advanced View, starší verze) nebo ze zálohy.
- Pokud přerušená aktualizace poškodila soubory jádra, stáhněte je znovu, aniž byste sáhli na wp-content:
wp core download --skip-content --force. Příkaz stáhne nejnovější vydání; chcete-li zachovat svou verzi, přidejte--versions číslem, které vypíšewp core version.
Od WordPressu 6.6 jádro vrací zpět automatické aktualizace pluginů: po automatické aktualizaci web zkontroluje, a pokud zjistí fatální chybu, obnoví předchozí verzi. Ruční aktualizace z administrace se na to nevztahují, proto mějte čerstvé zálohy.
Bílá obrazovka bez hlášení: co zkontrolovat
Nejprve zjistěte stavový kód HTTP:
curl -sI https://example.com/ | head -n 1- 200 a prázdná stránka: obvykle cache uložila prázdnou odpověď. Vymažte cache pluginu, serveru i Cloudflare a otestujte s ?nocache=1.
- 500: fatální chyba, kterou obsluha nezachytila. Ověřte, že wp-config.php neobsahuje
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );, a přečtěte debug.log i log domény. - 403: server nemůže soubory číst. Standardní oprávnění jsou 644 pro soubory a 755 pro složky.
- 502 nebo 504: PHP-FPM spadl nebo neodpovídá; hledejte v logech serveru, ne ve WordPressu. Postup popisuje náš návod k chybě 504 Gateway Timeout.
Jak jsme to ověřili: 30.10.2026 jsme údaje v tomto návodu porovnali s oficiálními zdroji: referencí kódu na developer.wordpress.org (WP_Fatal_Error_Handler, WP_Recovery_Mode_Email_Service, filtr recovery_mode_email_rate_limit), příručkou „Debugging in WordPress“, referencí WP-CLI pro wp core download, stránkou kompatibility WordPressu 7.0 v Hosting Handbooku na make.wordpress.org, návrhem „Rollback Auto-Update“ pro WordPress 6.6 a Google Search Central (chyby HTTP a sítě). Řádky logů, cesty a příkazy jsou příklady s example.com a smyšleným pluginem (my-shop-addon).
Časté dotazy
Můžu hlášení o kritické chybě prostě skrýt?
Obsluhu chyb můžete vypnout konstantou WP_DISABLE_FATAL_ERROR_HANDLER, jenže pak návštěvníci uvidí bílou obrazovku a vy přijdete o e-mail s režimem obnovení. Chybu opravte, místo abyste ji schovávali.
Je bezpečné nechat WP_DEBUG zapnutý?
Ne. Log může prozradit cesty k souborům a útržky dat a wp-content/debug.log je dostupný přes URL. Po ladění ho vypněte a log smažte, nebo ho zapisujte mimo veřejnou složku webu.
Chyba se objevuje jen v administraci. Proč?
Obvykle za to může plugin, který se načítá jen ve wp-admin, nebo cache, která návštěvníkům dál servíruje uložené stránky. Diagnostika je stejná: debug.log a potom vypínání pluginů jeden po druhém.
Škodí kritická chyba SEO?
Nefunkční stránky vracejí HTTP 500. Google bere krátké výpadky 5xx jako dočasné, ale pokud web nefunguje několik dní, stránky mohou z indexu vypadnout, proto chybu opravte rychle.
Jak tomu příště předejít?
Před aktualizacemi zálohujte, aktualizujte pluginy po jednom, odstraňte opuštěné pluginy, před změnou verze PHP ověřte kompatibilitu a nastavte monitoring hostingu, abyste se o chybách dozvěděli dřív než návštěvníci.
Závěr
„There has been a critical error on this website“ signalizuje fatální chybu PHP, ne útok ani ztrátu dat. Využijte e-mail správci a režim obnovení; pokud e-mail nepřišel, zapněte WP_DEBUG_LOG, najděte v debug.log cestu k vadnému pluginu nebo šabloně a vypněte je přejmenováním složky nebo přes WP-CLI. Se správcem souborů, SSH a přístupem k logům je to práce na pět minut, a proto na platformě u hostingu pro WordPress záleží. Hostingové tarify RichHost zahrnují vlastní ovládací panel s asistentem AI, NVMe disky a SSL zdarma.
