WordPress Kritik Hata ve Beyaz Ekran Çözümü: Hata Ayıklama Modu

Sitenizi açtığınızda yalnızca "Sitenizde ciddi bir sorun çıktı." yazıyorsa (İngilizce kurulumlarda "There has been a critical error on this website") ya da sayfa tamamen bembeyaz geliyorsa, WordPress çalışırken bir PHP hatası oluşmuş ve sayfa yarıda kesilmiştir. İçeriğiniz kaybolmamıştır; hatayı veren eklentiyi, temayı veya ayarı bulup düzelttiğinizde site geri gelir. Bu rehberde WordPress kritik hata ve WordPress beyaz ekran sorununun nedenini hata ayıklama modu (WP_DEBUG) ile nasıl bulacağınızı, panele girebildiğiniz ve giremediğiniz durumlarda eklenti ve tema çakışmasını nasıl gidereceğinizi, PHP sürümü ve bellek sınırı kaynaklı hataları adım adım anlatıyoruz.

Ekran görüntüleri WordPress 7.1.4 Türkçe ve PHP 8.3 üzerinde, tarayıcıda çalışan resmi WordPress deneme ortamında, bilerek hata veren örnek bir eklentiyle alınmıştır. cPanel görüntüleri gerçek bir hesaptandır; kullanıcı adı maskelenmiştir.

---

Kritik Hata ve Beyaz Ekran Ne Demek?

WordPress 5.2'den bu yana ölümcül (fatal) bir PHP hatası oluştuğunda sayfayı boş bırakmak yerine aşağıdaki mesajı gösterir. Daha eski sürümlerde ya da hata WordPress yüklenmeden önce oluştuğunda aynı durum beyaz ekran olarak görünür.

En sık nedenler şunlardır:

• Bir eklenti veya tema güncellemesi yeni bir hata getirmiştir ya da başka bir eklentiyle çakışmaktadır.
• PHP sürümü değişmiştir ve eski bir eklenti veya tema yeni sürümle uyumsuzdur.
• PHP bellek sınırı yetmemiştir (Allowed memory size ... exhausted).
• Yarım kalmış bir güncelleme veya eksik yüklenmiş dosyalar vardır.
• functions.php gibi bir dosyada elle yapılan bir düzenlemede yazım hatası vardır.

Aşağıdaki adımların hepsinde işe yedek alarak başlayın. Henüz bir yedeğiniz yoksa cPanel'de dosyaları ve veritabanını indirmek birkaç dakika sürer; yöntem WordPress yedek alma rehberimizde.

---

Adım 1: Kurtarma Modu E-postasına Bakın

WordPress kritik bir hata yakaladığında, hatayı veren eklentiyi veya temayı bulmaya çalışır ve sitenin yönetici e-posta adresine bir bağlantı gönderir. Bu bağlantı sizi kurtarma modunda panele sokar: hatalı eklenti yalnızca sizin oturumunuz için duraklatılır, siz de onu panelden etkisizleştirebilirsiniz. Ziyaretçiler bu sırada hâlâ hata ekranını görür.

E-posta gelmediyse iki olasılık vardır: ya yönetici e-posta adresi eskidir ya da site e-posta gönderemiyordur. Birçok paylaşımlı hosting sunucusunda PHP mail() işlevi kapalı olduğundan, SMTP ayarı yapılmamış sitelerde bu e-posta hiç gönderilmez. Böyle bir durumda aşağıdaki adımlarla devam edin.

---

Adım 2: Hata Ayıklama Modunu Açın ve Hatayı Okuyun

Hangi dosyanın hata verdiğini tahmin etmek yerine WordPress'e söyletin.

1. cPanel'de Dosya Yöneticisi'ni açın, sitenizin klasöründeki wp-config.php dosyasını seçip Düzenle'ye tıklayın.
2. Dosyada define( 'WP_DEBUG', false ); satırını bulun ve false değerini true yapın.
3. Hemen altına aşağıdaki satırları ekleyin. Hepsinin /* Hepsi bu kadar. Mutlu bloglamalar! */ yorumundan önce olması gerekir (İngilizce kurulumlarda bu satır /* That's all, stop editing! */ olarak geçer).

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

4. Kaydedin ve sitenizi bir kez yenileyin. Hata yeniden oluşur, ama bu kez wp-content/debug.log dosyasına yazılır.
5. Dosya Yöneticisi'nde wp-content klasöründeki debug.log dosyasını açın ve en alttaki PHP Fatal error satırını okuyun.

Satırda in kelimesinden sonra gelen yol, hatanın kaynağını gösterir:

• .../wp-content/plugins/eklenti-adi/... ise sorun o eklentidedir.
• .../wp-content/themes/tema-adi/... ise sorun temadadır.
• .../wp-includes/... veya .../wp-admin/... ise çekirdek dosyalar eksik ya da bozuk olabilir; yığın izinde (Stack trace) adı geçen eklentiye de bakın.
• Allowed memory size of ... bytes exhausted ise bellek sınırı yetmemiştir.

WP_DEBUG_DISPLAY değerini false yapmamızın nedeni şudur: bu ayar açık kalırsa aynı hata, sunucudaki dosya yollarıyla birlikte her ziyaretçinin ekranına yazılır. Bu bilgi saldırganların işine yarar.

Sorunu çözdükten sonra WP_DEBUG değerini yeniden false yapın ve debug.log dosyasını silin. Bu dosya wp-content içinde durduğu için tarayıcıdan indirilebilir ve sitenizin yapısıyla ilgili bilgi verir; WordPress'in Site sağlığı ekranı da bunu ciddi bir güvenlik sorunu olarak işaretler.

---

Adım 3: Hatalı Eklentiyi Devre Dışı Bırakın

Panele girebiliyorsanız

Hata yalnızca sitenin ön yüzündeyse panel çoğunlukla açılır. Eklentiler > Kurulu eklentiler sayfasında debug.log dosyasında adı geçen eklentinin altındaki Etkisizleştir bağlantısına tıklayın ve sitenizi yeniden açın.

Panele giremiyorsanız: klasör adını değiştirin

WordPress, klasörünü bulamadığı eklentiyi kendiliğinden etkisizleştirir.

1. Dosya Yöneticisi'nde public_html/wp-content/plugins klasörüne gidin.
2. Hatalı eklentinin klasörünü seçin, Yeniden Adlandır ile adının sonuna -kapali ekleyin (örneğin ornek-eklenti-kapali).
3. Siteyi yenileyin. Açıldıysa sorun bu eklentidir. Klasörün adını eski hâline getirmeyin; eklentiyi güncelleyin, geliştiricisine bildirin ya da bir alternatifini kullanın.

Hangi eklenti olduğunu bilmiyorsanız plugins klasörünün tamamının adını plugins-kapali yapın. Site açılırsa sorun eklentilerdedir. Klasörü yeniden plugins yapın (eklentiler bu sırada etkisiz duruma geçmiş olur), sonra panelden eklentileri teker teker etkinleştirip her seferinde siteyi kontrol edin. Hata yeniden çıktığında son etkinleştirdiğiniz eklenti sorunludur.

VDS'te WP-CLI ile

wp plugin list --status=active
wp plugin deactivate ornek-eklenti
wp plugin deactivate --all

WP-CLI de aynı hatayla durursa komuta --skip-plugins --skip-themes ekleyerek eklentileri ve temayı yüklemeden çalıştırabilirsiniz.

---

Adım 4: Tema Kaynaklı Hatalar

debug.log hatanın wp-content/themes/... altındaki bir dosyadan geldiğini söylüyorsa:

1. Panele girebiliyorsanız Görünüm > Temalar sayfasından WordPress'in kendi varsayılan temalarından birini (adı "Twenty" ile başlayan temalar) etkinleştirin.
2. Panele giremiyorsanız Dosya Yöneticisi'nde wp-content/themes içindeki etkin temanın klasör adını değiştirin. WordPress yüklü başka bir temaya geçer; yüklü varsayılan tema yoksa wordpress.org'dan indirip aynı klasöre yükleyin.
3. Hata functions.php dosyasında elle yaptığınız bir değişiklikten sonra başladıysa o değişikliği geri alın. Tema dosyalarını panelin dosya düzenleyicisinden değiştirmek yerine bir alt tema (child theme) kullanın.

---

Adım 5: PHP Sürümü Uyumsuzluğu

Hata, PHP sürümünü yükselttikten hemen sonra başladıysa ve debug.log içinde Call to undefined function, Deprecated veya Uncaught TypeError gibi satırlar eklenti ya da tema dosyalarını gösteriyorsa, o yazılım yeni PHP sürümüne uyumlu değildir.

1. cPanel'de MultiPHP Yöneticisi'ni açın, alan adınızı işaretleyin ve bir önceki PHP sürümünü seçip Uygula'ya tıklayın. Site genellikle hemen açılır.
2. Ardından sorunlu eklentinin veya temanın güncellemesini yapın. Güncelleme yoksa uzun süredir bakım almayan bu yazılımın yerine güncel bir alternatif seçin.
3. Güncellemeden sonra PHP sürümünü yeniden yükseltin. Destek süresi bitmiş sürümlerde (PHP 7.4 ve 8.0) kalıcı olarak kalmayın.

---

Adım 6: Bellek Sınırı Hatası

Allowed memory size of 41943040 bytes exhausted gibi bir satır görüyorsanız WordPress'in kendisine ayırdığı bellek yetmemiştir. WordPress varsayılan olarak tek bir site için 40 MB ister. wp-config.php dosyasına şu satırı ekleyin:

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

Bu değer sunucunun PHP memory_limit ayarını aşamaz. cPanel'de MultiPHP INI Düzenleyicisi ile memory_limit değerini kontrol edebilirsiniz. Bellek hatası sürekli tekrar ediyorsa asıl neden genellikle çok fazla bellek kullanan bir eklentidir; sınırı yükseltmek yerine o eklentiyi bulmak daha kalıcı bir çözümdür. WooCommerce gibi ağır siteler için hesabınızın RAM kaynağı da yetmiyor olabilir; bu durumda bir üst pakete geçmek gerekir.

---

Adım 7: Çekirdek Dosyaları ve .htaccess

• Yarım kalmış bir güncellemeden sonra site kök klasöründe .maintenance adlı bir dosya kalabilir ve site sürekli bakım modunda olduğunu söyleyen bir mesaj gösterir. Dosyayı silin.
• Çekirdek dosyalar bozulduysa wordpress.org'dan aynı sürümü indirin ve wp-admin ile wp-includes klasörlerini yenileriyle değiştirin. wp-content klasörüne ve wp-config.php dosyasına dokunmayın. VDS'te wp core verify-checksums komutu değişmiş çekirdek dosyalarını listeler.
• 500 hatası alıyorsanız .htaccess dosyasının adını .htaccess-eski yapıp deneyin. Site açılırsa panelde Ayarlar > Kalıcı bağlantılar sayfasında Değişiklikleri kaydet'e tıklayarak temiz bir .htaccess oluşturun.

---

En Sık Hatalar

1. WP_DEBUG satırını iki kez yazmak. Dosyada zaten bir WP_DEBUG satırı vardır; yenisini eklemek yerine mevcut olanı değiştirin. Aynı sabiti iki kez tanımlamak ayrı bir uyarıya neden olur.
2. Satırları "Hepsi bu kadar" yorumundan sonra eklemek. Bu durumda ayarlar etkisiz kalır.
3. Hata ayıklamayı açık unutmak. debug.log büyür, diski doldurur ve herkes tarafından indirilebilir.
4. Hatalı eklentiyi silip yeniden kurmak. Aynı sürüm aynı hatayı verir; önce güncellemeyi ya da uyumluluğu kontrol edin.
5. Yedek almadan dosya silmek. Eklenti klasörünü silmek yerine adını değiştirin; böylece ayarları ve dosyaları kaybetmezsiniz.
6. Korsan (nulled) tema veya eklenti kullanmak. Bu dosyalar güncelleme alamaz, sıklıkla hata verir ve çoğu zaman zararlı kod içerir. Kritik hatanın kaynağı böyle bir dosyaysa onu kaldırıp lisanslı sürümünü kullanın.

---

Özet

1. Önce yönetici e-postanıza gelen kurtarma modu bağlantısına bakın.
2. WP_DEBUG ve WP_DEBUG_LOG değerlerini açın, WP_DEBUG_DISPLAY değerini kapalı tutun ve wp-content/debug.log dosyasındaki son Fatal error satırını okuyun.
3. Hata bir eklentideyse panelden etkisizleştirin ya da klasör adını değiştirin; temadaysa varsayılan temaya geçin.
4. PHP sürümü değiştiyse bir önceki sürüme dönüp yazılımı güncelleyin; bellek hatasında WP_MEMORY_LIMIT değerini artırın.
5. İşiniz bitince hata ayıklamayı kapatın ve debug.log dosyasını silin.

Yazının konusu olmayan bir hata görüyorsanız ilgili rehberlerimize bakın: veritabanı bağlantı hatası, şifre sıfırlama ve wp-admin giriş sorunları, WordPress kurulumu. PHP sürümünü panelden seçebileceğiniz, LiteSpeed ve NVMe SSD altyapılı paketler için web hosting, kaynakları yalnızca size ayrılmış bir sunucu için VDS sunucu sayfamızı inceleyebilirsiniz. AnkSOFT'ta barındırılan sitenizde hata sürüyorsa debug.log dosyasındaki son hata satırını ekleyerek destek talebi açın.

---

Kaynaklar

• Debugging in WordPress (WordPress Developer Resources): WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY
• Fatal Error Recovery Mode in 5.2 (Make WordPress Core): kurtarma modu
• Editing wp-config.php: WP_MEMORY_LIMIT
• WordPress sunucu gereksinimleri
• cPanel MultiPHP Manager belgesi