WordPress kritik xəta jurnalı haradadır?

wp-config.php faylında WP_DEBUG və WP_DEBUG_LOG dəyərlərini true etsəniz, WordPress wp-content/debug.log faylına yazır. Bunlar sönülüdürsə, xəta yenə də hostinqin PHP xəta jurnalına düşür — adətən idarə panelindəki jurnallar və ya xəta jurnalları bölməsindən əlçatandır. Heç nə yazılmayıb qərarına gəlməzdən əvvəl hər ikisini yoxlayın.

WordPress bərpa rejimi e-poçtu niyə gəlmədi?

E-poçt sizin giriş ünvanınıza yox, Parametrlərdəki sayt admin ünvanına gedir və onu göndərən elə indicə çökmüş PHP prosesidir, ona görə çatdırılma tez-tez alınmır. Paylaşılan hostinqlər də SMTP olmadan gedən poçtu bloklayır. Spam qovluğuna baxın, sonra e-poçtu gözləmədən plaginləri SFTP üzərindən söndürün.

wp-admin panelinə girə bilmirəmsə kritik xətanı necə düzəldim?

SFTP və ya hostinqin fayl menecerinə qoşulun və wp-content/plugins qovluğunun adını plugins-off olaraq dəyişin. Bu, bütün plaginləri eyni anda deaktiv edir və demək olar ki, həmişə admin girişini bərpa edir. Adı geri qaytarın, sonra xəta qayıdana qədər plaginləri bir-bir aktivləşdirin — beləcə səbəbkarı taparsınız.

PHP versiyasının yenilənməsi WordPress-də kritik xətaya səbəb ola bilərmi?

Bəli, üstəlik bu ən çox rast gəlinən səbəblərdən biridir. Hostinqlər PHP-ni avtomatik yeniləyir və artıq silinmiş sintaksisdən istifadə edən köhnə plagin və ya mövzu kodu dərhal fatal xəta verir. Jurnal qeydi adətən wp-content daxilindəki konkret faylı göstərir. Hostinq panelindən PHP-ni geri qaytarmaq diaqnozu təsdiqləyir, amma bu müvəqqəti həlldir.

Kritik xəta mesajı saytımın sındırıldığını bildirirmi?

Adətən yox. Bu halların böyük əksəriyyəti PHP versiyanızla uyğun gəlməyən plagin/mövzu yeniləməsi və ya yaddaşın tükənməsidir. Zərərli kod da fatal xəta yarada bilər, lakin onda jurnal qeydi tanımadığınız bir faylı və ya oxunmaz şəkildə gizlədilmiş kodu göstərəcək. Sındırılma qərarına gəlməzdən əvvəl jurnalı oxuyun.

"Bu veb-saytda kritik xəta baş verib": Nə deməkdir və necə düzəldilir

Q: "Bu veb-saytda kritik xəta baş verib" nə deməkdir?

Bu o deməkdir ki, PHP səhifəni qurarkən fatal xətaya düşüb və WordPress boş ağ ekran görünməmişdən əvvəl onu tutub. Mesaj qəsdən qeyri-müəyyəndir ki, ziyarətçilər fayl yollarını və kodu görməsin. Fayl adı və sətir nömrəsi ilə birlikdə əsl xəta isə serverdəki jurnala yazılır.

Bu mesaj o deməkdir ki, PHP səhifənizi qurarkən fatal xətaya düşüb və WordPress bunun boş ağ ekrana çevrilməsinin qarşısını alıb. Xəta realdır, konkretdir və qeydə alınıb — WordPress sadəcə onu brauzerdə çap etməkdən imtina edir, çünki ictimai səhifədəki stack trace fayl yollarını və kodu hər gələnə açır.

Ona görə də həll heç vaxt təxminə əsaslanmır. Ardıcıllıq belədir: əsl xətanı oxu, sonra onun dediyinə uyğun hərəkət et.

Əslində nə baş verir

WordPress 5.2-dən bəri nüvədə fatal xəta idarəçisi var. PHP sorğunun ortasında öləndə idarəçi işə düşür, çökmə çıxışını nəzakətli ümumi cümlə ilə əvəzləyir və — hansı plagin və ya mövzunun səbəb olduğunu müəyyən edə bilsə — sayt administratoruna bərpa rejiminə keçid ehtiva edən e-poçt göndərməyə çalışır.

Köhnə “ağ ölüm ekranı” əvəzinə bunu görməyinizin səbəbi budur. Bu, irəliləyişdir, amma eyni zamanda diaqnostik məlumatın standart olaraq gizlədilməsi deməkdir. Mesajın iki variantı mövcuddur:

Gördüyünüz	Harada	Sizə nə deyir
”There has been a critical error on this website.”	Ön tərəf, sistemdən çıxmış halda	Fatal xəta baş verib, əlavə detal açıqlanmır
Eyni sətir, üstəgəl “Learn more about troubleshooting WordPress”	Ön tərəf və ya wp-admin	Eyni xəta, WordPress sizə sənədləşmə səhifəsini təklif edir
”…Please check your site admin email inbox for instructions.”	Ön tərəf	İdarəçi bərpa e-poçtunu göndərdiyini hesab edir

Üçüncü variant faydalı olanıdır. O bildirir ki, WordPress çökməni konkret plagin və ya mövzuya aid edib və sizə içəri girmək üçün yol vermək istəyib.

Addım 1: bərpa rejimi e-poçtunu yoxlayın

WordPress bərpa keçidini sayt admin e-poçt ünvanına göndərir — Parametrlər → Ümumi bölməsindəkinə — və bu, çox vaxt sizin giriş etdiyiniz ünvan deyil. Həmin qutuya, sonra da spam qovluğuna baxın.

E-poçtda ?action=enter_recovery_mode kimi bir şeylə bitən uzun keçid olur. Onu açanda wp-admin panelinə bərpa rejimində daxil olursunuz: problemli plagin və ya mövzu dayandırılır və yuxarıda qırmızı bildirişlə işarələnir. Oradan onu adi qaydada deaktiv edə bilərsiniz.

İki dürüst qeyd. Birincisi, e-poçtu elə indicə çökmüş PHP prosesi yaradır, üstəlik hostinqdə işlək poçt nəqli ümumiyyətlə olmaya bilər — çatdırılmama adi haldır və e-poçtun gəlməməsi xəta haqqında heç nə demir. İkincisi, bərpa keçidinin müddəti bitir (standart olaraq təxminən bir gün), ona görə qutunuzdakı köhnə e-poçt sadəcə artıq işləməyə bilər; saytı yenidən yükləyib təzə çökmə yaradın və yeni məktubu gözləyin.

E-poçtun həqiqətən oxuduğunuz ünvana gəlməsini istəyirsinizsə, onu wp-config.php faylında birbaşa təyin edin:

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

Addım 2: əsl xətanı oxuyun

Sınmış saytı beş dəqiqəlik təmirə çevirən addım məhz budur. wp-config.php faylına, redaktəni dayandırmağı deyən sətirdən yuxarıya bunları əlavə edin:

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

WP_DEBUG_DISPLAY dəyərinin false olması vacibdir — o, xətanı brauzerdən uzaq saxlayır, amma diskə yazılmasına mane olmur, beləcə problemi araşdırarkən yolları ziyarətçilərə açmırsınız.

Sınmış səhifəni bir dəfə yenidən yükləyin, sonra wp-content/debug.log faylını açın. Sonuncu qeyd təxminən belə görünəcək:

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

Cavab elə fayl yolunun özüdür. Əgər o, wp-content/plugins/ daxilinə işarə edirsə, səbəb həmin plagindir. wp-content/themes/ daxilinə işarə edirsə, səbəb mövzudur — çox vaxt bu yaxınlarda functions.php faylına yapışdırılmış nəsə.

debug.log görünmürsə, qovluğa yazmaq mümkün olmaya bilər və ya təhlükəsizlik plagini jurnalı başqa yerə köçürüb. Onda hostinqin PHP xəta jurnalına müraciət edin — idarə panellərinin çoxunda “Error Log” və ya “Logs” bölməsi var və eyni fatal xəta orada vaxt möhürü ilə birlikdə olacaq.

Qeydi WordPress xəta jurnalı deşifrəedicisinə yapışdırın: o, PHP dilindəki ifadəni praktikada nə demək olduğuna çevirir və ilk hansı fayla baxmalı olduğunuzu göstərir.

İşiniz bitəndə bu debug sətirlərini silin. WP_DEBUG parametrini istehsalatda açıq saxlamaq diski doldurur və WP_DEBUG_DISPLAY nə vaxtsa geri qaytarılsa, server yollarını ictimai şəkildə çap edir.

Addım 3: wp-admin panelinə qayıdın

Əgər wp-admin da ölübsə və bərpa e-poçtu gəlməyibsə, bütün plaginləri fayl sistemi səviyyəsində söndürün. SFTP (və ya hostinqin fayl meneceri) ilə qoşulun və bir qovluğun adını dəyişin:

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

WordPress plaginləri tapa bilmir, ona görə hamısını deaktiv edir və admin girişi demək olar ki, həmişə qayıdır. Sonra:

Qovluğun adını yenidən plugins edin. Hər şey deaktiv qalır — WordPress onları qeyri-aktiv kimi qeydə alıb.
Plaginləri bir-bir aktivləşdirin, hər dəfə ön tərəfi yükləyin.
Xətanı geri qaytaran plagin sizin səbəbkarınızdır.

Bütün plaginlər sönülü ikən sayt hələ də sınıqdırsa, şübhəli mövzudur. wp-content/themes/ içindəki aktiv mövzunun qovluq adını dəyişin — quraşdırılıbsa, WordPress standart mövzuya keçəcək.

Bilməyə dəyən üç səbəb

Fatal xəta verən plagin və ya mövzu yeniləməsi. Açıq-aydın ən çox rast gəlinəni. Jurnal faylı birbaşa adlandırır. Həmin bir plagini əvvəlki versiyasına qaytarın və ya deaktiv saxlayıb jurnal sətri ilə birlikdə tərtibatçıya yazın.

PHP versiyası uyğunsuzluğu. Hostinqlər PHP-ni cədvəl üzrə, bəzən çox xəbərdarlıq etmədən yeniləyir. Köhnə PHP üçün yazılmış kod yeni versiyada ümumiyyətlə oxunmaya bilər. Əlaməti budur: sizin tərəfinizdə heç nə dəyişməyib, amma hər şey eyni anda sınıb. Hostinq panelində PHP-ni bir kiçik versiya geri qaytarmaq etibarlı diaqnostikadır — lakin bunu həll yox, vaxt qazanmaq kimi qəbul edin. Köhnə PHP versiyaları təhlükəsizlik yamaqları almağı dayandırır.

Yaddaşın tükənməsi. Jurnalda “Allowed memory size of X bytes exhausted” yazılır. Limiti wp-config.php faylında qaldırmaq məntiqlidir:

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

Bunun nə etdiyi barədə dürüst olaq: o, tavanı qaldırır, amma bir səhifəni render etmək üçün 256MB yeyən şeyi düzəltmir. Limiti davamlı olaraq artırmaq lazım gəlirsə, əsl problem başqa yerdədir — adətən idxal prosesi, səhifə qurucusu və ya pis yazılmış sorğu.

Rahatlıqla nəzərə almaya biləcəyiniz məsləhətlər

“Sadəcə yaddaş limitini artır.” Yalnız jurnal həqiqətən yaddaşın tükəndiyini yazırsa aktualdır. Əks halda heç nəyi dəyişmir və xətanı heç oxumadığınızı gizlədir.

“WordPress nüvəsini yenidən qur.” Nüvə faylları nadir hallarda səbəb olur və onları əvəzləmək bir jurnal sətrini oxumağa sərf edə biləcəyiniz vaxtı yeyir.

“Fatal xəta idarəçisini söndür.” Onu söndürən sabit mövcuddur və nəticədə tutulmuş xəta əvəzinə ictimai saytınızda çılpaq xəta çap olunur. Bu, fayl yollarını ziyarətçilərə açır. Əvəzində WP_DEBUG_LOG ilə birlikdə WP_DEBUG_DISPLAY sönülü işlədin — eyni məlumat, heç bir açıqlanma olmadan.

“Keşi təmizlə.” Fatal xəta PHP-də, keş plagininin nəsə təqdim edə biləcəyindən əvvəl baş verir. Xəta səhifəsinin keşlənmiş surəti təqdim olunursa, təmizləmək səbəbi düzəltdikdən sonra kömək edir — heç vaxt onun əvəzinə yox.

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

Jurnal wp-content daxilindəki bir şeyi yox, nüvə faylını göstərirsə, daha ehtimallı izah nüvənin zədələnməsi deyil, daha əvvəl yüklənən plaginin nüvənin güvəndiyi vəziyyəti pozmasıdır. Qovluq adını dəyişməklə hər şeyi söndürün, saytın təmiz yükləndiyini təsdiqləyin, sonra plaginləri bir-bir geri qaytarın — xəta qayıtmazdan əvvəl aktivləşdirdiyiniz sonuncu plagin, jurnal sətri ilə birlikdə bildirməli olduğunuzdur.