WordPress-də Ağ Ölüm Ekranı (White Screen of Death) İzahı

Ağ ölüm ekranı görə bilmədiyiniz bir PHP fatal xətasıdır. WordPress render prosesinin ortasında bərpaolunmaz xətaya düşür, PHP dayanır və istehsalat (production) serverlərində xətaların göstərilməsi söndürülü olduğu üçün səhifə səbəbi çap etmək əvəzinə boş qayıdır. Həlli demək olar ki, heç vaxt təxminə əsaslanmır: debug jurnalını (log) yandırın, wp-content/debug.log faylını açın və sonuncu fatal sətri oxuyun. Orada dəqiq fayl adı göstərilir — demək olar ki, həmişə bir plagin və ya mövzu — və məhz həmin bir sətir bütün təmirin özüdür.

Ekran niyə boşdur

PHP-nin display_errors adlı parametri var. İşləmə (development) maşınında o adətən yanıqdır, ona görə fatal xəta ekrana stack trace çap edir. Real hostinqdə isə o standart olaraq söndürülüdür, çünki fayl yollarını və xətaları ziyarətçilərə sızdırmaq təhlükəsizlik problemidir. Beləliklə, nəsə fatal xəta yaradanda — artıq mövcud olmayan funksiyaya çağırış, yüklənməmiş sinif, plagin yeniləməsindəki sintaksis xətası — PHP ölür və heç nə göndərmir. Brauzeriniz boş sənəd render edir. Bu, elə “ağ ekran”dır.

WordPress 5.2-dən bəri bunları tutmağa çalışan bir fatal xəta idarəçisi (WP_Fatal_Error_Handler) var. O işləyəndə boş səhifə almırsınız — “Bu veb-saytda kritik xəta baş verib” mesajını, üstəlik admin ünvanına çox vaxt həqiqi xətanı və Bərpa Rejiminə (Recovery Mode) keçid ehtiva edən bir e-poçt alırsınız. Həqiqətən boş ekran isə adətən xətanın həmin idarəçi işə düşməmişdən əvvəl baş verdiyini bildirir: parse/sintaksis xətası (kompilyasiya vaxtı tutulur), sınmış must-use plagini və ya aktiv mövzunun functions.php faylındakı fatal xəta. Hər halda səbəb bir yerdə yazılıb. Sadəcə yazmağı yandırmaq lazımdır.

Ardıcıllıqla düzəldin

1. Jurnalı yandırın. SFTP üzərindən wp-config.php faylını redaktə edin və /* That's all, stop editing! */ sətrindən yuxarıya bunu əlavə edin:

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

WP_DEBUG_DISPLAY false xətaları ictimai səhifədən uzaq saxlayır, WP_DEBUG_LOG isə onları wp-content/debug.log faylına yazır. Təzə qeyd yaratmaq üçün sınmış səhifəni bir dəfə yenidən yükləyin.

2. Sonuncu fatal xətanı oxuyun. wp-content/debug.log faylını açın və aşağıya baxın:

tail -n 30 wp-content/debug.log

Belə bir sətir axtarırsınız:

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

Yol günahkarı göstərir: plugins/some-addon. Budur cavabınız. Əgər trace uzundursa və ya mesaj anlaşılmazdırsa (Allowed memory size exhausted, Cannot redeclare, tanımadığınız bir sinif adı), onu bizim error log decoder alətinə yapışdırın — o səs-küyü təmizləyir, yolun hansı plaginə və ya mövzuya işarə etdiyini deyir və konkret xəta növünün nə demək olduğunu izah edir.

3. Adı çəkilən komponenti deaktiv edin. /wp-admin-ə çata bilmirsiniz, ona görə bunu SFTP üzərindən edin. Problemli plaginin qovluğunun adını dəyişin, məsələn some-addon → some-addon.off. WordPress tapa bilmədiyi qovluğu yükləyə bilmir, ona görə plagini deaktiv edir və sayt geri qayıdır. Əgər jurnal mövzunuza işarə edirsə, aktiv mövzu qovluğunun adını dəyişməklə standart bir mövzuya keçin — WordPress paket şəklində gələn bir twentytwentysomething mövzusuna qayıdır.

4. Əgər jurnal yazmırsa, wp-content yazıla bilən deyil və ya xəta server səviyyəsindədir. Bunun əvəzinə hostinqin PHP xəta jurnalını yoxlayın:

find . -name "error_log" -newermt "-1 hour"

Eyni məlumat, fərqli fayl. cPanel/Apache konfiqurasiyaları çox vaxt sayt kökündə və ya sınan qovluqda bir error_log yerləşdirir.

Nə etməməli

Sadəcə yaddaş limitini qaldırmayın. İnternetdə ən çox təkrarlanan məsləhət WP_MEMORY_LIMIT dəyərini 256M və ya 512M-ə qaldırmaqdır. Bu, WSOD-u yalnız jurnal həqiqətən Allowed memory size of N bytes exhausted deyirsə düzəldir. Əgər xəta Call to undefined function-dırsa, əlavə yaddaş heç nə etmir — təsadüfi bir parametri dəyişmisiniz və ekran hələ də ağdır. Əvvəlcə jurnalı oxuyun, sonra yaddaşı yalnız problem məhz yaddaşdırsa qaldırın.

Keşinizi təmizləyib bunu diaqnoz saymayın. Ağ ekran hər hansı HTML mövcud olmamışdan əvvəl serverdə PHP-nin ölməsidir. Köhnəlmiş keşlənmiş bir resurs boş sənədə səbəb ola bilməz. (Sınmış bir keşləmə plagini səbəb ola bilər — amma jurnal onun adını çəkəcək, məsələ də elə budur.)

WordPress nüvəsini (core) redaktə etməyin və ya yenidən qurmayın. Fatal xəta demək olar ki, heç vaxt wp-includes və ya wp-admin-də olmur; o, jurnalın işarə etdiyi plagin və ya mövzudadır. Nüvəni yenidən qurmaq yavaş, riskli, üstəlik təsdiqləmədiyiniz bir simptomu müalicə etməkdir.

Bütün plaginləri söndürüb kor-koranə bir-bir yenidən aktivləşdirməyin. Bisektə (yarıya bölmə) işləyir, amma yavaş yoldur. Jurnal dəqiq qovluğu bir addımda deyir. “Hər şeyi söndür” metoduna yalnız oxunaqlı heç bir xəta olmayanda müraciət edin.

İstehsalatda (production) display_errors-u yanıq qoymayın. Sayt geri qayıdandan sonra debug təriflərini silin (və ya WP_DEBUG dəyərini yenidən false edin). Ziyarətçilərə çap olunan xətalar yollarınızı ifşa edir.

Hələ də ilişib qalmısınız?

Əgər jurnal bir plaginin adını çəkir, amma onu söndürmək ekranı təmizləmirsə, birincinin altında ikinci bir fatal xəta var — jurnalı yenidən yandırın və yeni sonuncu sətri oxuyun; fatal xətalar yığılır. Əgər mesajın özü divardırsa, onu error log decoder alətinə atın və xəta növünü və fayl yolunu sizin üçün tərcümə etsin. Ağ ekran yalnız jurnal söndürülü olduğu müddətdə sirr olaraq qalır.