WordPress Beyaz Ekran Hatası: Adım Adım Teşhis ve Çözüm
Siteyi açıyorsunuz ve karşınıza bomboş beyaz bir sayfa geliyor. Kaynak kodunu görüntülediğinizde de neredeyse hiçbir şey yok. WordPress dünyasında bu duruma WSOD, yani “white screen of death” deniyor ve sebebi neredeyse her zaman aynı yerde: PHP bir ölümcül hata verdi, çıktı üretilmeden çalışma durdu, ekranda gösterilecek hiçbir şey kalmadı.
Bugünkü WordPress sürümleri çoğu durumda tamamen boş sayfa yerine “Bu sitede kritik bir hata oluştu” mesajını gösterir. İkisi de aynı arızanın iki farklı yüzüdür ve teşhis akışı ortaktır. Önemli olan, tahminle eklenti silmek yerine hatayı görünür kılmaktır.
Aşağıdaki sıra, hatayı en hızlı daraltan sıradır. Her adımdan sonra siteyi yenileyip durumu kontrol edin ve yaptığınız değişiklikleri not alın ki geri dönebilesiniz.
Önce ne değişti sorusunu sorun
Beyaz ekran kendiliğinden oluşmaz. Neredeyse her vakada dört sebepten biri vardır: yeni bir eklenti kuruldu ya da güncellendi, tema güncellendi veya kod eklendi, PHP sürümü değişti, ya da bellek limiti doldu. Arızadan hemen önce ne yaptığınızı hatırlıyorsanız teşhisin yarısı bitmiş demektir.
Beyaz ekranın panoda mı, ön yüzde mi, yoksa ikisinde birden mi olduğunu da belirleyin. Yalnızca ön yüz beyazsa şüphe temada veya ön yüzde çalışan bir eklentidedir. Yalnızca /wp-admin beyazsa yönetici tarafında çalışan bir eklenti akla gelir. İkisi de beyazsa sorun çekirdek dosyalarda, veritabanı bağlantısında ya da sunucu tarafındadır.
WP_DEBUG ile hatayı görünür kılın
Hatanın metnini görmeden ilerlemeyin. FTP veya cPanel Dosya Yöneticisi ile public_html/wp-config.php dosyasını açın ve /* That's all, stop editing! */ satırının üzerine şunları ekleyin: define('WP_DEBUG', true);, define('WP_DEBUG_LOG', true);, define('WP_DEBUG_DISPLAY', false);. Dosyada zaten WP_DEBUG tanımı varsa yenisini eklemek yerine false olan değeri true yapın.
Bu ayarla hata ziyaretçiye gösterilmez, wp-content/debug.log dosyasına yazılır. Siteyi bir kez yenileyin, sonra bu dosyayı açın. Aradığınız satır genelde şuna benzer: PHP Fatal error: Uncaught Error: Call to undefined function ... in /home/kullanici/public_html/wp-content/plugins/eklenti-adi/inc/ayar.php on line 214. Dosya yolu size suçluyu doğrudan söyler.
Sorun bittikten sonra WP_DEBUG değerini mutlaka false yapın ve debug.log dosyasını silin; içinde dosya yolları ve bazen sorgu ayrıntıları bulunur, açık bırakmak güvenlik açısından gereksiz bilgi sızdırır.
Sunucu error_log dosyasını okuyun
Bazı durumlarda WordPress hiç çalışamadığı için debug.log bile oluşmaz. O zaman sunucunun kendi kaydına bakın. cPanel’de iki yer var: Ölçümler > Hatalar ekranı son hataları listeler, ayrıca çoğu kurulumda public_html içinde ve alt klasörlerde error_log adlı dosyalar oluşur. Dosya Yöneticisi’nde “Gizli dosyaları göster” seçeneğini açıp bakın.
Burada göreceğiniz tipik satırlar: PHP Parse error: syntax error, unexpected '}' (bir dosyaya elle eklenen kod bozuk), Allowed memory size of 268435456 bytes exhausted (bellek limiti doldu), PHP Fatal error: Uncaught mysqli_sql_exception (veritabanı sorunu). Hata kodlarının genel karşılıklarını sunucu hata kodları yazısında bulabilirsiniz.
Eklentileri FTP’den toplu devre dışı bırakın
Panoya giremiyorsanız eklentileri dosya sistemi üzerinden kapatabilirsiniz. FTP ya da Dosya Yöneticisi ile public_html/wp-content/plugins klasörüne sağ tıklayıp adını plugins-kapali yapın. WordPress klasörü bulamayınca tüm eklentileri devre dışı sayar.
Site açıldıysa suçlu eklentilerden biridir. Şimdi klasörün adını plugins olarak geri alın; eklentilerin hepsi devre dışı olarak listelenmiş olacak. Panodan tek tek etkinleştirin, her etkinleştirmeden sonra ön yüzü yenileyin. Site hangi eklentide beyazlarsa sorumlu odur. Bu eklentiyi kaldırın, geliştiricisine bildirin veya eski sürümüne dönün.
- Klasörü silmeyin, yalnızca yeniden adlandırın; eklenti ayarları veritabanında durur, geri döndüğünüzde kaybolmaz.
- Tek bir eklentiden şüpheleniyorsanız tüm klasör yerine sadece o eklentinin klasörünü yeniden adlandırın.
- Bazı eklentiler
mu-pluginsklasöründe durur ve bu yöntemle kapanmaz; oraya da bakın.
Temayı varsayılana çevirin
Eklentiler kapalıyken site hâlâ beyazsa sıra temada. wp-content/themes klasörüne girin, aktif temanın klasör adını değiştirin (örneğin astra yerine astra-kapali). Klasörde twentytwentyfour gibi bir varsayılan tema varsa WordPress otomatik olarak ona düşer ve site açılır.
Varsayılan tema yoksa WordPress.org’dan indirip klasöre yükleyin. Site varsayılan temayla açılıyorsa sorun temanızın kodunda ya da functions.php dosyasına elle eklediğiniz bir parçadadır. En sık görülen sebep, internetten kopyalanıp functions.php sonuna yapıştırılan ve kapanış etiketinden sonraya düşen kod parçalarıdır.
PHP bellek limitini artırın
Bellek yetmediğinde WordPress çoğu zaman sessizce beyaz sayfa döner. Limiti üç yerden yükseltebilirsiniz. En kolayı wp-config.php içine define('WP_MEMORY_LIMIT', '256M'); satırını eklemektir. cPanel kullanıyorsanız Yazılım > PHP Sürümü Seç > Options sekmesinde memory_limit değerini 256M yapabilirsiniz. Üçüncü yol, php.ini dosyasına memory_limit = 256M yazmaktır.
| Site türü | Makul memory_limit | Not |
|---|---|---|
| Blog, tanıtım sitesi | 128M | Çoğu durumda fazlasıyla yeter |
| Orta ölçekli kurumsal | 256M | Sayfa oluşturucu kullanılıyorsa önerilir |
| WooCommerce | 256-512M | Toplu ürün içe aktarımında geçici artış gerekebilir |
512M üzerinde değerler sorunu çözmüyorsa mesele bellek değil, sonsuz döngüye giren bir koddur. Limiti sürekli yükseltmek yerine debug.log içindeki dosya yolunu takip edin.
Kurtarma modu e-postası
WordPress 5.2’den beri ölümcül hata yakalandığında yönetici e-posta adresine “Sitenizde teknik bir sorun var” başlıklı bir ileti gider. İçindeki bağlantı sizi kurtarma moduna sokar: sorunlu eklenti veya tema geçici olarak devre dışı bırakılmış bir panoya girersiniz ve hatanın hangi dosyada oluştuğu e-postanın içinde yazar.
E-posta gelmiyorsa iki ihtimal var. Birincisi, Ayarlar > Genel altındaki yönetici e-posta adresi artık kullanılmıyordur. İkincisi ve daha yaygını, sitenin PHP mail gönderimi çalışmıyordur. Bildirim e-postalarının neden ulaşmadığını e-posta ulaşmıyor teşhis yazısında ele alıyoruz; SMTP eklentisiyle gönderimi düzeltmek bu tür kritik bildirimleri de kurtarır.
Adım adım teşhis akışı
- Hata ön yüzde mi, panoda mı, ikisinde de mi? Not alın.
- Yönetici e-postasına gelen kurtarma modu iletisine bakın.
wp-config.phpiçindeWP_DEBUGveWP_DEBUG_LOGdeğerlerinitrueyapın, sayfayı yenileyin,wp-content/debug.logdosyasını okuyun.- Log yoksa cPanel’de
error_logdosyasına bakın. pluginsklasörünü yeniden adlandırın; site açılırsa eklentileri tek tek geri açın.- Hâlâ beyazsa aktif tema klasörünü yeniden adlandırın.
- Log’da bellek uyarısı varsa
WP_MEMORY_LIMITdeğerini 256M yapın. - Hiçbiri işe yaramazsa PHP sürümünü bir kademe geri alıp deneyin, sonra son sağlam yedeğe dönün.
- Sorun çözülünce
WP_DEBUGdeğerinifalseyapın vedebug.logdosyasını silin.
Özetle
- Beyaz ekran bir PHP ölümcül hatasıdır; tahmin etmeyin,
debug.logveyaerror_logile hatanın dosya yolunu okuyun. - Panoya giremiyorsanız
pluginsve tema klasörlerini yeniden adlandırarak devre dışı bırakabilirsiniz; klasörleri silmeyin. - Bellek uyarısı görüyorsanız
WP_MEMORY_LIMITdeğerini 256M yapın; sürekli artırmak sorunu gizler. - Kurtarma modu e-postası en hızlı yoldur, bu yüzden yönetici adresinin çalışır olması önemlidir.
- Hata giderildikten sonra hata ayıklama ayarlarını kapatın ve log dosyasını temizleyin.