WordPress’te Beyaz Sayfa Hatası Nasıl Çözülür?

WordPress beyaz sayfa hatası (WSOD – White Screen of Death), sitenin hem ön yüzünü hem de yönetici panelini boş bir beyaz sayfaya dönüştüren, panik yaratan ancak çoğu zaman 5-10 dakikada çözülebilen klasik bir hatadır. Bu rehber, hatayı teşhis etmekten geri dönüş planına kadar uçtan uca ele alır; staging ortamı olmayan küçük sitelerden yüksek trafikli kurumsal WP’lere kadar aynı temel adımları izler.

Bu yazıdaki adımlar wp-config.php, .htaccess, wp-content/ ve PHP hata loglarını düzenleme yetkisi olan, en az 2 kez WSOD yaşamış ve çözmüş bir geliştiricinin deneyiminden derlenmiştir.

PHP Hatası ve Hata Ayıklama

Beyaz sayfa hatasının %70’i PHP seviyesinde bir ölümcül hatadan (fatal error) kaynaklanır. PHP, varsayılan olarak kritik hataları tarayıcıya yazdırmaz, sadece boş sayfa döner. Bu nedenle ilk adım her zaman hata raporlamayı açmaktır.

wp-config.php dosyasını FTP veya hosting dosya yöneticisi ile açın ve /* That's all, stop editing! Happy publishing. */ satırının hemen üstüne şu 3 satırı ekleyin:

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

Bu 3 sabit sırasıyla: hata raporlamayı açar, hataları /wp-content/debug.log dosyasına yazar, ekranda göstermez (kullanıcıların hata mesajı görmesini engeller). Tarayıcıyı yenilediğinizde hâlâ beyaz sayfa görüyorsanız ama debug.log dosyası içerik kazandıysa, sorunun köküne ulaşmışsınız demektir.

Log dosyasında sıklıkla karşılaşılan 4 tip hata vardır:

• Out of memory (Bellek yetersiz). Allowed memory size of 134217728 bytes exhausted mesajı görünür. Çözüm: wp-config.php‘ye define('WP_MEMORY_LIMIT', '256M'); satırı ekleyin veya hosting sağlayıcınızdan PHP bellek limitini artırmasını isteyin.
• Undefined function (Tanımsız fonksiyon). Bir eklenti veya tema, mevcut olmayan bir PHP fonksiyonunu çağırıyor demektir. Genellikle eklenti PHP sürümü uyumsuzluğu veya eklentinin tam yüklenmemiş olmasından kaynaklanır.
• Parse error (Sözdizimi hatası). functions.php veya bir eklenti dosyasında PHP kodlama hatası var demektir. Sıklıkla manuel kod düzenlemesi sonrası, eksik noktalı virgül veya yanlış kapanan süslü parantez nedeniyle oluşur.
• Cannot redeclare (Yeniden bildirim). Aynı fonksiyon iki kez tanımlanmaya çalışılıyor. Genellikle iki eklentinin aynı kütüphaneyi farklı isimle yüklemesinden kaynaklanır; birinin devre dışı bırakılması çözüm olabilir.

Debug.log dosyasını okumak için SSH erişiminiz varsa tail -f wp-content/debug.log komutu, dosya yöneticiniz varsa dosyayı doğrudan açabilirsiniz. Hata mesajındaki dosya yolu ve satır numarası, sorunun hangi dosyada olduğunu doğrudan gösterir.

Eklenti ve Tema Çakışma Kontrolü

Eğer debug.log dosyasında wp-content/plugins/ veya wp-content/themes/ ile başlayan bir hata varsa, sorun bir eklenti veya temadadır. Çakışma kaynağını izole etmek için tüm eklentileri geçici olarak devre dışı bırakın.

Ancak WP-Admin’e erişemiyorsanız, eklentileri dosya sistemi üzerinden devre dışı bırakmanız gerekir. FTP veya dosya yöneticisi ile /wp-content/ klasörüne gidin ve plugins klasörünün adını plugins_disabled olarak değiştirin. Bu, WP’nin tüm eklentileri tek seferde devre dışı bırakmasını sağlar. Site normale döndüyse sorun bir eklentidedir; eski haline getirip plugins klasörünün içine girerek eklentileri teker teker devre dışı bırakarak hangisinin suçlu olduğunu bulun.

Eklenti çakışması olmadığını tespit ettiyseniz, sıra temadadır. Aynı yöntemle wp-content/themes/ klasörüne gidin ve aktif temanın klasör adını değiştirin. WP otomatik olarak son çalışan temaya (örn. Twenty Twenty-Four) geri döner. Site normale döndüyse sorun temanızdır; tema dosyalarını son güncellemeden önceki yedeğe döndürmeniz veya tema sağlayıcınızla iletişime geçmeniz gerekir.

Çakışma bulma sürecinde sıklıkla yapılan 3 hatadan kaçının:

1. Tüm eklentileri aynı anda geri açmayın. Sorunu bulamazsınız. Her seferinde bir eklenti açıp site kontrol edin.
2. Cache eklentilerini son sıraya bırakın. WP Super Cache, W3 Total Cache gibi önbellek eklentileri pasif olsa bile disk üzerinde eski HTML dosyaları bırakabilir. Test sırasında wp-content/cache/ klasörünü de temizleyin.
3. Staging ortamı kullanmadan production’da deneme yapmayın. Eğer hosting sağlayıcınız staging desteği sunuyorsa, sorunu orada çözüp hazır çözümü canlıya uygulayın.

WP_DEBUG ve .htaccess Çözümleri

Wp Debug Htaccess Cozumleri

Bazı WSOD vakaları PHP hatasından değil, web sunucusu tarafında oluşur. Apache .htaccess dosyası bozulmuş, nginx rewrite kuralları çakışıyor veya PHP-FPM havuzu tükenmiş olabilir. Bu durumda wp-config.php hata raporlaması hiçbir şey göstermez çünkü hata PHP’ye ulaşmadan web sunucusu tarafından döndürülür.

Apache kullanıyorsanız .htaccess dosyasını geçici olarak yeniden adlandırın (örn. .htaccess.bak) ve siteye erişmeyi deneyin. WP, kök dizinde .htaccess bulamazsa otomatik olarak yeni bir tane oluşturur. Site normale döndüyse eski .htaccess dosyanızdaki kuralların bir kısmı bozuk demektir. WP’nin oluşturduğu yeni dosyayı temel alarak, eski dosyanızdaki özel kuralları (SSL yönlendirmesi, www -> www dışı yönlendirmesi, gzip, expires headers) teker teker geri ekleyin ve her ekleme sonrası site kontrolü yapın.

PHP sürüm uyumsuzluğu da sıklıkla gözden kaçar. WP 7.0, PHP 8.1+ gerektirir; eski sürümlerde ise PHP 7.4+ yeterlidir. Eğer yakın zamanda PHP sürümü güncellendiyseniz ve hemen ardından beyaz sayfa hatası aldıysanız, sorun PHP sürümü olabilir. Hosting kontrol panelinden (cPanel, Plesk veya özel panel) PHP sürümünü önceki kararlı sürüme (örn. 8.2’den 8.1’e) geri alıp test edin.

Son olarak, geri dönüş planı her zaman hazır olmalıdır. Her WP yükseltmesi, tema güncellemesi veya büyük eklenti değişikliği öncesinde:

• Veritabanını wp-cli ile veya phpMyAdmin üzerinden dışa aktarın.
• /wp-content/ klasörünün tam yedeğini alın (upload dizini büyük olabilir, sadece uploads/ ve themes/ da yeterli olabilir).
• wp-content/debug.log dosyasının temiz olduğundan emin olun; mevcut hatalar yeni hatalarla karışır.
• Yedekten geri dönüş süresini test edin. Yedek aldığınız sisteme gerçekten güvenebilmek için, staging’de bir kez geri yükleme testi yapın.

Sonuç

WordPress beyaz sayfa hatası, ilk bakışta çözümsüz görünür ancak sistematik bir yaklaşımla 10 dakika içinde kaynağına ulaşılabilir. Önce debug.log’u açın, sonra eklentileri, sonra temayı, sonra .htaccess’i test edin. Her adımda bir değişiklik yapıp siteye erişmeyi deneyin; sorunu izole etmenin en hızlı yolu budur. Geri dönüş planınız yoksa büyük değişiklik yapmayın; staging ortamı yoksa en azından bakım moduna alarak kullanıcıların boş sayfa görmesini engelleyin.