Biela obrazovka vo WordPresse: 5 jednoduchých opráv

odsek | WordPress

Ak vaša stránka WordPress zrazu zobrazí úplne prázdnu stránku. sans Správa znie, že nie ste „prekliaty“: len čelíte fatálnej chybe, ktorú WordPress nedokáže správne zobraziť.

Problém

„WSOD“ (biela obrazovka smrti) sa zobrazuje ako úplná absencia obsahu. Niekedy sa zobrazí ekvivalent na strane servera, napríklad chyba 500 alebo minimálna správa, ako napríklad:

HTTP ERROR 500

Alebo, ak hosting zobrazuje chyby PHP (v produkcii zriedkavé), niečo ako:

Fatal error: Uncaught Error: Call to undefined function ... in /home/.../wp-content/themes/.../functions.php:123

Kde a kedy sa objaví?

  • čelné : prázdna domovská stránka alebo iba určité stránky (často stránka so shortcode, widget, špecifická šablóna).
  • Administrátor (/wp-admin) : biela obrazovka pri prihlásení, neprístupný ovládací panel alebo biela obrazovka na konkrétnej stránke (Rozšírenia, Vzhľad, Editor…).
  • Cron / naplánované úlohy : stránka „funguje“, ale niektoré akcie (e-maily, importy) sa zastavia a v protokoloch nájdete chyby.
  • REST API / AJAX Elementor/Divi/Avada už nedokážu načítať editor, požiadavky XHR zlyhávajú alebo sa nenačíta náhľad.

Typické situácie, s ktorými sa stretávam najčastejšie:

  • Hneď po aktualizovať (WordPress 6.9.4, a zapojiť(téma, nástroj na tvorbu).
  • Po pridaní útržok v functions.php alebo prostredníctvom pluginu pre úryvky.
  • Po aktivácii „ťažký“ plugin (vyrovnávacia pamäť, zabezpečenie, nástroj na tvorbu, elektronický obchod).
  • Po zmene na strane servera (verzia PHP, modul OPcache, pamäťové limity).

Pre koho je to určené: Ak ste začiatočník, ale máte prístup k FTP/správcovi súborov (alebo aspoň k administračnému panelu), budete môcť správne diagnostikovať a znova spustiť stránku. Nakoniec budete vedieť nájsť presnú chybu, izolovať vinníka (plugin/téma/úryvok kódu) a vyhnúť sa falošným bielym obrazovkám spôsobeným vyrovnávacou pamäťou.

Rýchle zhrnutie

  • Nehádaj Povoľte ladenie a prečítajte si chybu (Riešenie 1).
  • izolovať : deaktivujte všetky pluginy a prepnite späť na predvolenú tému (riešenie 2).
  • Skontrolujte pamäť Mnoho WSOD pochádza z Povolená veľkosť pamäte je vyčerpaná (Riešenie 3).
  • úryvky chýbajúca bodkočiarka v functions.php dosť na vybielenie všetkého (roztok 4).
  • Cache Ak OPcache/CDN používa starú verziu, môžete stránku „opraviť“ bez toho, aby ste ju videli (riešenie 5).

Príznaky

WSOD nie je vždy „len prázdna stránka“. Tu sú konkrétne znaky, na ktoré si treba dať pozor (a čo naznačujú).

  • Úplne prázdna strana (vpredu), ale / Wp-admin funguje: často je problém v téme, šablóne, shortcode alebo poškodenej vyrovnávacej pamäti stránky.
  • / Wp-admin aj biela: častejšie ide o fatálnu chybu PHP (plugin, téma, úryvok) alebo o limit pamäte.
  • erreur 500 v prehliadači: často ide o fatálnu chybu PHP, konfiguráciu servera alebo modul (OPcache), ktorý poskytuje zastaraný kód.
  • Editor Elementor/Divi/Avada sa už nenačítava Chyby REST API/AJAX, problémy s pamäťou, konflikty pluginov (zabezpečenie/ukladanie do vyrovnávacej pamäte) alebo skryté chyby JS.
  • Stránka funguje lokálne ale nie v produkčnom prostredí: rozdiely vo verzii PHP, rozšíreniach PHP, limitoch pamäte, vyrovnávacej pamäti servera, oprávneniach k súborom.
  • Iba určité stránky : poškodený shortcode, príliš veľká požiadavka, nekonečná slučka alebo obrázok/zdroj, ktorý zahlcuje pamäť.

Rýchla diagnostika na strane prehliadača: otvorte konzolu (F12) a pozrite sa:

  • Konzola Chyby JavaScriptu (obzvlášť užitočné pre tvorcov).
  • sieť XHR dotazy na /wp-json/ (REST API) alebo admin-ajax.php v roku 500/403.

Prečo sa to deje?

Jednoduché vysvetlenie (pre začiatočníkov)

WordPress spúšťa PHP kód (témy + pluginy). Ak PHP narazí na fatálnu chybu, vykonávanie sa okamžite zastaví. V závislosti od konfigurácie vášho servera môže byť chyba skrytá (z bezpečnostných dôvodov) a môže sa zobraziť iba biela obrazovka.

WSOD je preto zriedkakedy „mystický“. Takmer vždy je:

  • un chyba kódu (plugin/téma/úryvok kódu),
  • un nedostatok zdrojov (pamäť/čas),
  • alebo medzipamäte ktorá vám zobrazuje poškodenú verziu, aj keď ste ju opravili.

Technické vysvetlenie (stredne pokročilý/profesionálny)

V zákulisí sa chyba často vyskytuje počas načítavania hookov WordPressu. háčik je bod rozšírenia: a akčná vykoná kód v danom čase, filtre upraví hodnotu (napr. obsah) pred jej použitím.

Príčiny (od najčastejších po najzriedkavejšie) spolu s tým, čo som pozoroval pri riešení problémov s WordPressom 6.9.4:

  • Plugin nie je kompatibilný s PHP 8.1+ (alebo chyba po aktualizácii).
  • Téma / Detská téma kód v functions.phpšablóna alebo prepísanie WooCommerce.
  • Úryvok skopírovaný zo starého tutoriálu (zastaraná funkcia, nesprávny hook alebo kód vykonaný príliš skoro).
  • Nedostatok pamäte PHP (tvorcovia + WooCommerce + bezpečnostné pluginy = klasická kombinácia).
  • Serverová vyrovnávacia pamäť (OPcache) / CDN ktorý ponúka zastaranú verziu.
  • Oprávnenie (menej časté pre skutočný WSOD, ale môže spôsobiť 500 chýb).

Aby sme vám pomohli zorientovať sa, tu je diagnostická tabuľka: „príznak → kontrola → riešenie“.

symptóm Príčina pravdepodobná overenie Riešenie
Biela obrazovka všade Fatálna chyba PHP Povoliť WP_DEBUG + čítanie debug.log Riešenie 1 + 2
erreur 500 Fatálne PHP / limit pamäte / vyrovnávacia pamäť servera Protokoly servera + debug.log Riešenie 1 + 3 + 5
Administrátor OK, biela predná strana Téma / krátky kód / vyrovnávacia pamäť stránky Dočasne zmeniť tému + vymazať vyrovnávaciu pamäť Riešenie 2 + 5
Elementor/Divi už neotvára editor Chyba REST/AJAX, pamäť Konzola + sieť (XHR 500/403) Riešenie 3 + „Ak to stále nefunguje“
WSOD po pridaní úryvku kódu Syntaktická chyba / príliš skoré zapojenie Posledná úprava súboru, protokoly Riešenie 4

Predpoklady pred začatím

Pred vykonaním akýchkoľvek zmien uložte. Ak potrebujete pracovať s nejakými súbormi, vytvorte si minimálne kópiu:

  • wp-config.php
  • súbor wp-content (alebo aspoň themes et plugins)

Odporúčané technické predpoklady (WordPress 6.9.4 k aprílu 2026):

  • PHP 8.1 + (minimálne odporúčané). Ak je pod touto hodnotou, výrazne zvyšujete riziko chýb a zraniteľností.
  • Prístup k FTP / SFTP alebo do správcu súborov poskytovateľa hostingu.
  • V ideálnom prípade réžia (testovacia stránka). Mnoho poskytovateľov hostingu to ponúka jedným kliknutím.

Užitočné (bezplatné) nástroje:

Zlaté pravidlo : nikdy neupravujte jadro (súbory WordPressu v wp-includes / wp-admin). Oprava sa vykonáva v doplnku, podradenej téme alebo v konfigurácii.

Riešenie 1: Správne povoľte ladenie (a nájdite presnú chybu)

Prázdna obrazovka bez viditeľných chýb vás núti hádať. Cieľom je získať použiteľnú správu v súbore protokolu.

Kde zasiahnuť: v súbore wp-config.php, v koreňovom adresári WordPressu (na rovnakej úrovni ako wp-content).

Pred vykonaním zmien uložte. Preklep v wp-config.php môže spôsobiť nedostupnosť stránky.

PRED (typická konfigurácia, ktorá všetko skrýva)

Mnohé stránky nemajú nič alebo majú neúplné ladenie:

<?php
// ... contenu existant ...

/* C'est tout : aucune trace d'erreur exploitable. */

PO (riešenie problémov zamerané na ladenie, bez zobrazenia návštevníkom)

Pridajte (alebo upravte) tieto konštanty. Umiestnite ich pred čiara /* That's all, stop editing! */ ak sa nachádza vo vašom súbore.

<?php
// ... contenu existant ...

/**
 * Debug WordPress (WordPress 6.9.4+ / PHP 8.1+)
 * Objectif : écrire les erreurs dans wp-content/debug.log sans les afficher aux visiteurs.
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

// Évite d'afficher des erreurs PHP directement dans le HTML.
@ini_set( 'display_errors', '0' );

Potom:

  1. Znovu načítajte prázdnu stránku (úvodnú alebo administrátorskú).
  2. otvorené wp-content/debug.log a hľadajte poslednú chybu.

Príklady chýb, ktoré sa môžu zobraziť:

PHP Fatal error:  Uncaught Error: Call to undefined function my_plugin_helper() in /wp-content/plugins/mon-plugin/mon-plugin.php:88
PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /wp-includes/class-wpdb.php on line ...

Prečo sa tým problém vyrieši: niekedy sa chyba „WSOD“ týmto krokom neopraví, ale problém sa obnoví. informácie čo umožňuje rýchlu opravu (konkrétny plugin, konkrétny súbor, konkrétny riadok). Bez neho strácate čas.

Keď skončíte: odovzdajte to WP_DEBUG à false na produkčnom mieste. Ak je súbor zle chránený, udržiavanie aktívneho protokolu môže odhaliť cesty k serveru a citlivé informácie.

Oficiálny zdroj: Ladenie WordPressu

Riešenie 2: Izolácia konfliktu medzi pluginom a témou (metóda pre začiatočníkov + metóda „bez administrátorského prístupu“)

Podľa mojej skúsenosti, WSOD veľmi často pramení z aktualizovaného pluginu (alebo builderu), ktorý spustí fatálnu chybu. Cieľ: vrátiť sa k minimálnej konfigurácii a potom ich jeden po druhom reaktivovať.

Metóda A (začiatočník): z administračného panela, ak máte prístup

  1. ísť Rozšírenia> Nainštalované rozšírenia.
  2. Vybrať všetko a potom deaktivácia.
  3. Otestujte stránku.
  4. Znova aktivovať jedno rozšírenie naraz kým sa WSOD nezreprodukuje.

Ďalej dočasne prepnite na štandardnú tému:

  • Vzhľad > Témy > aktivujte oficiálnu tému (často Twenty*).
  • Skúste to znova.

Ak používate Divi 5, Elementor alebo Avada: tieto témy/tvorcovia pridávajú veľa kódu. Konflikt s doplnkom pre vyrovnávaciu pamäť/zabezpečenie je bežný. Test „predvolená téma + deaktivované doplnky“ je najrýchlejší spôsob, ako zastaviť tento začarovaný kruh.

Metóda B (bez administrátorského prístupu): cez FTP/SFTP

Si /wp-admin je biela, použite FTP/SFTP.

Krok 1: Vypnite všetky pluginy naraz

Kde zasiahnuť: premenovať priečinok wp-content/plugins en plugins.offWordPress bude pluginy považovať za chýbajúce a deaktivuje ich.

# Exemple (le nom exact dépend de votre outil FTP)
wp-content/plugins  →  wp-content/plugins.off

Otestujte stránku. Ak sa problém vráti, potvrdili ste, že problém je v „plugine(och)“. Potom znova nainštalujte:

wp-content/plugins.off  →  wp-content/plugins

Potom, vo vnútri pluginsPremenujte priečinky jeden po druhom (napr. elementor → elementor.off) nájsť vinníka.

Krok 2: Vynútenie záložnej témy, ak téma zlyhá

Ak je stránka stále biela aj s vypnutými pluginmi, téma (alebo podradená téma) je podozrivá.

voľba proces : Premenujte priečinok aktívnej témy (alebo podradenej témy). WordPress prepne na inú dostupnú tému.

wp-content/themes/mon-theme-enfant  →  wp-content/themes/mon-theme-enfant.off

Prečo sa to opravuje: zastavíte načítavanie padajúceho kódu. Fatálna chyba v plugine/téme bráni WordPressu v ďalšom pokračovaní.

Ak chcete oficiálneho sprievodcu riešením problémov: Často kladené otázky týkajúce sa riešenia problémov (WordPress.org)

Riešenie 3: Oprava zlyhania z dôvodu nedostatku pamäte (PHP/WordPress)

Nedostatok pamäte je bežným problémom na stránkach používajúcich Elementor/Divi/Avada + WooCommerce + bezpečnostné/cachovacie pluginy. Príznakom je niekedy WSOD, niekedy chyba 500 a niekedy editor, ktorý sa odmieta načítať.

Typická správa v debug.log :

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate ...)

Krok 1: Zväčšenie pamäte na strane WordPressu (rýchlo)

Kde zasiahnuť: v wp-config.php, pred „zastaviť úpravy“.

PRED (bez explicitného obmedzenia)

<?php
// ...

PO (požiada WordPress o použitie viac pamäte)

<?php
// ...

/**
 * Augmente la mémoire pour WordPress.
 * Attention : si PHP a une limite plus basse, cela ne suffira pas.
 */
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // Utile pour l'admin et certaines tâches lourdes.

Prečo to funguje: WP_MEMORY_LIMIT informuje WordPress o cieľovej pamäti. Ak však váš server stanoví dolný limit, WordPress ho nebude môcť prekročiť.

Krok 2: Zvýšte alokáciu pamäte na strane PHP (často nevyhnutné)

V závislosti od vášho poskytovateľa hostingu sa to robí prostredníctvom:

  • panel ubytovania (odporúčané),
  • súbor php.ini ou .user.ini,
  • alebo konfiguráciu PHP-FPM (ak spravujete server).

Príklad (súbor) .user.ini (na mnohých zdieľaných hostingových službách):

memory_limit = 512M
max_execution_time = 120

Oficiálna referencia PHP (memory_limit): limit_pamäte v php.net

Čo testujem po zvýšení pamäte

  • Načítava sa prázdna stránka.
  • Otvorenie editora (Elementor/Divi/Avada).
  • Ak WooCommerce: pridanie do košíka, pokladňa a stránka produktu.

Ak sa stránka opäť sprístupní, ale zostane pomalá, je možné, že máte výrazne narastajúci dopyt (veľmi pomáha Query Monitor).

Riešenie 4: Oprava poškodeného úryvku (functions.php / plugin snippet) bez poškodenia všetkého

Najfrustrujúcejší scenár: pridáte 10 riadkov kódu „na vylepšenie WordPressu“, uložíte... a všetko sa zobrazí prázdne. Často som to videl na stránkach, kde je kód vložený do nesprávneho súboru alebo s chýbajúcou zátvorkou.

Podmienky:

  • útržok : malý kúsok kódu pridaný do témy (často functions.php) alebo prostredníctvom pluginu.
  • Syntaktická chyba PHP nedokáže prečítať súbor (chýba bodkočiarka, zložená zátvorka navyše...). Je to fatálne.

Prípad A: Kód bol pridaný do súboru functions.php (podradená téma)

Kde zasiahnuť: wp-content/themes/VOTRE-THEME-ENFANT/functions.php

Veľmi realistická chyba: zabudnutie bodkočiarky alebo uzavretie zloženej zátvorky.

PRED (prerušené: chýba bodkočiarka)

<?php
add_action( 'wp_enqueue_scripts', 'mon_site_styles' );

function mon_site_styles() {
	// Charge une feuille de style
	wp_enqueue_style( 'mon-style', get_stylesheet_directory_uri() . '/style.css' )
}

PO (opravené)

<?php
add_action( 'wp_enqueue_scripts', 'mon_site_styles' );

function mon_site_styles() {
	// Charge une feuille de style
	wp_enqueue_style( 'mon-style', get_stylesheet_directory_uri() . '/style.css' );
}

Prečo to rieši: PHP vyžaduje bodkočiarku na ukončenie inštrukcie. Bez nej sa spustí chyba pri analýze a WordPress sa už nebude môcť načítať.

Prípad B: kód použije hook príliš skoro (funkcia „ešte nie je načítaná“)

Ďalší prípad, na ktorý narážam: v starom tutoriáli voláte funkciu, ktorá v čase spustenia kódu ešte neexistuje.

PRED (poškodené: okamžité vykonanie príliš skoro)

<?php
// Mauvaise idée : ce code s'exécute dès le chargement du fichier.
ma_fonction_qui_depend_de_wordpress();

function ma_fonction_qui_depend_de_wordpress() {
	// Exemple : vous faites des appels à des APIs WordPress non disponibles à cet instant
	update_option( 'test', 'ok' );
}

PO (opravené: vykonanie prostredníctvom akcie)

<?php
/**
 * On utilise une action pour attendre que WordPress soit chargé.
 * Une "action" est un hook qui déclenche votre code à un moment précis.
 */
add_action( 'init', 'ma_fonction_qui_depend_de_wordpress' );

function ma_fonction_qui_depend_de_wordpress() {
	update_option( 'test', 'ok' );
}

Prečo to opravuje: init Spúšťa sa po načítaní WordPressu. Tým sa zabráni predčasným volaniam.

Prípad C: úryvok kódu prostredníctvom pluginu (WPCode, úryvky kódu atď.)

Ak používate doplnok pre úryvky kódu, výhodou je, že niekedy dokáže automaticky deaktivovať fatálny úryvok. Ak je však administrátorský panel neprístupný, deaktivujte doplnok pre úryvky kódu cez FTP (riešenie 2) a potom úryvok kódu opravte.

Referencia (háky): developer.wordpress.org/plugins/hooks

Riešenie 5: Odstráňte falošný WSOD spôsobený vyrovnávacou pamäťou (vyrovnávacia pamäť stránok, CDN, OPcache)

Toto nachytá mnohých začiatočníkov: opravíte chybu, ale stále vidíte bielu obrazovku. V skutočnosti vyrovnávacia pamäť zobrazuje poškodenú verziu.

Toto často vidím na:

  • stránky za Cloudflare (alebo inou CDN),
  • Poskytovatelia hostingu s agresívnym ukladaním servera do vyrovnávacej pamäte
  • stránky s povoleným a nesprávne zakázaným OPcache po nasadení.

Krok 1: Vymažte „viditeľné“ vyrovnávacie pamäte

  • Vymažte vyrovnávaciu pamäť pluginov (LiteSpeed ​​​​Cache, WP Rocket, W3TC…).
  • Vymažte vyrovnávaciu pamäť CDN (Cloudflare: „Vyčistiť všetko“ alebo cielené vyčistenie).
  • Otestujte v režime súkromného prehliadania + pridaním parametra: ?nocache=1

Krok 2: OPcache (na strane servera)

Ak máte prístup k serveru, najefektívnejším riešením je reštartovať PHP-FPM (v závislosti od vášho stacku). Príklad (Linux):

sudo systemctl reload php8.2-fpm

Ak používate zdieľaný hosting, tento príkaz nebudete mať k dispozícii. V takom prípade:

  • V paneli vyhľadajte možnosť „vymazať OPcache“.
  • alebo požiadajte podporu o vyprázdnenie OPcache (toto je často štandardná požiadavka).

Prečo to rieši: OPcache dokáže uložiť staršiu verziu PHP súboru do pamäte. Opravíte súbor... ale PHP stále vykoná starú verziu.

Oficiálna referencia OPcache: php.net OPcache

Kontroly po korekcii

Keď je stránka opäť v prevádzke, vždy vykonávam rovnaké „základné, ale účinné“ testy:

  1. predné : domovská stránka + 2-3 interné stránky + vyhľadávanie.
  2. admin Ovládací panel, Rozšírenia, Vzhľad, Editor (ak sa používa).
  3. stavitelia :
    • Elementor: otvorte editor + uložte zmenu.
    • Divi 5: otvorte Visual Builder + skontrolujte responzívny náhľad.
    • Avada: otvorte Fusion Builder + skontrolujte úpravy kontajnera.
  4. formuláre odoslať formulár (kontakt/newsletter).
  5. REST API : rýchly test návštevou /wp-json/ (mali by ste vidieť JSON, nie prázdnu stránku).

Potom:

  • Prečítaj si znova wp-content/debug.log Ak bude naďalej rásť, stále sa vyskytnú chyby (aj keď stránka „funguje“).
  • Vypnite ladenie, ak ste ho povolili v produkčnom prostredí (riešenie 1).

Ak to stále nefunguje

Keď 5 „začiatočníckych“ riešení nestačí, prejdem k systematickejšiemu postupu. Stále je dostupný, ale vyžaduje si trochu metódy.

1) Skontrolujte protokoly servera (často sú informatívnejšie ako súbor debug.log)

U mnohých poskytovateľov hostingu nájdete v ovládacom paneli „záznam chýb“ Apache/Nginx. Hľadajte:

  • PHP Fatal error
  • Premature end of script headers
  • Allowed memory size

2) Použite kontrolu stavu (režim riešenia problémov)

Ak máte administrátorský prístup, doplnok Health Check vám umožňuje zakázať doplnky/témy. len pre tebabez ovplyvnenia návštevníkov. Toto je veľmi praktické na aktívnej webovej stránke.

Doplnok: Kontrola stavu a riešenie problémov

3) Skontrolujte aktuálnu verziu PHP

Webová stránka si môže „myslieť“, že používa PHP 8.1, ale subdoména alebo cron úloha môže používať verziu 7.4 (videl som to). Skontrolujte:

  • Nástroje > Stav lokality
  • alebo panel poskytovateľa hostingu

4) Dočasne vypnite pluginy mu

Les mu-plugins (povinné pluginy) sa načítavajú automaticky z wp-content/mu-pluginsV zozname štandardných rozšírení nie sú viditeľné. Niektorí poskytovatelia hostingu používajú vyrovnávacie pamäte/bezpečnostné opatrenia.

Test: premenovať mu-plugins en mu-plugins.off cez FTP a potom otestovať.

5) Trvalé odkazy / pravidlá prepisovania („admin OK, strany 404/500“)

Toto nie je najčistejší WSOD, ale po migrácii alebo použití pluginu sa často skomplikuje. Prejdite na:

Nastavenia> Trvalé odkazy potom kliknite Registrovať (bez toho, aby sa čokoľvek zmenilo).

Oficiálny dokument: WP-CLI (pre profesionálov) (užitočné, ak máte prístup cez SSH, ale v tomto prípade voliteľné).

6) Skontrolujte povolenia súborov (zriedkavé, ale skutočné)

Príliš obmedzujúce povolenia môžu spôsobiť chyby servera. V zdieľaných prostrediach Linuxu často vidíme:

  • Súbory: 755
  • Súbory: 644

Ak má váš poskytovateľ hostingu iné odporúčania, riaďte sa nimi.

Časté úskalia a chyby

symptóm Príčina pravdepodobná Odporúčané riešenie
Povolili ste WP_DEBUG, ale debug.log sa nezobrazuje wp-content Nemožno zapisovať / Zlá konfigurácia / Chyba pred načítaním Skontrolujte povolenia a potom si pozrite protokoly servera
WSOD hneď po vložení kódu Chýbajúca bodkočiarka/zátvorka, kód vložený na nesprávne miesto Riešenie 4 (oprava úryvku), ideálne vo vlastnom plugine
Funguje to v režime súkromného prehliadania, ale nie „normálne“. Vyrovnávacia pamäť prehliadača / plugin / CDN Riešenie 5 (vymazanie) + dočasné vypnutie minifikácie
Elementor/Divi/Avada už neotvorí editor Pamäť, REST/AJAX blokované zabezpečením, konflikt pluginov Riešenie 3 + kontrola konzoly + vypnutie bezpečnostného doplnku
Riadil si sa starým návodom Nekompatibilný kód WordPress 6.9.4 / PHP 8.1 Nahradiť prístupom používajúcim aktuálne hooky, otestovať v stagingovom režime
Upravili ste nadradenú tému Strata úprav pri aktualizácii, riziko poškodenia Vrátiť sa k podradenej téme alebo vlastnému pluginu (pozri časť „Vyhnúť sa“)
WSOD sa vracia po „oprave“ OPcache/CDN stále poskytuje starú verziu Riešenie 5 (ak je to možné, vyčistiť + znova načítať PHP-FPM)

„Ľudské“ chyby, ktoré vidím najčastejšie:

  • Vložte úryvok do chybný súbor (napr. v šablóne namiesto functions.php).
  • Zabudnutie na zátvorka alebo bodkočiarka.
  • Zmiasť akčná et filtre (napr. použitie) add_action au Lieu de add_filter).
  • Otestujte priamo na výroba bez zálohy.
  • Zabúdanie na Vyprázdniť vyrovnávaciu pamäť po korekcii.

Variant / alternatíva

Metóda bez kódu (odporúčané, ak ste začiatočník)

Ak máte prístup k administrátorskému panelu, nainštalujte:

Toto je najbezpečnejší spôsob na online stránke: prešetríte bez toho, aby ste narušili zážitok návštevníka.

Pokročilejšia metóda (pre vývojárov): záloha mu-pluginu

Ak často riešite problémy (alebo spravujete viacero lokalít), môžete vytvoriť mu-plugin (Automaticky načítané), aby sa vynútilo minimálne protokolovanie a zabránilo sa zobrazovaniu chýb.

Kam vložiť kód: vytvoriť súbor wp-content/mu-plugins/00-rescue.php (ak priečinok neexistuje, vytvorte ho).

<?php
/**
 * Plugin Name: Rescue minimal
 * Description: Aide au dépannage : loggue des infos minimales si le site plante tôt.
 * Author: Votre Nom
 *
 * Attention : ceci ne remplace pas WP_DEBUG. C'est un filet de sécurité.
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

// Exemple : log simple pour confirmer que WordPress charge bien les mu-plugins.
error_log( '[Rescue] mu-plugin chargé' );

Riziká: Zapisovanie príliš veľkého množstva údajov do protokolov ich môže zaplniť. Udržujte tento súbor minimalistický a po vyriešení problémov ho odstráňte.

Oficiálna referencia na mu-pluginy: developer.wordpress.org/advanced-administration/plugins/mu-plugins

Vyhnite sa tomuto problému v budúcnosti

WSODy sa znova objavia, keď vykonáte rýchle opravy bez zmeny svojich návykov. Tu je to, čo v skutočnosti znižuje riziko.

1) Vykonajte úpravy vo vlastnom plugine, nie vo functions.php

Pre opakovane použiteľné úryvky kódu uprednostňujem malý, na mieru vytvorený plugin. Výhodou je, že ho môžete deaktivovať jedným kliknutím bez ovplyvnenia témy.

Kam vložiť kód: vytvoriť wp-content/plugins/mon-plugin-custom/mon-plugin-custom.php, potom ho aktivujte.

<?php
/**
 * Plugin Name: Mon plugin custom
 * Description: Snippets stables pour ce site (WordPress 6.9.4+ / PHP 8.1+).
 * Version: 1.0.0
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Exemple : on accroche un code sur une action.
 */
add_action( 'init', function () {
	// Code sûr : exécuté après le chargement de WordPress.
} );

2) Implementujte plán postupného vývoja

Testujte aktualizácie (WordPress, pluginy, témy, tvorcovia) v testovacom prostredí. Je to rozdiel medzi „5 minútami stresu“ a „2 hodinami paniky“.

3) Skontrolujte kompatibilitu s PHP 8.1+

Neudržiavaný plugin môže po aktualizácii verzie PHP zlyhať. Skontrolujte kompatibilitu na stránke pluginu (wordpress.org) a sledujte zoznam zmien.

4) Majte núdzový prístup

  • Funkčný prístup SFTP/FTP
  • Prístup k ovládaciemu panelu hostingu (logy, verzia PHP, vyrovnávacia pamäť)
  • Denná záloha (ideálne externá)

5) Vyrovnávacia pamäť: zdokumentujte svoju „cestu čistenia“

Na stránkach s CDN + vyrovnávacou pamäťou pluginov + vyrovnávacou pamäťou servera jasne uveďte, kde sa má vymazať. V opačnom prípade niečo „opravíte“ bez toho, aby ste opravu skutočne videli.

zdroje

často kladené otázky

Pochádza WSOD nevyhnutne z pluginu?

Nie. Téma, podradená téma, úryvok kódu, nedostatočná pamäť alebo vyrovnávacia pamäť servera môžu spôsobiť úplne rovnaký príznak. Najrýchlejšou metódou zostáva: debug.log + hromadné vypnutie (riešenie 1 + 2).

Prečo sa mi nezobrazujú žiadne chybové hlásenia?

Pretože väčšina serverov skrýva chyby PHP v produkčnom prostredí. Je to normálne (bezpečnosť). Povoliť protokolovanie cez WP_DEBUG_LOG načítať chybu bez jej zobrazenia návštevníkom.

Môžem to opraviť bez FTP?

Áno, ak máte administrátorský prístup: Kontrola stavu + vypnutie pluginov často stačí. Bez administrátorského prístupu je prístup k súborom (FTP/SFTP) najpriamejšia cesta.

Moja webová stránka je biela iba na jednej stránke, nie všade. Prečo?

Táto stránka pravdepodobne spúšťa špecifický kód: krátky kód, widget, šablónu, požiadavku náročnú na zdroje alebo obsah, ktorému dôjde pamäť. Povoľte ladenie a potom túto konkrétnu stránku znova načítajte, aby ste získali použiteľnú stopu.

Elementor zobrazuje v editore bielu obrazovku: je to rovnaké?

Často áno, ale problém môže byť na strane REST API/AJAX. Skontrolujte kartu Sieť: ak požiadavky na /wp-json/ ou admin-ajax.php vrátiť 500, vyhľadať chybu PHP (riešenie 1) alebo nedostatok pamäte (riešenie 3).

Po oprave stále vidím bielu obrazovku. Čo mám robiť?

Zamyslite sa nad ukladaním do vyrovnávacej pamäte: súkromné ​​prehliadanie, čistenie pluginov, čistenie CDN a ak je to možné, čistenie OPcache (riešenie 5). Toto je veľmi častá pasca.

Je nebezpečné povoliť WP_DEBUG na produkčnom webe?

Ak sa na obrazovke zobrazujú chyby, áno (môžete prezradiť citlivé informácie). Ak sa iba prihlásite (WP_DEBUG_DISPLAY à falseHlavným rizikom je generovanie veľkého súboru denníka. Po odstránení problémov ho vypnite.

Ktorý súbor musím upraviť: functions.php, wp-config.php alebo .htaccess?

Na diagnostiku: wp-config.php (Riešenie 1). Oprava úryvku: functions.php z podradenej témy, alebo ešte lepšie z vlastného pluginu (Riešenie 4 / „Vyhnite sa“). .htaccess je skôr na problémy s prepisovaním/permalinkmi, nie na väčšinu WSOD.

Stránka sa znova zobrazí, keď deaktivujem doplnok, ale potrebujem ho. Čo mám robiť?

Poznačte si presnú chybu (súbor/riadok) a aktualizujte doplnok, potom kontaktujte vývojára so stopou. Medzitým hľadajte alternatívu alebo vypnite iba funkciu, ktorá chybu spúšťa (často ukladanie do vyrovnávacej pamäte/minifikacia/zabezpečenie).

Súvisiace položky

Odoslať komentár

Vaša emailová adresa nebude zverejnená. Povinné položky sú označené *

Táto stránka používa Akismet na zníženie nežiaducich. Získajte viac informácií o tom, ako sa spracúvajú údaje vašej spätnej väzby.