WordPress Beyaz Ölüm Ekranı Nedir, Nasıl Çözülür

Beyaz ölüm ekranı, göremediğiniz bir PHP fatal hatasıdır. WordPress render’ın ortasında kurtarılamaz bir hataya düştü, PHP durdu ve production sunucularında hata gösterimi kapalı olduğu için sayfa, nedenini yazdırmak yerine boş döndü. Çözüm neredeyse hiçbir zaman tahmin işi değildir: debug log’u açın, wp-content/debug.log dosyasını açın ve son fatal satırını okuyun. O satır, tam olarak hangi dosyanın sorumlu olduğunu söyler — neredeyse her zaman bir eklenti ya da tema — ve o tek satır, çözümün kendisidir.

Ekran neden boş

PHP’nin display_errors adında bir ayarı vardır. Geliştirme makinesinde genellikle açıktır, bu yüzden bir fatal hata ekrana bir stack trace yazdırır. Gerçek bir sunucuda ise varsayılan olarak kapalıdır, çünkü dosya yollarını ve hataları ziyaretçilere sızdırmak bir güvenlik sorunudur. Yani bir şey fatal hata fırlattığında — artık var olmayan bir fonksiyona yapılan çağrı, yüklenmemiş bir sınıf, bir eklenti güncellemesindeki söz dizimi hatası — PHP çöker ve hiçbir şey göndermez. Tarayıcınız boş bir doküman render eder. İşte “beyaz ekran” budur.

WordPress 5.2’den beri bunları yakalamaya çalışan bir fatal hata işleyicisi (WP_Fatal_Error_Handler) vardır. Çalıştığında boş bir sayfa görmezsiniz — “web sitenizde kritik bir hata oluştu” mesajını görürsünüz, ayrıca yönetici adresine çoğu zaman gerçek hatayı ve Kurtarma Modu’na (Recovery Mode) giden bir bağlantı içeren bir e-posta gider. Gerçekten boş bir ekran genellikle hatanın, bu işleyici çalışamadan tetiklendiği anlamına gelir: bir parse/söz dizimi hatası (derleme aşamasında yakalanır), bozuk bir must-use eklentisi ya da aktif temanın functions.php dosyasındaki bir fatal. Her iki durumda da neden bir yere yazılmıştır. Sizin tek yapmanız gereken, yazma işlemini açmaktır.

Sırayla çözün

1. Log’u açın. SFTP üzerinden wp-config.php dosyasını düzenleyin ve /* That's all, stop editing! */ satırının üstüne şunu ekleyin:

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

WP_DEBUG_DISPLAY false değeri hataları genel sayfadan uzak tutarken WP_DEBUG_LOG onları wp-content/debug.log dosyasına yazar. Yeni bir kayıt oluşturmak için bozuk sayfayı bir kez yeniden yükleyin.

2. Son fatal’ı okuyun. wp-content/debug.log dosyasını açın ve en alta bakın:

tail -n 30 wp-content/debug.log

Şuna benzer bir satır arıyorsunuz:

[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, suçluyu adıyla söyler: plugins/some-addon. İşte cevabınız bu. Trace uzunsa veya mesaj anlaşılmazsa (Allowed memory size exhausted, Cannot redeclare, tanımadığınız bir sınıf adı), bunu hata log çözücümüze yapıştırın — gürültüyü ayıklar, yolun hangi eklentiyi ya da temayı işaret ettiğini söyler ve o belirli hata türünün ne anlama geldiğini açıklar.

3. Adı geçen bileşeni devre dışı bırakın. /wp-admin’e erişemezsiniz, o yüzden bunu SFTP üzerinden yapın. Sorunlu eklentinin klasörünü yeniden adlandırın, ör. some-addon → some-addon.off. WordPress bulamadığı bir klasörü yükleyemez, dolayısıyla eklentiyi devre dışı bırakır ve site geri gelir. Log temanızı işaret ediyorsa, aktif tema klasörünü yeniden adlandırarak varsayılan bir temaya geçin — WordPress paketlenmiş bir twentytwentysomething temasına geri döner.

4. Log yazılmıyorsa, ya wp-content yazılabilir değildir ya da hata sunucu düzeyindedir. Bunun yerine sunucunun PHP hata log’una bakın:

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

Aynı bilgi, farklı bir dosya. cPanel/Apache yığınları çoğu zaman site kök dizinine ya da hatalı dizine bir error_log bırakır.

Yapılmaması gerekenler

Sadece bellek limitini artırmayın. İnternette en çok tekrarlanan tavsiye, WP_MEMORY_LIMIT değerini 256M ya da 512M’ye çıkarmaktır. Bu, WSOD’yi yalnızca log gerçekten Allowed memory size of N bytes exhausted diyorsa çözer. Hata Call to undefined function ise, daha fazla bellek hiçbir işe yaramaz — rastgele bir ayarı değiştirdiniz ve ekran hâlâ beyaz. Önce log’u okuyun, sonra yalnızca sorun gerçekten bellekse belleği artırın.

Önbelleğinizi temizleyip bunu bir teşhis saymayın. Beyaz ekran, herhangi bir HTML var olmadan önce PHP’nin sunucuda çökmesidir. Bayat bir önbelleğe alınmış varlık, boş bir dokümana neden olamaz. (Bozuk bir önbellek eklentisi neden olabilir — ama log onu adıyla söyler, ki mesele de budur.)

WordPress çekirdeğini düzenlemeyin ya da yeniden kurmayın. Fatal neredeyse hiçbir zaman wp-includes ya da wp-admin içinde değildir; log’un işaret ettiği eklenti ya da temadadır. Çekirdeği yeniden kurmak yavaş, riskli ve doğrulamadığınız bir belirtiyi tedavi etmektir.

Tüm eklentileri kapatıp körlemesine tek tek yeniden açmayın. İkiye bölme (bisecting) yöntemi işe yarar ama yavaş yoldur. Log, tek adımda tam olarak hangi klasör olduğunu söyler. “Her şeyi kapat” yöntemine yalnızca okunabilir hiçbir hata olmadığında başvurun.

Production’da display_errors’ı açık bırakmayın. Site geri geldikten sonra debug tanımlarını kaldırın (ya da WP_DEBUG değerini tekrar false yapın). Ziyaretçilere yazdırılan hatalar, dosya yollarınızı açığa çıkarır.

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

Log bir eklentiyi işaret ediyor ama onu devre dışı bırakmak ekranı temizlemiyorsa, ilkinin altında ikinci bir fatal vardır — log’u tekrar açın ve yeni son satırı okuyun; fatal’lar üst üste yığılır. Mesajın kendisi duvar ise, onu hata log çözücüsüne bırakın ve hata türünü ile dosya yolunu sizin için çevirmesine izin verin. Beyaz ekran, yalnızca log kapalıyken bir gizem olarak kalır.