WordPress: bílá obrazovka a chyba 500, jak je opravit

Prázdná stránka, chyba 500, hláška „There has been a critical error on this website“ a „Error establishing a database connection“ vypadají jako čtyři různé problémy, ale většinou jsou to dva: PHP spadlo při spouštění tvého kódu, nebo se PHP nedokázalo připojit k MySQL. Zjistíš to tak, že přestaneš hádat a přečteš si chybu. Zapni WP_DEBUG_LOG v souboru wp-config.php, jednou znovu načti rozbitou stránku a přečti si wp-content/debug.log a log chyb PHP. V devíti případech z deseti poslední řádek jmenuje soubor pluginu nebo šablony a důvod. Pokud ne, projdi postup z tohoto článku: přejmenuj složku s pluginy, přepni na výchozí šablonu, zvyš limit paměti, obnov pravidla přepisování, zkontroluj přihlašovací údaje k databázi a teprve potom opravuj databázi.

Všechno níže funguje jen se správcem souborů nebo přes SFTP, což je obvykle přesně ta situace, ve které jsi, když dashboard přestane fungovat.

Co která chyba doopravdy znamená#

Prohlížeč ukazuje velmi málo a to, co ukazuje, závisí na tom, jak PHP selhalo. Tato tabulka je mapa pro zbytek článku.

Klasická „bílá obrazovka smrti“ je z těchto chyb nejstarší. Před WordPressem 5.2 vedla každá fatální chyba v pluginu ke stránce, na které nebylo nic. Od té doby WordPress většinu fatálních chyb zachytí, zobrazí hlášku o kritické chybě a pošle správci e-mail. Skutečně prázdná stránka dnes obvykle znamená jednu ze tří věcí: chyba nastala dřív, než ji WordPress mohl zachytit (syntaktická chyba v wp-config.php nebo v souboru načítaném velmi brzy), fatální chyba nastala v samotném obslužném kódu chyb, nebo PHP došla paměť tak úplně, že nešlo nic vypsat.

Chyba 500 je jiná vrstva. Je to stavový kód webového serveru a říká jen „na serveru se něco pokazilo“. Padající PHP způsobí 500. Stejně tak rozbité pravidlo přepisování, problém s oprávněními, požadavek, který překročil časový limit, nebo proces PHP zabitý za příliš velkou spotřebu paměti. Proto je první úkol vždy stejný: najít řádek v logu, který patří k selhanému požadavku.

Ještě jeden rozdíl ušetří čas. Pokud selhávají jen administrační obrazovky a veřejná část funguje, nebo naopak, chyba je v kódu, který se načítá jen na jedné straně - v šabloně, na administrační stránce pluginu, ve widgetu. Pokud selhává všechno včetně statického souboru, například /readme.html, problém je pod WordPressem: server, verze PHP nebo souborový systém. Otevři /readme.html a zjisti, jestli se načte. Pokud ano, webový server je v pořádku a chyba je v PHP nebo ve WordPressu.

Nejdřív zapni logování: WP_DEBUG a debug.log#

Každá oprava v tomto článku jde rychleji, když si můžeš přečíst skutečnou chybu. WordPress má pro to tři konstanty, všechny se nastavují v wp-config.php nad řádkem s textem That's all, stop editing!.

define( 'WP_DEBUG', true );define( 'WP_DEBUG_LOG', true );define( 'WP_DEBUG_DISPLAY', false );@ini_set( 'display_errors', 0 );

Co která dělá:

• WP_DEBUG zapíná vlastní hlášení chyb WordPressu. Výchozí hodnota je false.
• WP_DEBUG_LOG zapisuje chyby do wp-content/debug.log. Místo true přijímá i cestu, pokud chceš mít log jinde.
• WP_DEBUG_DISPLAY určuje, jestli se chyby vypisují přímo do stránky. Výchozí hodnota je true, a proto může ladění na ostrém webu prozradit cesty k souborům každému návštěvníkovi. Nastav ji na false a čti raději log.

Řádek @ini_set( 'display_errors', 0 ) je pojistka navíc: ladicí režim WordPressu může jinak zapnout zobrazování chyb na hostingu, kde je vlastní nastavení PHP zapnuté.

Teď jednou načti rozbitou stránku a pak otevři wp-content/debug.log ve správci souborů. Řádky, které hledáš, vypadají takto:

[16-Oct-2026 09:12:41 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function  gutenberg_get_block_template() in /wp-content/plugins/old-slider/slider.php:88[16-Oct-2026 09:12:41 UTC] PHP Fatal error:  Allowed memory size of 134217728 bytes  exhausted (tried to allocate 20480 bytes) in /wp-includes/class-wp-hook.php on line 324

Čti cestu, ne hlášku. /wp-content/plugins/old-slider/ jmenuje plugin. /wp-content/themes/mytheme/functions.php jmenuje šablonu. Cesta uvnitř /wp-includes/ nebo /wp-admin/ spolu s hláškou o paměti obvykle znamená oběť, ne viníka: paměť spotřebovalo něco dřív v průběhu požadavku a jádro bylo jen kódem, který zrovna běžel, když paměť došla.

Pokud se debug.log vůbec neobjeví, obvyklé důvody jsou tyto: wp-config.php byl upraven pod řádkem „stop editing“ (konstanty musí přijít dřív, než se načte wp-settings.php), PHP uživatel nemůže zapisovat do wp-content, nebo chyba nastává ještě před startem WordPressu. V posledním případě je jediným záznamem log chyb PHP.

Čtení logu chyb PHP#

debug.log obsahuje jen to, co zachytil obslužný kód WordPressu. Vlastní log PHP je širší: zachytí chyby parseru, fatální chyby před startem WordPressu i varování z rozšíření. Kde leží, určuje direktiva error_log v php.ini; pokud není nastavená, chyby jdou do chybového logu webového serveru nebo na standardní chybový výstup procesu.

Zjisti to ze skriptu, protože odpověď se liší podle prostředí. Vlož tohle do souboru, jednou ho načti a potom ho smaž:

<?phpecho ini_get( 'error_log' ) ?: 'not set - using the server or stderr';echo "\n", ini_get( 'log_errors' ) ? 'log_errors on' : 'log_errors off';echo "\n", php_ini_loaded_file();

Pokud máš shell, sleduj log, zatímco znovu načítáš stránku:

$ tail -f /path/to/php_errors.log

Na serveru s panelem se výstup webového serveru a PHP objevuje v konzoli a každý log, do kterého PHP zapisuje, najdeš ve správci souborů. Rozdíl mezi chybou 500 s fatální chybou PHP v logu a chybou 500 bez čehokoli v logu PHP je sám o sobě užitečný. Fatální chyba v logu znamená opravit kód, který jmenuje. Prázdný log PHP a chyba 500 znamenají, že požadavek se k PHP nikdy nedostal, což ukazuje na konfiguraci webového serveru, .htaccess nebo zabitý proces. Obecný přístup k logům je v článku vysvětlení logů herních serverů. Je o herních serverech, ale návyk je stejný: číst od konce a párovat časové značky s vlastním požadavkem. Kompletní nastavení logování PHP najdeš v článku nastavení php.ini, na kterém záleží.

Vypnutí pluginů bez dashboardu#

Plugin je příčinou většiny bílých obrazovek a k jeho vypnutí nepotřebuješ administraci. WordPress načítá pluginy jen ze složky wp-content/plugins. Přejmenuj ji a žádný plugin se nenačte.

1. Otevři správce souborů nebo se připoj přes SFTP (podrobnosti o připojení jsou v článku SFTP a správce souborů).
2. Přejmenuj wp-content/plugins na wp-content/plugins.off.
3. Znovu načti web. Pokud chyba zmizela, způsobil ji plugin.
4. Přejmenuj složku zpět na plugins. WordPress ukáže všechny pluginy jako deaktivované, protože je nemohl najít.
5. Přejmenovávej složky uvnitř plugins jednu po druhé, nebo po polovinách, a najdi viníka. Zbytek aktivuj z dashboardu.

Přejmenování složky jediného pluginu funguje stejně a je rychlejší, když ho už jmenuje debug.log. Přidej -disabled na konec názvu složky, ne znak na začátek, abys viděl, co jsi změnil.

S WP-CLI, pokud máš shell, kde je nainstalované, jsou to dva příkazy a na soubory nesahají:

$ wp plugin list --status=active$ wp plugin deactivate --all$ wp plugin activate woocommerce

Pokud WP-CLI odmítne běžet, protože rozbitý plugin shodí WordPress už při načtení, přidej k libovolnému příkazu --skip-plugins: wp plugin deactivate --all --skip-plugins. Existuje i odpovídající --skip-themes. Neověřili jsme, že konzole každého tarifu poskytuje shell s WP-CLI, takže cestu přes správce souborů ber jako tu, která funguje vždy.

Dvě upozornění. Za prvé, mu-plugins je samostatná složka, říká se jí „must-use“, a načítá se bez ohledu na to, jestli je něco aktivované. Někteří hostitelé a cache pluginy tam ukládají soubor. Pokud přejmenování plugins nic nezmění, podívej se do wp-content/mu-plugins a přejmenuj i tuto složku. Za druhé, wp-content/advanced-cache.php a wp-content/object-cache.php jsou drop-iny, které po sobě zanechávají cache pluginy. Načítají se dřív než pluginy a ten, který odkazuje na smazaný plugin, shodí všechno. Pokud log jmenuje některý z těchto souborů, přejmenuj ho.

Přepnutí na výchozí šablonu#

Pokud pluginy problém nezpůsobují, na řadě je šablona. functions.php šablony se spouští při každém požadavku a jediná chyba v něm shodí celý web včetně wp-admin. Obvyklou příčinou je úprava provedená v editoru šablon, aktualizace šablony, která potřebuje novější verzi PHP, nebo podřízená šablona, jejíž nadřazená složka byla přejmenována.

Odsuň složku aktivní šablony stranou. V wp-content/themes přejmenuj rozbitou šablonu, například mytheme na mytheme-off. Když WordPress aktivní šablonu nenajde, vrátí se k libovolné výchozí šabloně, kterou najde, takže nějaká musí být přítomná: twentytwentyfive nebo jakákoli nedávná výchozí. Pokud žádná není, nahraj ji z wordpress.org rozbalením zipu do wp-content/themes; správce souborů umí archivy rozbalit přímo na místě.

Se shellem a WP-CLI:

$ wp theme list$ wp theme activate twentytwentyfive

Dosaď název výchozí šablony, která je opravdu nainstalovaná. Pokud po přepnutí web funguje, chyba byla v šabloně. Šablona, která selhává jen u jednoho typu stránky, například u jednotlivých příspěvků nebo v obchodě, ukazuje na soubor šablony pro tento typ; jeho cestu jmenuje debug.log.

Paměť PHP: memory_limit a WP_MEMORY_LIMIT#

Hláška Allowed memory size of 134217728 bytes exhausted je jediná chyba, která sama jmenuje svou opravu, i když ne vždy tu správnou. 134217728 bajtů je 128 MB, což je běžná výchozí hodnota memory_limit v PHP. Číslo „tried to allocate“ je poslední kapka, ne celkový součet. Spolupracují čtyři čísla:

WP_MEMORY_LIMIT je to, o co WordPress žádá PHP pro požadavek na veřejné části. Limit může zvýšit jen do výše, kterou server dovolí, takže jeho nastavení nad memory_limit může tiše selhat, pokud hosting zamkne memory_limit nastavením na úrovni poolu. WP_MAX_MEMORY_LIMIT je vyšší strop, který WordPress používá pro úlohy v administraci, například změnu velikosti obrázků a aktualizace.

define( 'WP_MEMORY_LIMIT', '256M' );define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Pokud to nic nezmění, zvyš samotný memory_limit v php.ini, nebo v souboru .user.ini v kořenové složce webu, pokud PHP běží pod FPM nebo CGI:

memory_limit = 256M

.user.ini se několik minut cachuje, takže počkej, než usoudíš, že nezabral. Podrobnější výklad, včetně toho, proč řádky php_value v .htaccess způsobují pod FPM chybu 500, je v článku nastavení php.ini, na kterém záleží.

Zvyšování limitu je jen náplast, ne oprava, pokud něco paměť požírá. Jediná stránka, která potřebuje víc než 256 MB, je téměř vždy plugin načítající obrovský výsledek dotazu, rozbitý import nebo smyčka. Pokud paměť dojde na hranici 128 MB nebo 256 MB bez ohledu na to, jak vysoko limit nastavíš, cesta k souboru na řádku logu ti řekne, kdo za to může.

Nad PHP je ještě jeden strop. V tarifu postaveném na kontejneru nemůže proces použít víc než RAM tarifu, ať říká memory_limit cokoli. memory_limit 1 GB v tarifu s 1 GB a s několika souběžnými požadavky skončí zabitím procesu, ne úhlednou hláškou PHP, a návštěvník dostane 500 nebo přerušené spojení bez jakéhokoli záznamu v logu PHP. Na RE:NODE se server, který dosáhne limitu paměti, zastaví jádrem a čistě se restartuje, místo aby swapoval, a grafy v konzoli ukazují paměť proti limitu, takže pilovitý průběh, který naráží na čáru a padá, je ten příznak. Článek kolik RAM potřebuje WordPress se věnuje dimenzování podle PHP workerů, což je správný způsob, jak se rozhodnout mezi zvýšením limitu a koupí většího tarifu.

Chyby 500, .htaccess a trvalé odkazy#

Chyba 500 bez chyby PHP za sebou je téměř vždy konfigurace webového serveru. Co udělat dál, závisí na tom, jaký webový server tvůj tarif používá, a to se u hostingů liší. U webových tarifů RE:NODE ho neuvádíme, takže oba případy jsou popsané zvlášť.

Pokud tvůj tarif používá Apache, nebo jakýkoli server, který čte .htaccess, je tento soubor obvyklý podezřelý. Špatná direktiva v něm, například řádek php_value pod PHP-FPM, vložené pravidlo pro nenačtený modul nebo zbloudilý znak, způsobí chybu 500 u každého požadavku. Vygeneruj ho znovu:

1. Přejmenuj .htaccess v kořenové složce webu na .htaccess.bak. Skryté soubory si ve správci souborů možná vyžádají zapnutí zobrazení skrytých souborů.
2. Znovu načti web. Úvodní stránka teď může fungovat, zatímco příspěvky vrací 404.
3. V dashboardu otevři Nastavení, potom Trvalé odkazy, a klikni na Uložit beze změny. WordPress zapíše čerstvý soubor.

Pokud se do dashboardu nedostaneš, vytvoř soubor ručně se standardním blokem WordPressu:

# BEGIN WordPress<IfModule mod_rewrite.c>RewriteEngine OnRewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]RewriteBase /RewriteRule ^index\.php$ - [L]RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule . /index.php [L]</IfModule># END WordPress

S WP-CLI soubor přepíše příkaz wp rewrite flush --hard, pokud je soubor zapisovatelný.

Pokud tvůj tarif používá nginx, žádný .htaccess se nečte a soubor se prostě ignoruje. Hezké trvalé odkazy fungují přes pravidlo try_files v konfiguraci serveru a chybějící pravidlo dá 404 na každé URL kromě úvodní stránky, ne chybu 500. Přejmenování .htaccess ti tam nepomůže.

Chyba 500, která se objeví jen u jedné akce, má i méně zjevné příčiny:

• Časové limity. Stránka, která trvá déle než max_execution_time (výchozí 30 sekund), skončí fatální chybou PHP. Delší čekání na reverzní proxy místo toho dá 502 nebo 504. Narážejí na to importy a zálohovací pluginy.
• Oprávnění. WordPress musí číst všechno a zapisovat do wp-content. V kontejneru, kde všechno vlastní jediný uživatel, to málokdy vadí, ale soubor nahraný jiným uživatelem přes SFTP může dorazit s režimem, který PHP nepřečte. Postup najdeš v článku SFTP nejde upravit soubory: permission denied.
• Verze PHP. Plugin napsaný pro PHP 7 může na 8.3 nebo novějším skončit fatální chybou. Pokud log ukazuje „Unsupported operand types“ nebo „Call to undefined function“ u něčeho starého, ověř nejdřív, které verze plugin podporuje.

Jádro WordPressu a hláška o kritické chybě#

„There has been a critical error on this website“ znamená, že WordPress zachytil fatální chybu a nahradil bílou obrazovku hláškou. Důležité je, že zároveň posílá e-mail.

Režim obnovy

WordPress pošle správci webu na adresu uvedenou v Nastavení, potom Obecné, zprávu s předmětem v duchu „Your Site is Experiencing a Technical Issue“. Jmenuje plugin nebo šablonu, která chybu způsobila, a obsahuje speciální přihlašovací odkaz. Po jeho otevření se dashboard otevře v režimu obnovy, kde je rozbitý plugin nebo šablona pozastavená jen pro tvou relaci. Pak ho můžeš řádně deaktivovat na obrazovce Pluginy a režim obnovy ukončit.

Tři praktické poznámky:

• Odkaz platí omezenou dobu, ve výchozím nastavení jeden den, a WordPress v tomto okně pošle nejvýš jeden e-mail na typ chyby, takže druhé načtení stránky druhý e-mail nevyvolá.
• E-mail jde na adresu správce. Pokud je to schránka, kterou už nepoužíváš, nebo tvůj web neumí odesílat poštu, nikdy ho neuvidíš.
• Web, který neumí doručovat poštu, není nic neobvyklého. Pokud e-mail nepřijde, nečekej na něj. Přejmenování pluginů a šablon výše udělá stejnou práci.

Chceš-li e-mail poslat jinam, nadefinuj RECOVERY_MODE_EMAIL v wp-config.php:

define( 'RECOVERY_MODE_EMAIL', 'you@example.com' );

Poškozené soubory jádra

Pokud log jmenuje soubor ve wp-includes nebo wp-admin, nebo hlásí chybějící třídu, kterou má definovat jádro, mohou být poškozené samotné soubory WordPressu - kvůli neúspěšné aktualizaci, přerušenému nahrávání nebo malwaru. Oprava spočívá v tom vrátit soubory jádra na místo, aniž by ses dotkl svého obsahu.

S WP-CLI:

$ wp core verify-checksums$ wp core download --force --skip-content

verify-checksums porovná tvé soubory jádra s oficiálními. --force přepíše jádro a --skip-content nechá wp-content na pokoji. Bez WP-CLI stáhni stejnou verzi z wordpress.org, rozbal ji a nahraj wp-admin a wp-includes přes stávající, plus volné soubory v kořenové složce kromě wp-config.php. Nikdy nenahrávej přes wp-content a nikdy ji nemaž; ta složka obsahuje tvé nahrané soubory, šablony a pluginy. Web, který neprojde kontrolou kontrolních součtů a má ve složkách jádra nevysvětlitelné soubory navíc, má jiný problém a pokračovat můžeš v článku co dělat, když je tvůj server hacknutý. Zabezpečení proti opakování je v článku zabezpečení WordPressu.

Error establishing a database connection#

Tuto chybu hlásí WordPress, ne PHP, a znamená jedno: volání pro připojení k MySQL selhalo. Má čtyři příčiny a pořadí jejich kontroly jde od nejrychlejší po nejpomalejší.

1. Špatné přihlašovací údaje v `wp-config.php`. Nejčastější po migraci, změně hesla nebo obnově ze zálohy.
2. Databázový server neběží nebo je nedostupný.
3. Databázi došla spojení nebo prostředky.
4. Poškozené tabulky.

Začni souborem. Připojení určují čtyři konstanty:

define( 'DB_NAME', 'wp_site' );define( 'DB_USER', 'wp_user' );define( 'DB_PASSWORD', 'the-generated-password' );define( 'DB_HOST', 'localhost' );

Porovnej každou se skutečnými hodnotami. U webového tarifu RE:NODE se databázový slot vytváří v panelu s vygenerovaným hostitelem, uživatelem, názvem databáze a heslem a řada WordPress zapíše wp-config.php pro vlastní databázi MySQL, takže soubor by už měl odpovídat. Pokud ne, zdrojem pravdy je sekce databází v panelu - kopíruj z ní, ne z paměti. Stačí mezera na konci nebo uvozovka ztracená při vkládání. DB_HOST není vždy localhost: databáze na jiném hostiteli potřebuje jeho název a nestandardní port se zapisuje jako host:3307.

Tlačítko „Open in phpMyAdmin“ v panelu je nejrychlejší test, jestli databáze žije. Přihlásí tě jednorázovým tokenem, který vyprší za 60 sekund. Pokud se phpMyAdmin otevře a ukáže tvé tabulky, server běží a chyba je v přihlašovacích údajích nebo v hodnotě hostitele v wp-config.php. Pokud se neotevře, problém je v databázovém slotu a dalším krokem je ticket z panelu.

Ze shellu s klientem MySQL můžeš stejné údaje otestovat přímo:

$ mysql -h HOST -u USER -p DATABASE -e "SELECT 1;"

Pokud to funguje a WordPress se přesto nepřipojí, něco ve vrstvě PHP se liší, například chybí rozšíření mysqli, což ukáže php -m. Článek mysqli vs PDO vysvětluje, jak PHP komunikuje s MySQL a na kterých ovladačích záleží. Pokud je selhání nárazové, tedy web funguje a pak pod zátěží selže, databáze nemá dost spojení a tento případ pokrývá článek limity spojení MySQL a pooling.

Jednu variantu je dobré odlišit. Pokud veřejná část ukazuje chybu databáze, ale /wp-admin ukazuje „One or more database tables are unavailable. The database may need to be repaired“, přihlašovací údaje jsou správné a tabulky jsou poškozené.

Oprava databáze#

WordPress má vestavěný nástroj pro opravu, který je ve výchozím stavu vypnutý, protože nevyžaduje přihlášení. Zapneš ho přidáním jednoho řádku do wp-config.php:

define( 'WP_ALLOW_REPAIR', true );

Potom na svém webu otevři /wp-admin/maint/repair.php. Nabídne dvě tlačítka: Repair Database a Repair and Optimise Database. Spusť první. Až skončí, řádek okamžitě odstraň.

Alternativy:

$ wp db check$ wp db repair

nebo v phpMyAdminu zaškrtni poškozené tabulky a v rozbalovací nabídce pod seznamem vyber Repair table. Pamatuj, že REPAIR TABLE funguje na tabulkách MyISAM; u InnoDB, které je výchozí v současném WordPressu, oprava dělá málo a skutečným lékem je obnova ze zálohy. Článek záloha a obnova pomocí mysqldump ukazuje, jak exportovat dřív, než na cokoli sáhneš, a zálohy a obnovy databází popisuje širší postup.

Před opravou jsou záchrannou sítí zálohy v panelu. Zálohy na RE:NODE lze vytvořit na vyžádání, ukládají se mimo stroj, který chrání, a obnovují se tlačítkem. Udělej jednu dřív, než přejmenuješ složky, upravíš wp-config.php nebo spustíš opravu, a vždy se budeš moci vrátit na začátek. Záloha, kterou nikdo neobnovil, je jen hypotéza, takže viz vyzkoušej obnovu dřív, než ji budeš potřebovat.

Bezpečné pořadí kroků#

Když web nefunguje a svádí tě to změnit pět věcí najednou, měň vždy jednu a mezi změnami testuj. Tohle je pořadí, které stojí nejméně a nejméně riskuje:

1. Otevři /readme.html a zjisti, jestli server vůbec odpovídá.
2. Zapni WP_DEBUG_LOG při vypnutém WP_DEBUG_DISPLAY, znovu načti stránku a přečti debug.log a log chyb PHP.
3. Udělej zálohu, pokud se chystáš měnit soubory nebo databázi.
4. Přejmenuj wp-content/plugins (a podle potřeby mu-plugins).
5. Přejmenuj složku aktivní šablony.
6. Zvyš WP_MEMORY_LIMIT, potom memory_limit.
7. Přejmenuj .htaccess a znovu ulož trvalé odkazy, pokud tvůj tarif používá Apache.
8. Zkontroluj DB_NAME, DB_USER, DB_PASSWORD a DB_HOST proti panelu.
9. Ověř nebo vyměň soubory jádra.
10. Databázi opravuj až jako poslední možnost.

Když něco zabere, vracej věci zpět po jedné. Obnov složku s pluginy a pak znovu povoluj pluginy po polovinách. Je lákavé nechat web běžet na výchozí šabloně a bez pluginů, a právě tak weby měsíce nenápadně přicházejí o funkce. Nakonec vypni ladění a smaž debug.log.

Prevence je levná. Aktualizuj nejdřív na testovací kopii (provozování testovacího serveru vedle ostrého popisuje tento návyk), před každou aktualizací pluginu měj čerstvou zálohu a neupravuj soubory šablon v editoru v dashboardu. Na starších instalacích editor nemá undo ani kontrolu syntaxe a jeden chybějící středník znamená bílou obrazovku.

FAQ#

Proč web ukazuje bílou obrazovku, ale žádnou chybu?

Protože zobrazování chyb je vypnuté, což je na ostrém webu správně. Chyba existuje, ale je v logu. Nastav WP_DEBUG a WP_DEBUG_LOG na true a WP_DEBUG_DISPLAY na false, jednou znovu načti stránku a přečti wp-content/debug.log. Pokud zůstane log prázdný, zkontroluj log chyb PHP, protože k selhání mohlo dojít ještě před startem WordPressu.

Je chyba 500 vina mého hostingu?

Někdy, ale zřídka. Většina chyb 500 ve WordPressu je plugin, šablona, špatné pravidlo v .htaccess nebo limit paměti. Nejdřív zkus přejmenování pluginů a log. Pokud je log PHP prázdný, selhává i /readme.html a nic z toho, co jsi změnil, nesedí, je ticket u hostingu rozumný. Tickety z panelu RE:NODE dostane všichni z podpory.

O kolik mám zvýšit limit paměti?

Nejdřív na 256M. Pokud chyba přetrvává i na 256M, zjisti, co paměť spotřebovává, místo dalšího zvyšování. Vyčerpaná paměť při každém limitu, který zkusíš, znamená smyčku nebo příliš velký dotaz, ne malý limit. Limit nad RAM tarifu jen přesune selhání z úhledné hlášky PHP na zabití procesu.

Nepřišel mi e-mail z režimu obnovy. Co teď?

Zkontroluj adresu správce v Nastavení, potom Obecné, a podívej se do spamu. Web, který neumí odesílat poštu, neodešle ani tento e-mail. Místo toho přejmenuj složku s pluginy; udělá stejnou práci. Nastav RECOVERY_MODE_EMAIL v wp-config.php, aby další e-mail šel tam, kam se díváš.

Smaže přejmenování složky s pluginy moje nastavení?

Ne. Nastavení pluginů žije v databázi a přejmenování jen zastaví načítání kódu WordPressem. Když složku přejmenuješ zpět, pluginy se objeví jako deaktivované a ty je znovu aktivuješ. Pár pluginů při deaktivaci některou volbu resetuje, takže před testem udělej zálohu.

Potřebuju WP-CLI na opravu čehokoli z tohoto?

Ne. Každý krok má cestu přes správce souborů nebo SFTP a tlačítko phpMyAdmin v panelu pokryje databázi. WP-CLI je rychlejší, když máš shell s ním, a --skip-plugins mu umožní fungovat i tehdy, když plugin shazuje WordPress už při načtení.