Bu Sitede Kritik Bir Hata Oluştu: Ne Anlama Geliyor ve Nasıl Çözülür

Bu mesaj, PHP’nin sayfanızı oluştururken bir fatal hataya düştüğü ve WordPress’in bunu boş beyaz ekrana dönüşmeden yakaladığı anlamına gelir. Hata gerçektir, spesifiktir ve kaydedilmiştir — WordPress sadece bunu tarayıcıya yazdırmayı reddeder, çünkü herkese açık bir sayfadaki stack trace, siteyi ziyaret eden herkese dosya yollarını ve kodu sızdırır.

Bu yüzden çözüm asla tahmin işi değildir. Yapılacak şey şu: gerçek hatayı okuyun, sonra ne diyorsa ona göre hareket edin.

Aslında ne oluyor

WordPress 5.2’den beri çekirdeğe gömülü bir fatal hata işleyicisi var. PHP istek ortasında öldüğünde işleyici devreye girer, çökme çıktısını o kibar ve genel cümleyle değiştirir ve — hangi eklenti ya da temanın buna yol açtığını çözebilirse — site yöneticisine kurtarma moduna giden bir bağlantı içeren e-posta göndermeye çalışır.

Eski beyaz ölüm ekranı yerine bunu görmenizin nedeni budur. Bir ilerleme, ama aynı zamanda teşhis bilgisinin varsayılan olarak gizlendiği anlamına gelir. Mesajın iki sürümü vardır:

Gördüğünüz	Nerede	Size ne söyler
”Bu web sitesinde kritik bir hata oluştu.”	Ön yüz, oturum kapalıyken	Fatal hata oluştu, başka ayrıntı gösterilmiyor
Aynı satır artı “WordPress sorun giderme hakkında daha fazla bilgi edinin”	Ön yüz ya da wp-admin	Aynı hata, WordPress size el kitabı sayfasını öneriyor
”…Talimatlar için site yönetici e-posta kutunuzu kontrol edin.”	Ön yüz	İşleyici, kurtarma e-postasını gönderdiğini düşündü

Asıl işe yarayan üçüncü varyanttır. WordPress’in çökmeyi belirli bir eklenti ya da temaya bağladığı ve size içeri girecek bir yol vermeye çalıştığı anlamına gelir.

Adım 1: kurtarma modu e-postasını kontrol edin

WordPress kurtarma bağlantısını site yönetici e-posta adresine gönderir — Ayarlar, Genel bölümündeki adrese — ki bu çoğu zaman giriş yaptığınız adres değildir. O kutuya bakın, spam klasörünü de kontrol edin.

E-posta, ?action=enter_recovery_mode gibi bir ifadeyle biten uzun bir bağlantı içerir. Bu bağlantıyı açmak sizi kurtarma modunda wp-admin’e sokar; orada sorunlu eklenti ya da tema duraklatılmış ve en üstte kırmızı bir uyarıyla işaretlenmiş olur. Oradan normal şekilde devre dışı bırakabilirsiniz.

İki dürüst uyarı. Birincisi, e-posta az önce çöken PHP süreci tarafından, üstelik hiç çalışan bir posta altyapısı olmayabilecek bir sunucuda üretilir — teslim edilememesi çok yaygındır ve gelmemesi hata hakkında size hiçbir şey söylemez. İkincisi, kurtarma bağlantısının ömrü doludur (varsayılan olarak yaklaşık bir gün), yani gelen kutunuzdaki eski bir e-posta artık çalışmıyor olabilir; siteyi yeniden yükleyip yeni bir çökme tetikleyin ve yeni e-postayı bekleyin.

E-postanın gerçekten okuduğunuz bir adrese gitmesini istiyorsanız wp-config.php içinde açıkça belirtin:

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

Adım 2: gerçek hatayı okuyun

Bozuk bir siteyi beş dakikalık bir işe çeviren adım budur. Şu satırları wp-config.php dosyasına, düzenlemeyi burada bırakın diyen satırın üstüne ekleyin:

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

WP_DEBUG_DISPLAY değerinin false olması önemlidir — hatayı tarayıcıdan uzak tutarken diske yazmayı sürdürür, yani hata ayıklarken ziyaretçilere sunucu yollarını göstermezsiniz.

Bozuk sayfayı bir kez yeniden yükleyin, sonra wp-content/debug.log dosyasını açın. Son kayıt kabaca şuna benzeyecektir:

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

Dosya yolu, cevabın kendisidir. wp-content/plugins/ içine işaret ediyorsa neden o eklentidir. wp-content/themes/ içine işaret ediyorsa temadır — çoğu zaman da yakın zamanda functions.php dosyasına yapıştırılmış bir şey.

debug.log ortaya çıkmıyorsa dizin yazılabilir olmayabilir ya da bir güvenlik eklentisi log’u başka yere taşımış olabilir. Bu durumda hosting firmanızın PHP hata log’una dönün — çoğu kontrol panelinde “Error Log” ya da “Logs” bölümü vardır ve aynı fatal hata zaman damgasıyla orada durur.

Kaydı WordPress hata log’u çözümleyiciye yapıştırarak PHP’nin ifadesini pratikte ne anlama geldiğine ve önce hangi dosyaya bakmanız gerektiğine çevirin.

İşiniz bittiğinde bu debug satırlarını silin. WP_DEBUG değerini canlı sitede açık bırakmak diski doldurur ve WP_DEBUG_DISPLAY bir şekilde geri açılırsa sunucu yollarını herkese yazdırır.

Adım 3: wp-admin’e geri girin

wp-admin de ölüyse ve kurtarma e-postası gelmediyse tüm eklentileri dosya sistemi seviyesinde devre dışı bırakın. SFTP (ya da hosting firmanızın dosya yöneticisi) ile bağlanın ve tek bir klasörün adını değiştirin:

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

WordPress eklentileri bulamaz, hepsini devre dışı bırakır ve yönetim paneline erişim neredeyse her zaman geri gelir. Sonrasında:

1. Klasörün adını tekrar plugins yapın. Hepsi devre dışı kalır — WordPress onları pasif olarak kaydetti.
2. Eklentileri teker teker etkinleştirin, her birinden sonra ön yüzü açın.
3. Hatayı geri getiren eklenti, aradığınız sorumludur.

Tüm eklentiler kapalıyken site hâlâ bozuksa şüpheli temadır. wp-content/themes/ içindeki aktif temanın klasör adını değiştirin; kuruluysa WordPress varsayılan bir temaya geri döner.

Bilmeye değer üç neden

Fatal hata veren bir eklenti ya da tema güncellemesi. Açık ara en yaygını. Log dosyanın adını doğrudan verir. O eklentiyi önceki sürümüne geri alın ya da devre dışı bırakıp log satırıyla birlikte geliştiricisine yazın.

PHP sürüm uyumsuzluğu. Hosting firmaları PHP’yi belirli bir takvimle, bazen fazla haber vermeden yükseltir. Eski PHP için yazılmış kod, yeni sürümde tamamen ayrıştırılamaz hale gelebilir. İşareti şudur: sizin tarafınızda hiçbir şey değişmedi ama her şey aynı anda bozuldu. Hosting panelinizden PHP’yi bir alt sürüme almak geçerli bir teşhis yöntemidir — ama bunu bir çözüm değil, zaman kazanma olarak görün. Eski PHP sürümleri güvenlik yamaları almayı bırakır.

Bellek tükenmesi. Log “Allowed memory size of X bytes exhausted” der. Limiti wp-config.php içinde yükseltmek makul bir adımdır:

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

Ne yaptığı konusunda dürüst olalım: tavanı kaldırır, tek bir sayfayı oluştururken 256MB’ı ne tükettiyse onu düzeltmez. Limiti sürekli yükseltmek gerekiyorsa asıl sorun başka bir şeydir — genelde bir içe aktarma işlemi, bir sayfa oluşturucu ya da kötü yazılmış bir sorgu.

Gönül rahatlığıyla göz ardı edebileceğiniz tavsiyeler

“Bellek limitini artırman yeter.” Yalnızca log gerçekten bellek tükendiğini söylüyorsa geçerli. Aksi halde hiçbir şeyi değiştirmez, sadece hatayı hiç okumadığınızı gizler.

“WordPress çekirdeğini yeniden kur.” Çekirdek dosyaları nadiren nedendir ve onları değiştirmek, tek bir log satırını okumaya harcayabileceğiniz zamanı çöpe atar.

“Fatal hata işleyicisini kapat.” Bunu devre dışı bırakan bir sabit var ve sonuç şu olur: yakalanmış bir hata yerine ham hata herkese açık sitenizde yazdırılır. Bu, dosya yollarını ziyaretçilere gösterir. Bunun yerine WP_DEBUG_LOG kullanın ve WP_DEBUG_DISPLAY kapalı olsun — aynı bilgi, hiçbir sızıntı yok.

“Önbelleği temizle.” Fatal hata, bir önbellek eklentisi herhangi bir şey sunabilecek duruma gelmeden PHP içinde gerçekleşir. Hata sayfasının önbelleğe alınmış bir kopyası sunuluyorsa temizlemek nedeni çözdükten sonra işe yarar — asla onun yerine geçmez.

Hâlâ takıldınız mı?

Log wp-content içindeki bir şeyi değil de bir çekirdek dosyasını gösteriyorsa daha olası açıklama, bozulmuş çekirdek değil, daha önce yüklenen bir eklentinin çekirdeğin güvendiği durumu bozmasıdır. Klasör adını değiştirerek her şeyi kapatın, sitenin temiz açıldığını doğrulayın, sonra eklentileri teker teker geri getirin — hata dönmeden önce etkinleştirdiğiniz son eklenti, log satırını ekleyerek bildirmeniz gereken eklentidir.