“Bu Sitede Kritik Bir Hata Oluştu” Çözümü: WordPress Beyaz Ekran ve Kurtarma Rehberi

Sabah bilgisayarınızı açıp web sitenize girmeye çalıştığınızda ya da yönetim panelinize (wp-admin) erişmek istediğinizde karşınıza çıkan o meşhur siyah çerçeveli uyarı: “Bu sitede kritik bir hata oluştu. Talimatlar için lütfen site yöneticisi e-postanızı kontrol edin.” (İngilizce kurulumlarda: There has been a critical error on this website). Bu ekranı ilk kez gören her webmasterın yüreği ağzına gelir ve akla gelen ilk soru şudur: “Bütün sitem, yazılarım, resimlerim ve emeklerim silindi mi?”

Hemen derin bir nefes alın ve sakinleşin: Hayır, hiçbir veriniz silinmedi! Veritabanınız, blog yazılarınız, ortam kütüphaneniz ve müşteri siparişleriniz sunucunuzda sapasağlam duruyor. Bu ekran, WordPress’in bir PHP ölümcül hatası (Fatal Error) ile karşılaştığında sitenin tamamen kilitlenmesini ve veritabanı tablolarının bozulmasını engellemek için devreye soktuğu bir koruma kalkanıdır.

Bu kapsamlı rehberde; WordPress 5.2 öncesinde “Beyaz Ekran” (WSOD) olarak bilinen bu sorunun perde arkasını, yönetici e-postası gelmediğinde bile FTP ve cPanel üzerinden nasıl çözüleceğini, PHP 8.x uyumluluğunu ve sitenizi 10 dakika içinde nasıl ayağa kaldıracağınızı adım adım anlatıyoruz.

WordPress Beyaz Ekran Sorunu (White Screen of Death) Neden Olur?

Eski WordPress kullanıcılarının çok iyi bildiği “Beyaz Ekran Sorunu” (White Screen of Death – WSOD), sitenizi açtığınızda karşınıza bomboş, bembeyaz bir sayfanın gelmesi durumuydu. WordPress 5.2 sürümünden önce, PHP motoru ölümcül bir kod hatasıyla karşılaştığında çalışmayı durdurur ve tarayıcıya hiçbir çıktı gönderemeden donup kalırdı.

WordPress 5.2 ile birlikte gelen çekirdek güncellemesiyle bu bembeyaz sayfa, yerini modern bir bildirim arayüzü olan “Bu sitede kritik bir hata oluştu” uyarısına bıraktı. Yani aslında her iki sorun da aynı temel kök nedenlerden kaynaklanır:

• Eklenti ve Tema Çakışmaları: Yeni güncellenen bir eklentinin mevcut temanızla veya başka bir eklentiyle aynı PHP fonksiyonunu ya da sınıfını (class) yeniden tanımlamaya çalışması (Fatal Error: Cannot redeclare…).
• PHP 8.x Sürüm Uyumsuzluğu: Hosting sağlayıcınız sunucudaki PHP sürümünü 8.1, 8.2 veya 8.3’e yükselttiğinde, yıllardır güncellenmeyen eski eklentilerin artık tedavülden kalkan (deprecated) PHP fonksiyonlarını çağırması.
• Yetersiz PHP Bellek Sınırı (Memory Exhausted): WooCommerce, Elementor veya WPML gibi devasa sistemlerin sunucunun ayrılan RAM miktarını (örneğin 64MB veya 128MB) aşması ve scriptin bellek yetersizliğinden patlaması.
• Bozuk Dosya Düzenlemeleri: functions.php veya wp-config.php dosyasına elle kod eklerken yapılan tek bir noktalı virgül (;) veya tırnak işareti eksikliği (Parse Error).
• Bozuk Veritabanı Tabloları: Sunucu elektrik kesintisi veya MySQL çökmesi sonrası `wp_options` tablosunun kilitlenmesi.

1. Adım: Kurtarma Modu (Recovery Mode) ve E-Posta Gelmediğinde Yapılacaklar

WordPress, kritik bir hata oluştuğunda site yöneticisinin e-posta adresine özel bir “Kurtarma Modu Bağlantısı” gönderir. Bu bağlantıya tıkladığınızda:

1. Hatalı eklenti veya tema sadece sizin admin oturumunuz için geçici olarak devre dışı bırakılır.
2. Admin paneline giriş yapabilir, ekranın üst kısmında “Hangi eklentinin hangi hatayı verdiği” uyarısını görebilir ve o eklentiyi tek tıkla pasife alabilirsiniz.

E-Posta Gelmiyor mu? Panik Yapmayın!
Türkiye’deki birçok hosting sunucusunda yerel PHP mail() fonksiyonu spam engellemesi nedeniyle devre dışıdır veya WordPress SMTP eklentisi henüz kurulmamıştır. Dolayısıyla yöneticilerin %70’i bu kurtarma e-postasını hiçbir zaman alamaz. E-posta gelmediyse doğrudan aşağıdaki 2. ve 3. adımlara geçerek sorunu manuel çözebilirsiniz.

2. Adım: Hata Ayıklama Modu (WP_DEBUG) İle Gizli Hatayı Ortaya Çıkarma

Karanlıkta el yordamıyla eklenti aramak yerine sunucunun arka planda hata günlüğü tutmasını sağlayabilirsiniz. Ziyaretçilere teknik hata göstermeden hataları bir log dosyasına kaydetmek için:

1. cPanel Dosya Yöneticisi veya FileZilla FTP programıyla sitenizin ana dizinine (public_html) bağlanın.
2. Ana dizinde bulunan wp-config.php dosyasını metin düzenleyiciyle açın.
3. /* That's all, stop editing! Happy publishing. */ satırının hemen üzerine şu kod bloğunu yerleştirin:

// WordPress Güvenli Hata Ayıklama Modu (Ziyaretçiye Göstermez, Dosyaya Yazar)
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Bu kodu kaydedip sitenizi tarayıcıda bir kez yenileyin. Ardından FTP’de wp-content/ klasörüne gidin. Orada yeni oluşan debug.log isimli dosyayı göreceksiniz. Dosyayı açtığınızda en alt satırda şu şekilde nokta atışı bir hata görürsünüz:

PHP Fatal error: Cannot redeclare custom_seo_function() in /public_html/wp-content/plugins/ornek-eklenti/plugin.php on line 42

Artık suçlunun kim olduğunu (ornek-eklenti) ve hangi satırda patladığını tam olarak biliyorsunuz!

3. Adım: Eklenti Çakışmasını Çözme (FTP Klasör İsim Değiştirme Hilesi)

Eğer hata günlüğünde suçlu bir eklenti görünüyorsa ya da admin paneline hiç erişemiyorsanız, tüm eklentileri tek hamlede güvenle devre dışı bırakabilirsiniz:

1. FTP üzerinden wp-content/ klasörüne girin.
2. Buradaki plugins klasörünün adını plugins_eski olarak değiştirin.
3. Sitenizi tarayıcıda gizli sekmede yenileyin. Siteniz ve admin paneliniz anında açılacaktır! Çünkü WordPress eklenti klasörünü bulamayınca tüm eklentileri güvenle pasife çeker.
4. Şimdi klasörün adını tekrar plugins yapın.
5. WordPress admin paneline girip eklentileri tek tek aktifleştirin. Hata veren eklentiye sıra geldiğinde site tekrar kritik hata verecek; böylece arızalı eklentiyi kesin olarak tespit edip silebilir veya alternatifini arayabilirsiniz.

4. Adım: PHP 8.x Sürüm Uyumsuzluklarını Giderme

Hosting sağlayıcınız arka planda sunucunun PHP sürümünü otomatik yükseltmiş olabilir. Bazı eski tema ve eklentiler PHP 8.1, 8.2 veya 8.3 ile fatal error verebilir.

• cPanel’e girip “MultiPHP Yöneticisi” veya “Select PHP Version” aracını açın.
• Domaininizi seçip PHP sürümünü bir alt stabil sürüme (örneğin PHP 8.1 veya 8.0) çekin ve “Uygula” deyin.
• Eğer site açıldıysa, sorun eskiyen bir eklentinizin modern PHP standartlarına ayak uyduramamasından kaynaklanmaktadır.

5. Adım: PHP Bellek Sınırını (WP_MEMORY_LIMIT) 256M veya 512M Yapma

Özellikle Elementor sayfa düzenleyici, WooCommerce veya Rank Math gibi kapsamlı araçlar aynı anda çalıştığında sunucunun RAM limiti yetersiz kalır ve bellek tükenmesi nedeniyle kritik hata tetiklenir.

wp-config.php dosyanıza şu kodları ekleyerek WordPress bellek limitini artırın:

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

Bu ayar, ağır sorguların sunucuyu kilitlemesini ve sayfa kaydederken oluşan kritik çökmeleri anında ortadan kaldırır.

6. Adım: Hatalı Tema ve functions.php Düzenlemelerini Geri Alma

Eğer eklentileri kapattığınız halde sorun devam ediyorsa, aktif temanızın functions.php dosyasına eklenen hatalı bir kod buna yol açıyor olabilir:

• FTP’de wp-content/themes/ klasörüne gidin.
• Kullandığınız aktif temanın klasör adının sonuna _eski ekleyin (Örn: meyricks_eski).
• WordPress aktif temayı bulamayınca otomatik olarak varsayılan Twenty Twenty-Four temasına geçiş yapar.
• Site açılıyorsa, temanızın dosyalarında yapılan son kod değişikliklerini geri almanız gerekmektedir.

Hata Türleri Karşılaştırma Tablosu: Hangi Hata Ne Anlama Gelir?

Gelişmiş Kullanıcılar İçin WP-CLI İle Tek Komutta Çözüm

Eğer sunucunuzda SSH (Terminal) erişiminiz varsa, sitenizi saniyeler içinde kurtarabilirsiniz:

# Tüm eklentileri tek tıkla pasife al
wp plugin deactivate --all

# Çekirdek WordPress dosyalarını orijinaliyle doğrula ve onar
wp core verify-checksums

# Bellek sınırını kontrol et
wp config get WP_MEMORY_LIMIT

Hata Çözüldükten Sonra Alınması Gereken Güvenlik Önlemleri

1. debug.log Dosyasını Silin: Hata günlüğü dosyanız veritabanı yollarını ve sunucu dizinlerinizi ifşa edebileceğinden işiniz bittiğinde mutlaka silin.
2. WP_DEBUG’ı Kapatın: wp-config.php dosyasındaki WP_DEBUG değerini tekrar false yapın.
3. Otomatik Yedekleme Kurun: UpdraftPlus gibi bir eklentiyle haftalık Google Drive yedeklemesi aktif edin.

Canlı Vaka Analizi: WooCommerce ve Önbellek Eklentisi Sonrası Çöküş

Kritik hataların pratikte nasıl ortaya çıktığını daha iyi kavramak için bizzat tecrübe ettiğimiz bir senaryoyu inceleyelim: Bir e-ticaret sitemizde WooCommerce son sürüme güncellendiğinde, sitede anında “Bu sitede kritik bir hata oluştu” uyarısı belirdi. wp-admin paneli de kilitlenmiş durumdaydı.

1. FTP üzerinden wp-config.php dosyasına define('WP_DEBUG', true); ve define('WP_DEBUG_LOG', true); satırları eklendi.
2. Site yenilendiğinde oluşan wp-content/debug.log dosyası açıldı.
3. Log dosyasında şunu gördük: “Fatal error: Uncaught Error: Call to undefined function wc_get_checkout_url() in /wp-content/plugins/eski-odeme-gecidi/gateway.php on line 78”
4. Sorunun kaynağı anlaşıldı: WooCommerce güncellenmiş ancak 4 yıldır güncellenmeyen eski bir sanal pos eklentisi WooCommerce’in artık tedavülden kalkan eski fonksiyonunu çağırıp fatal error veriyordu.
5. FTP’den eski-odeme-gecidi klasörünün adı eski-odeme-gecidi_deaktif yapıldı ve site 30 saniye içinde sorunsuz şekilde yeniden açıldı!

Veritabanı Tablolarını Onarma: Bozuk wp_options ve Transient Temizliği

Bazen sorun dosyalardan değil, veritabanındaki bozuk tablolardan kaynaklanabilir. Özellikle sunucu kesintisi veya MySQL çökmesi sırasında yazma işlemi yarıda kalırsa WordPress veritabanı kilitlenir.

Bunu otomatik onarmak için wp-config.php dosyasına şu satırı ekleyin:

define('WP_ALLOW_REPAIR', true);

Ardından tarayıcınızda https://siteadresiniz.com/wp-admin/maint/repair.php adresine gidin. Karşınıza çıkacak ekranda “Veritabanını Onar ve Optimize Et” butonuna tıklayın. İşlem tamamlandıktan sonra güvenlik amacıyla bu satırı wp-config.php dosyasından mutlaka kaldırın.

Kritik hatalar dışında sunucu kaynaklı genel kilitlenmeler için WordPress 500 Internal Server Error Çözümü ve bağlantı kopmaları için WordPress 404 Hatası Çözümü rehberlerimize de mutlaka göz atın.

Sıkça Sorulan Sorular (FAQ)