Ano ang ibig sabihin ng "there has been a critical error on this website"?

Ibig sabihin, tumama ang PHP sa isang fatal error habang binubuo ang page, at nasalo ito ng WordPress bago pa lumabas ang blangkong puting screen. Sinadyang gawing malabo ang mensahe para hindi makita ng bisita ang file paths at code. Ang totoong error, kasama ang file at line number, ay naisusulat sa isang log sa server.

Saan matatagpuan ang log ng critical error sa WordPress?

Kung itinakda mo ang WP_DEBUG at WP_DEBUG_LOG bilang true sa wp-config.php, isinusulat ito ng WordPress sa wp-content/debug.log. Kung naka-off ang mga iyon, mapupunta pa rin ang error sa PHP error log ng host mo, na kadalasang makikita sa hosting control panel sa ilalim ng logs o error logs. Tingnan pareho bago mo isipin na walang naitala.

Bakit hindi ako nakatanggap ng recovery mode email ng WordPress?

Napupunta ang email sa site admin address na nakalagay sa Settings, hindi sa address na ginagamit mong mag-login, at ipinapadala ito ng parehong sirang PHP na kaka-crash lang — kaya madalas na hindi ito nakakarating. Bina-block din ng mga shared host ang papalabas na mail kung walang SMTP. Tingnan ang spam, pagkatapos ay kalimutan na ang email at i-disable na lang ang mga plugin sa pamamagitan ng SFTP.

Paano ko aayusin ang critical error kung hindi ako makapasok sa wp-admin?

Kumonekta sa pamamagitan ng SFTP o ng file manager ng host mo at palitan ang pangalan ng wp-content/plugins folder ng plugins-off. Nade-deactivate niyan ang lahat ng plugin nang sabay-sabay at halos palaging bumabalik ang admin access. Ibalik ang dating pangalan, tapos i-activate ang mga plugin nang isa-isa hanggang bumalik ang error — iyon na ang may kasalanan.

Puwede bang maging sanhi ng critical error ang pag-upgrade ng PHP version?

Oo, at isa iyon sa pinakakaraniwang dahilan. Awtomatikong ina-upgrade ng mga host ang PHP, at agad na mag-fafatal ang lumang plugin o theme code na gumagamit ng syntax na tinanggal na. Karaniwang tinutukoy ng log entry ang eksaktong file sa loob ng wp-content. Ang pagbalik ng PHP sa dating bersyon sa hosting panel ay nagkukumpirma ng diagnosis, pero pansamantalang solusyon lang iyon.

Ibig bang sabihin ng critical error na na-hack ang site ko?

Kadalasan, hindi. Halos lahat ng ganitong kaso ay dahil sa update ng plugin o theme na hindi tugma sa PHP version mo, o dahil naubos ang memory. Puwede rin namang magdulot ng fatal error ang malware, pero ituturo ng log entry ang isang hindi pamilyar na file o obfuscated na code. Basahin muna ang log bago isipin na na-kompromiso ka.

"There Has Been a Critical Error on This Website": Ano ang Ibig Sabihin at Paano Ayusin

Ang mensaheng iyon ay nangangahulugang tumama ang PHP sa isang fatal error habang binubuo ang page mo, at nasalo ito ng WordPress bago pa maging blangkong puting screen. Totoo ang error, tiyak, at naitala — ayaw lang ipakita ng WordPress sa browser, dahil ang stack trace sa isang pampublikong page ay naglalantad ng file paths at code sa kahit sinong bumisita.

Kaya hindi kailanman hulaan ang solusyon. Ganito ito: basahin ang totoong error, tapos kumilos base sa sinasabi nito.

Ano talaga ang nangyayari

Mula pa noong WordPress 5.2, may fatal error handler nang nakapaloob sa core. Kapag namatay ang PHP sa gitna ng request, pumapasok ang handler, pinapalitan ang crash output ng magalang at pangkalahatang pangungusap, at — kung matukoy nito kung aling plugin o theme ang may kasalanan — sinusubukan nitong i-email ang site administrator kasama ang link papasok sa recovery mode.

Iyan ang dahilan kung bakit ito ang nakikita mo imbes na ang lumang white screen of death. Pagbuti ito, pero ibig ding sabihin na nakatago ang diagnostic na impormasyon bilang default. May dalawang bersyon ang mensahe:

Ang nakikita mo	Saan	Ano ang ibig sabihin
”There has been a critical error on this website.”	Front end, naka-log out	May naganap na fatal error, walang ibang detalyeng ipinakita
Ang parehong linya kasama ang “Learn more about troubleshooting WordPress”	Front end o wp-admin	Parehong error, inaalok lang ng WordPress ang handbook page
”…Please check your site admin email inbox for instructions.”	Front end	Naniniwala ang handler na nakapagpadala ito ng recovery email

Ang pangatlong bersyon ang pinakamagamit. Ibig sabihin nito, natukoy ng WordPress kung aling plugin o theme ang nag-crash at sinubukan ka nitong bigyan ng paraan para makapasok.

Hakbang 1: tingnan ang recovery mode email

Ipinapadala ng WordPress ang recovery link sa site admin email address — ang nasa Settings, General — na madalas ay hindi ang address na ginagamit mong mag-login. Tingnan ang inbox na iyon, at tingnan din ang spam.

Naglalaman ang email ng mahabang link na nagtatapos sa tulad ng ?action=enter_recovery_mode. Kapag binuksan mo ito, makakapasok ka sa wp-admin sa recovery mode, kung saan naka-pause ang may sala na plugin o theme at may pulang paalala sa itaas. Mula roon, puwede mo na itong i-deactivate nang normal.

Dalawang bagay na dapat linawin. Una, ang email ay gawa ng parehong PHP process na kaka-crash lang, sa isang host na baka wala talagang gumaganang mail transport — karaniwan ang hindi pagdating nito, at ang kawalan nito ay walang sinasabi tungkol sa error. Pangalawa, nag-e-expire ang recovery link (mga isang araw bilang default), kaya baka hindi na gumagana ang lumang email sa inbox mo; pilitin ang bagong crash sa pamamagitan ng pag-reload ng site at maghintay ng bago.

Kung gusto mong mapunta ang email sa inbox na talagang binabasa mo, itakda ito nang direkta sa wp-config.php:

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

Hakbang 2: basahin ang totoong error

Ito ang hakbang na nagpapalit ng sirang site tungo sa limang minutong ayos. Idagdag ang mga linyang ito sa wp-config.php, sa itaas ng linyang nagsasabing itigil na ang pag-edit:

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

Mahalaga ang WP_DEBUG_DISPLAY na naka-false — pinipigilan nito ang error na lumabas sa browser habang isinusulat pa rin ito sa disk, kaya hindi mo inilalantad ang mga path sa mga bisita habang nag-de-debug ka.

I-reload ang sirang page nang isang beses, tapos buksan ang wp-content/debug.log. Ganito ang hitsura ng pinakahuling entry:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

Ang file path ang sagot. Kung tumuturo ito sa loob ng wp-content/plugins/, ang plugin na iyon ang sanhi. Kung sa loob naman ng wp-content/themes/, ang theme ang may sala — madalas ay isang bagay na kaka-paste lang sa functions.php.

Kung walang lumalabas na debug.log, baka hindi writable ang direktoryo, o baka inilipat ng isang security plugin ang logging sa ibang lugar. Bumalik sa PHP error log ng host mo — karamihan sa mga control panel ay may seksiyong “Error Log” o “Logs”, at naroon ang parehong fatal error kasama ang timestamp.

I-paste ang entry sa WordPress error log decoder para isalin ang pananalita ng PHP sa kung ano talaga ang ibig sabihin nito at kung aling file ang unang titingnan.

Burahin ang mga debug na linyang ito kapag tapos ka na. Ang pag-iwan sa WP_DEBUG na naka-on sa production ay pinupuno ang disk at, kung sakaling maibalik sa true ang WP_DEBUG_DISPLAY, ipapakita nito nang hayagan ang mga server path.

Hakbang 3: makabalik sa wp-admin

Kung patay din ang wp-admin at walang dumating na recovery email, i-disable ang lahat ng plugin sa antas ng filesystem. Kumonekta sa pamamagitan ng SFTP (o ng file manager ng host mo) at palitan ang pangalan ng isang folder:

mv wp-content/plugins wp-content/plugins-off

Hindi mahahanap ng WordPress ang mga plugin, kaya nade-deactivate nito lahat at halos palaging bumabalik ang admin access. Pagkatapos:

Ibalik ang pangalan ng folder sa plugins. Mananatiling naka-deactivate ang lahat — naitala ng WordPress na hindi sila aktibo.
I-activate ang mga plugin nang isa-isa, at i-load ang front end pagkatapos ng bawat isa.
Ang nagpapabalik ng error ang siyang may kasalanan.

Kung sira pa rin ang site kahit patay na lahat ng plugin, ang theme ang pinaghihinalaan. Palitan ang pangalan ng folder ng aktibong theme sa wp-content/themes/ at babalik ang WordPress sa default theme kung may naka-install.

Ang tatlong sanhing dapat mong malaman

Update ng plugin o theme na nag-fatal. Ito ang pinakakaraniwan. Direktang tinutukoy ng log ang file. Ibalik ang plugin na iyon sa nakaraang bersyon, o iwan itong naka-deactivate at kontakin ang developer kasama ang linya ng log.

Hindi tugmang PHP version. May iskedyul ang mga host sa pag-upgrade ng PHP, minsan halos walang abiso. Ang code na isinulat para sa lumang PHP ay puwedeng tuluyang hindi na ma-parse sa bagong bersyon. Ang palatandaan: walang binago sa panig mo pero biglang nasira ang lahat. Ang pagbalik ng PHP sa isang minor version pababa sa hosting panel ay wastong diagnostic — pero ituring mong pandagdag na oras lang iyon, hindi solusyon. Hindi na tumatanggap ng security patch ang mga lumang PHP version.

Naubos na memory. Sinasabi ng log na “Allowed memory size of X bytes exhausted”. Makatuwiran ang pagtaas ng limitasyon sa wp-config.php:

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

Maging tapat tayo sa ginagawa nito: inaalis nito ang kisame, hindi nito inaayos kung ano ang umubos ng 256MB sa pag-render ng isang page. Kung paulit-ulit mong kailangang itaas ang limitasyon, may ibang problema — kadalasan ay isang import, isang page builder, o isang masamang pagkakasulat na query.

Payo na puwede mong balewalain

“Taasan mo lang ang memory limit.” Nauugnay lang ito kung talagang sinasabi ng log na naubos ang memory. Kung hindi, wala itong binabago at itinatago lang nito na hindi mo binasa ang error.

“I-reinstall ang WordPress core.” Bihirang ang core files ang sanhi, at ang pagpapalit sa mga ito ay nag-aaksaya ng oras na puwede mong gamitin sa pagbasa ng isang linya ng log.

“Patayin ang fatal error handler.” May constant na puwedeng mag-disable nito, at ang kalalabasan ay maipapakita ang hilaw na error sa pampublikong site mo imbes na masalo ito. Naglalantad iyon ng file paths sa mga bisita. Gamitin ang WP_DEBUG_LOG na naka-off ang WP_DEBUG_DISPLAY — parehong impormasyon, walang panganib na malantad.

“I-clear ang cache mo.” Nangyayari ang fatal error sa PHP bago pa makapaghain ng kahit ano ang isang cache plugin. Kung may naka-cache na kopya ng error page na inihahain, nakakatulong ang pag-clear pagkatapos mong ayusin ang sanhi — hindi kapalit nito.

Hindi pa rin gumagana?

Kung tumuturo ang log sa isang core file sa halip na sa loob ng wp-content, mas malamang na may plugin na na-load nang mas maaga at sinira ang estadong inaasahan ng core — hindi sirang core. Patayin ang lahat gamit ang pagpapalit ng pangalan ng folder, kumpirmahin na malinis na nagla-load ang site, tapos ibalik ang mga plugin nang paisa-isa — ang huling na-enable mo bago bumalik ang error ang siyang ireport, kasama ang linya ng log.