WordPress baltas ekranas: perskaitykite klaidą prieš ką nors keisdami

„Kritinė klaida“ ar baltas ekranas: tas pats gedimas

Tuščias puslapis beveik visada reiškia lemtingą PHP klaidą (fatal error): svetainės failas paprašė kažko neįmanomo, ir vykdymas sustojo dar nieko neparodęs. Nuo 5.2 versijos WordPress tokias klaidas perima: vietoj tuščio puslapio rodo „Tinklalapyje įvyko kritinė klaida.“ ir siunčia laišką svetainės administratoriaus adresu.

Puslapis lieka visiškai baltas keliais atvejais: senesnė WordPress versija, klaida, įvykusi prieš įsikeliant šiam apsaugos mechanizmui, konstanta WP_DISABLE_FATAL_ERROR_HANDLER, nustatyta į true, arba podėlio (cache) įskiepis, pateikiantis tuščią puslapį, kurį išsaugojo gedimo metu. Toliau aprašytas būdas tinka visais šiais atvejais.

Trys veiksmai gali palaukti, kol perskaitysite klaidą: WordPress įdiegimas iš naujo, įskiepių trynimas, senos atsarginės kopijos atkūrimas. Kiekvienas gali ištrinti nuostatas ar naujausius duomenis, o klaidos pranešimas paprastai tiksliai nurodo, kurį komponentą išjungti, nieko neprarandant.

Trumpiausias kelias: atstatymo režimas

Kai WordPress perima klaidą, jis svetainės administratoriaus adresu siunčia laišką tema „[Tinklalapio pavadinimas] Jūsų tinklalapis turi techninių problemų“. Jame nurodytas kaltas įskiepis ar tema ir yra nuoroda, atidaranti administravimo skydelį atstatymo režimu.

• Šiuo režimu kaltas komponentas pristabdomas tik jums: lankytojai vis dar mato klaidą.
• Skiltyje Įskiepiai arba Išvaizda > Temos išjunkite laiške nurodytą komponentą, tada administravimo juostoje spustelėkite „Išjungti atstatymo režimą“.
• Nuoroda galioja 24 valandas, o WordPress tokį laišką siunčia ne dažniau kaip kartą per dieną. Jei laiškas neatkeliauja, patikrinkite šlamšto aplanką, tada pereikite prie kito būdo.

Perskaitykite klaidą: derinimo žurnalas

Prisijunkite prie svetainės per SFTP arba per hostingo teikėjo failų tvarkyklę, atidarykite šakniniame aplanke esantį wp-config.php ir eilutę define( 'WP_DEBUG', false ); pakeiskite šiomis keturiomis eilutėmis:

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

Jos įrašomos virš eilutės /* That's all, stop editing! Happy publishing. */. Iš naujo įkelkite puslapį su klaida, tada atidarykite wp-content/debug.log. Nustačius WP_DEBUG_DISPLAY į false, pranešimai lieka faile, o ne jūsų lankytojų matomame puslapyje.

Jei debug.log lieka tuščias arba neatsiranda, klaidą užfiksavo pats PHP: ieškokite failo error_log svetainės šakniniame aplanke arba aplanke wp-admin, arba klaidų žurnalų skilties hostingo valdymo skydelyje.

Ką sako pranešimas ir koks sprendimas jam tinka

Lemtinga klaida telpa vienoje eilutėje: klaidos tipas, jos aprašymas, tada in ir visas failo kelias bei eilutės numeris. Kelias yra naudingiausia dalis: wp-content/plugins/pavadinimas/ nurodo įskiepį, wp-content/themes/pavadinimas/ temą.

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

Išjunkite kaltą komponentą be administravimo skydelio

Per SFTP arba failų tvarkyklę

Pervadinkite pranešime nurodyto įskiepio aplanką, pavyzdžiui wp-content/plugins/iskiepio-pavadinimas į iskiepio-pavadinimas.off. WordPress nebeaptinka įskiepio ir nustoja jį įkelti; jo nuostatos lieka išsaugotos duomenų bazėje, o WordPress jį išjungia, kai kitą kartą atidaromas įskiepių ekranas.

Temos atveju, pervadinus jos aplanką wp-content/themes kataloge, administravimo skydelis vėl pasiekiamas, bet lankytojai mato tuščią puslapį, kol nėra aktyvios temos. Iš karto atidarykite Išvaizda > Temos: WordPress pastebi, kad aktyvi tema neveikia, ir įjungia įdiegtą numatytąją temą.

Su WP-CLI

wp plugin list --status=active
wp plugin deactivate iskiepio-pavadinimas
wp theme list
wp theme activate twentytwentyfive

Pirmoji komanda užfiksuoja, kurie įskiepiai aktyvūs, o tai naudinga prieš bet kokį masinį išjungimą. Jei pats WP-CLI sustoja ties klaida, pridėkite prie komandos --skip-plugins --skip-themes, kad jis pasileistų neįkeldamas įskiepių ir temos. Aplanko wp-content/mu-plugins įskiepiai vis tiek įkeliami; jei klaida kyla dėl vieno iš jų, pervadinkite jo failą.

Kai pranešime nenurodytas joks komponentas, wp plugin deactivate --all išjungia visus įskiepius. Jei svetainė vėl veikia, aktyvuokite juos po vieną, kaskart iš naujo įkeldami svetainę: paskutinis prieš klaidos sugrįžimą aktyvuotas įskiepis ir yra kaltininkas.

Kai svetainė vėl veikia

1. Vėl nustatykite define( 'WP_DEBUG', false ); ir pašalinkite WP_DEBUG_LOG iš wp-config.php.
2. Ištrinkite wp-content/debug.log: jis yra iš interneto pasiekiamame aplanke, todėl jį gali perskaityti bet kas, o jame yra serverio kelių.
3. Atnaujinkite arba pakeiskite kaltą komponentą, prieš tai perskaitę jo pakeitimų žurnalą.
4. Išvalykite podėlio įskiepio podėlį, taip pat hostingo teikėjo podėlį, jei jis toks yra.
5. Kitam kartui: atnaujinimus pirmiausia išbandykite svetainės kopijoje, o tik tada taikykite veikiančiai svetainei.