WordPress Beyaz Ekran Hatası (WSOD): Çözüm Rehberi

WordPress beyaz ekran hatası, bir sayfanın içinde tek karakter bile olmadan açılmasıdır. Ne hata mesajı vardır ne de ipucu. PHP kodu bir noktada çöker ve tarayıcıya gönderilecek bir şey kalmaz. Bu yazıda önce beyaz ekranı sıkça karıştırılan "kritik hata" ekranından ayırıyoruz, ardından sorunun sadece yönetim panelinde ya da sadece ön yüzde olmasına göre teşhis yolunu çiziyoruz. Çözüm adımları en az riskliden başlayıp çekirdek dosyalarını yenilemeye kadar gidiyor.

Beyaz ekran ile kritik hata ekranı arasındaki fark nedir?

WordPress 5.2 öncesinde ölümcül bir PHP hatası her zaman tamamen boş bir sayfa üretirdi. 5.2 ile gelen hata yakalama sistemi bu durumu çoğunlukla "Web sitenizde kritik bir hata oluştu" ekranına çevirdi ve yöneticiye e-posta atmaya başladı. Dolayısıyla güncel bir sitede gördüğünüz boş sayfa genellikle şu durumlardan birine işaret eder:

• Hata yakalayıcının kendisi de çalışamadı (örneğin hata çok erken, çekirdek yüklenmeden oluştu).
• Hata yakalama kapatılmış ya da bir eklenti tarafından geçersiz kılınmış.
• Sorun PHP dışında: sunucu zaman aşımı, bozuk .htaccess ya da önbellek katmanı boş yanıt dönüyor.
• Çok eski bir WordPress sürümü çalışıyor.

Kritik hata ekranı görüyorsanız doğrudan kritik hata rehberini izleyin, çünkü e-postadaki kurtarma bağlantısı işinizi bir adımda çözebilir. Aşağıdaki adımlar gerçek beyaz ekran içindir.

Beyaz ekran sadece yönetim panelinde mi, sadece ön yüzde mi?

Boş sayfanın nerede çıktığı, aramayı hızla daraltır. Önce hem ana sayfayı hem /wp-admin adresini hem de birkaç iç sayfayı deneyin.

Önce hatayı nasıl görünür kılarım?

Beyaz ekranın en büyük sorunu bilgi vermemesidir. Bunu wp-config.php dosyasında hata günlüğünü açarak çözün. Hataları ekrana yazdırmak yerine dosyaya kaydediyoruz, çünkü ziyaretçiye dosya yollarını göstermek istemeyiz.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Sayfayı yenileyin ve wp-content/debug.log dosyasını açın. "PHP Fatal error" satırındaki dosya yolu suçluyu gösterir. Günlük hiç oluşmuyorsa hata WordPress yüklenmeden önce ya da PHP seviyesinde oluşuyor demektir, o zaman hosting panelindeki PHP hata günlüğüne bakın. Ayarlar, günlüğün güvenliği ve satırların anlamı için WP_DEBUG rehberine göz atın. İşiniz bitince bu modu kapatmayı unutmayın.

Eklenti ve tema sorunu nasıl dışlanır?

Beyaz ekranın en yaygın kaynağı bir eklenti ya da temadır, özellikle bir güncellemenin ardından. FTP ya da hosting dosya yöneticisiyle şu sırayı izleyin:

1. 1wp-content/plugins klasörünü geçici olarak plugins-kapali yapın. Site açılırsa sorun bir eklentidir.
2. 2Klasörü eski adına döndürmeden önce wp-admin'de Eklentiler sayfasını (plugins.php) bir kez açın; WordPress eksik eklentileri etkin listeden ancak bu sayfa yüklendiğinde çıkarır, yoksa klasör geri adlandırılınca hepsi yeniden etkinleşir ve beyaz ekran geri döner. Sonra eklentileri panelden tek tek etkinleştirerek ya da klasör adlarını tek tek değiştirerek suçluyu bulun (ayrıntısı güncelleme sonrası site bozuldu rehberinde). Günlükte yol varsa doğrudan o eklentiyi kapatın.
3. 3Site hâlâ boşsa wp-content/themes içinde aktif temanın klasörünü yeniden adlandırın. WordPress yedek bir temaya geçmeyi dener. Yüklü ikinci bir tema yoksa varsayılan bir tema yükleyip deneyin.

Sorun bir eklenti güncellemesinden sonra başladıysa güncelleme sonrası site bozulduğunda ne yapılır sayfası ve eklenti güncellemesini geri alma yazısı doğrudan işinize yarar.

Bellek limitini nasıl artırırım?

Boş sayfa bazen sadece PHP'nin bellek sınırına çarpmasıdır. Günlükte "Allowed memory size exhausted" görüyorsanız wp-config.php dosyasına, /* That's all, stop editing! */ satırından önce şu sabitleri ekleyin:

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

WordPress belgelerine göre WP_MEMORY_LIMIT sitenin genel sınırıdır (tek sitede varsayılan 40 MB, multisite'ta 64 MB), WP_MAX_MEMORY_LIMIT ise yönetim ekranındaki ağır işler için ayrı bir sınır tanımlar. Hosting planı daha düşük bir PHP memory_limit koyuyorsa bu sabitler onu aşamaz, hostinginizden ayarı yükseltmesini isteyin. Sürekli bellek sınırına dayanıyorsanız artırmak sorunu ertelemekten öteye geçmez. Nedenini ağır bir eklentide aramalısınız.

Bozuk .htaccess ve çekirdek dosyaları nasıl düzeltilir?

Sunucu düzeyinde bir kural hatası boş yanıt ya da 500 üretebilir. .htaccess dosyasını .htaccess-eski olarak yeniden adlandırın ve siteyi açmayı deneyin. Açıldıysa Ayarlar > Kalıcı Bağlantılar'da Değişiklikleri Kaydet'e basarak dosyayı yeniden oluşturun. Standart bir WordPress kuralı şöyledir:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Bu da işe yaramazsa çekirdek dosyalarını yenileyin. WP-CLI ile içeriğinize dokunmadan çekirdeği yeniden indirebilirsiniz:

wp core verify-checksums
wp core download --force --skip-content

İlk komut hangi çekirdek dosyalarının resmi sağlama toplamından saptığını gösterir. İkincisi wp-content klasörünü ve wp-config.php dosyasını korur. SSH yoksa aynı sürümü wordpress.org'dan indirip wp-content ve wp-config.php hariç yükleyebilirsiniz.

Hata WordPress yüklenmeden önce oluşuyorsa ne yapmalıyım?

Günlük boş kalıyorsa ve boş sayfa değişmiyorsa üç şeyi kontrol edin. Birincisi wp-config.php: dosyanın başında <?php'den önce boşluk ya da görünmez karakter (BOM) olması, çıktıyı bozabilir ve en çok elle düzenlenmiş dosyalarda görülür. Dosyayı düz metin düzenleyicide BOM'suz kaydedin. İkincisi PHP sürümü: bir güncelleme sonrası hosting PHP sürümünü değiştirdiyse, eski bir eklenti yeni sürümde ölümcül hata verir. Hosting panelinden bir önceki sürüme dönüp denemek iyi bir testtir. Üçüncüsü sunucu zaman aşımıdır: çok uzun süren bir işlem (büyük bir içe aktarma, takılı kalmış bir cron görevi) yanıtın hiç üretilmemesine yol açabilir.

Tarayıcı geliştirici araçlarında Network sekmesinde ilk isteğe bakın. Durum kodu 500 ise sunucu hata vermiş, 200 ve boş gövde ise PHP sessizce çıkmış demektir. 502 ya da 504 görüyorsanız sorun uygulamada değil, sunucu ya da proxy katmanındadır. Hosting desteğine bu bilgiyi vermek çözümü hızlandırır.

Beyaz ekran tekrar etmesin diye ne yapabilirim?

Tekrarı önlemenin yolu, değişikliği riskli hale getiren alışkanlıkları ortadan kaldırmaktır. Güncellemeleri toplu ve yedeksiz uygulamayın. Her güncellemeden önce yedek alın, güncellemeleri tek tek uygulayın ve her adımdan sonra ön yüzü ile yönetim panelini açın. Canlı sitede kod düzenlemeyin: Görünüm > Tema Dosya Düzenleyici'den yapılan tek bir noktalı virgül hatası siteyi çökertebilir. Yapılandırma sorunlarını erken yakalamak için Site Sağlığı ekranındaki uyarıları da düzenli kontrol edin. Genel bakım rutininiz için güvenlik kontrol listesine göz atın.

Sık sorulan sorular

Beyaz ekran hatası verilerimi siler mi?

Hayır. Ölümcül hata kodun çalışmasını durdurur ama veritabanı ve dosyalar yerinde kalır. Veri kaybı riski, çözüm sırasında yanlış dosyayı silmek ya da üzerine yazmaktır, bu yüzden her müdahaleden önce yedek alın.

Beyaz ekran kendiliğinden geçti, endişelenmeli miyim?

Geçici boş ekranlar sunucu aşırı yüklenmesi, bellek yetersizliği ya da zaman aşımından olabilir. Tekrarlıyorsa günlüğe bakın. Tekrar etmesini beklemeden uptime izleme açmak, kesintilerin zamanını ve süresini kaydeder.

Sadece mobilde beyaz ekran görüyorum?

Mobil için ayrı sunulan önbellek ya da bir CDN kuralı bozuk yanıt veriyor olabilir. Önbelleği ve CDN önbelleğini temizleyin, sorun sürerse ilgili önbellek eklentisini dışlayın.

Hosting beyaz ekran çözmeye yardım eder mi?

Edebilir. Destek ekibi sunucu günlüğünden hatanın zamanını ve nedenini görebilir. Onlara hatanın başladığı saati ve son yaptığınız değişikliği söylerseniz süreç hızlanır.

• WordPress Developer Resources: wp-config.php (WP_MEMORY_LIMIT)
• WordPress Developer Resources: Debugging in WordPress
• WordPress Core: Fatal error recovery mode in 5.2
• WP-CLI: wp core download

Erdinç

Watch Your WP'yi geliştiriyor. WordPress bakım, güvenlik ve site yönetimi deneyiminden yazıyor.

LinkedIn