WordPress beyaz ekran hatası, ziyaretçinin veya yöneticinin içerik yerine tamamen boş bir sayfa görmesidir. Hata bazen yalnızca yönetim panelinde, yalnızca belirli bir sayfada ya da sitenin tamamında ortaya çıkar. Çoğu vakada neden; hatalı bir eklenti veya tema güncellemesi, PHP ölümcül hatası, yetersiz bellek limiti, bozuk önbellek ya da uyumsuz PHP sürümüdür. Boş ekran, hatanın kendisini gizlediğinden rastgele dosya değiştirmek yerine log odaklı ilerlemek gerekir. Bu rehberde WordPress beyaz ekran hatasını güvenli biçimde izole etmeyi, geri dönüş planı hazırlamayı ve sorunu kalıcı olarak çözmeyi öğreneceksiniz.
Belirti ve kapsamı belirleyin
İlk olarak sorunun sınırını belirleyin. Bu ayrım, doğru teşhis adımını seçmenizi sağlar:
- Tüm site ve /wp-admin boş: PHP ölümcül hatası, etkin tema, zorunlu eklenti, PHP-FPM sorunu veya bellek limiti olasılığı yüksektir.
- Ön yüz boş, yönetim paneli açılıyor: Tema, sayfa oluşturucu, şablon dosyası, önbellek veya yalnızca ön yüzde çalışan eklentiler incelenmelidir.
- Yalnızca /wp-admin boş: Yönetim eklentisi, oturum/cookie sorunu, tarayıcı önbelleği ya da yönetim tarafındaki bir PHP hatası söz konusu olabilir.
- Tek bir yazı veya sayfa boş: İlgili şablon, kısa kod, blok, özel alan verisi veya o sayfada çalışan eklenti sorgulanmalıdır.
- Güncelleme sonrası başladı: Son güncellenen eklenti, tema, WordPress çekirdeği veya PHP sürümü öncelikli şüphelidir.
Önce farklı bir tarayıcıda veya gizli sekmede kontrol yapın. Varsa CDN ve sunucu önbelleğini henüz kalıcı olarak silmeden, sorunun oturum açmış kullanıcıya mı yoksa herkese mi göründüğünü not edin.
WordPress beyaz ekran hatası için hızlı teşhis özeti
| Kontrol | Ne gösterir? | İlk güvenli işlem |
|---|---|---|
| PHP hata günlüğü | Ölümcül hata, dosya ve satır numarası | Logu okuyun; hatalı bileşeni devre dışı bırakın. |
| Eklentiler | Uyumsuz veya bozuk eklenti | Tüm eklentileri geçici olarak kapatıp tek tek açın. |
| Etkin tema | Tema veya child theme hatası | Varsayılan bir WordPress temasına geçin. |
| PHP bellek limiti | Bellek taşması | Logla doğrulayın, limiti hosting politikasına uygun artırın. |
| PHP sürümü | Eklenti/tema uyumluluğu | Staging ortamında desteklenen sürümle test edin. |
| Dosya ve disk durumu | Eksik dosya, izin veya dolu disk | Disk alanını ve sahipliği kontrol edin. |
İşlemden önce yedek ve bakım penceresi
Eklenti veya tema klasörünü yeniden adlandırmak, PHP sürümünü değiştirmek, çekirdek dosyalarını yenilemek ya da veritabanında işlem yapmak sitenin davranışını değiştirebilir. Canlı sitede çalışmadan önce dosyaların ve veritabanının geri yüklenebilir yedeğini alın. Yoğun trafik alan sitelerde bakım penceresi planlayın. Mümkünse aynı PHP sürümü ve benzer yapılandırmayla hazırlanmış bir staging kopyasında test edin.
SSH erişiminiz varsa WordPress kök dizininde temel dosya envanterini ve boş alanı kaydedebilirsiniz. Aşağıdaki komutlarda /var/www/example.com/public örnek yoldur; kendi gerçek WordPress kök dizininizle değiştirin.
cd /var/www/example.com/public
pwd
wp core version --allow-root
df -h .
wp komutu ancak WP-CLI kuruluysa çalışır. Paylaşımlı hosting veya cPanel hesaplarında Dosya Yöneticisi ve paneldeki yedekleme araçları kullanılabilir. --allow-root parametresini yalnızca komutu gerçekten root kullanıcısıyla çalıştırmanız gerekiyorsa ekleyin.
Hata kaydını görünür hâle getirin
WordPress debug kaydını geçici olarak etkinleştirin
En değerli bulgu, PHP’nin ürettiği gerçek hata mesajıdır. wp-config.php dosyasında “That’s all, stop editing!” satırından önce aşağıdaki sabitleri ekleyin veya mevcut değerlerini geçici olarak değiştirin:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
Bu yapılandırma hataları ziyaretçiye göstermeden wp-content/debug.log dosyasına yazmayı amaçlar. Sayfayı bir kez yenileyin ve logun son satırlarını inceleyin:
tail -n 100 /var/www/example.com/public/wp-content/debug.log
Özellikle PHP Fatal error, Uncaught Error, Allowed memory size exhausted, Call to undefined function ve Class not found ifadelerine bakın. Mesajdaki dosya yolu genellikle sorunlu eklentiyi, temayı veya özel kodu gösterir. Hata ayıklama bittikten sonra üretim ortamında logun gereksiz büyümesini önlemek için WP_DEBUG değerini tekrar false yapın.
Sunucu günlüklerini kontrol edin
debug.log oluşmuyorsa hata WordPress başlamadan önce meydana geliyor olabilir. Web sunucusu ve PHP-FPM günlükleri bu durumda daha faydalıdır. Günlük yolu dağıtıma ve PHP çalıştırma yöntemine göre değişir. Debian/Ubuntu sistemlerinde sık görülen günlükleri aşağıdaki gibi kontrol edebilirsiniz; dosya mevcut değilse panelinizdeki Error Log ekranını veya sisteminizde tanımlı günlük yolunu kullanın.
sudo journalctl -u php8.2-fpm --since "30 minutes ago" --no-pager
sudo tail -n 100 /var/log/apache2/error.log
sudo tail -n 100 /var/log/nginx/error.log
Buradaki php8.2-fpm servis adını kurulu PHP sürümünüze göre değiştirin. cPanel/WHM, Plesk veya yönetimli hosting ortamlarında servis günlükleri farklı konumda tutulabilir; servisleri rastgele yeniden başlatmak yerine önce paneldeki hata günlüğünü ve kaynak kullanımını inceleyin.
Olası nedenlere göre güvenli adım adım çözüm
1. Eklenti çakışmasını izole edin
Log belirli bir eklentiyi işaret ediyorsa önce yalnızca o eklentiyi devre dışı bırakın. Yönetim paneli erişilemiyorsa FTP, SFTP, Dosya Yöneticisi veya SSH ile wp-content/plugins altındaki ilgili eklenti klasörünün adını değiştirin. Örneğin:
cd /var/www/example.com/public/wp-content/plugins
mv sorunlu-eklenti sorunlu-eklenti.disabled
Hata kaydı net değilse tüm eklentileri tek seferde izole edin. plugins klasörünü yeniden adlandırmak WordPress’in eklentileri görememesini sağlar; veritabanındaki eklenti ayarlarını silmez.
cd /var/www/example.com/public/wp-content
mv plugins plugins.disabled
Site açılırsa boş bir plugins klasörü oluşturun veya eski klasörü geri adlandırıp eklentileri yönetim panelinden ya da klasör bazında sırayla etkinleştirin. Hata geri geldiğinde son etkinleştirilen eklenti adaydır. Eklentiyi güncelleyin, uyumlu sürümüne dönün veya geliştiricisinden PHP sürümü uyumluluğunu teyit edin.
2. Temayı varsayılan tema ile test edin
Ön yüz boş, fakat eklentiler kapalıyken durum değişmiyorsa etkin temayı kontrol edin. Yönetim panelinden geçici olarak kurulu bir varsayılan WordPress temasına geçin. Panel erişimi yoksa etkin tema klasörünü yeniden adlandırabilirsiniz:
cd /var/www/example.com/public/wp-content/themes
mv ozel-tema ozel-tema.disabled
WordPress’in geçiş yapabilmesi için twentytwentyfour gibi uyumlu bir varsayılan temanın sunucuda kurulu olması gerekir. Bu tema mevcut değilse önce dosyalarını güvenilir WordPress kaynağından sağlayın. Child theme kullanılıyorsa ana temanın eksik, güncel olmayan veya uyumsuz olmaması da kontrol edilmelidir.
3. PHP bellek taşmasını düzeltin
Logda Allowed memory size exhausted görülüyorsa sorun bellek limitidir; ancak sadece limiti yükseltmek hatalı veya sonsuz döngüye giren kodu çözmez. Önce hangi eklenti ya da işlem sırasında taşma olduğunu belirleyin. Hosting izin veriyorsa wp-config.php dosyasına, yorum satırı olmayan erken bir bölüme şu tanımı ekleyebilirsiniz:
define( 'WP_MEMORY_LIMIT', '256M' );
Yönetim işlemleri için bazı kurulumlar WP_MAX_MEMORY_LIMIT kullanır; fakat PHP’nin sunucu tarafındaki memory_limit değeri daha düşükse WordPress bunu aşamaz. cPanel MultiPHP INI Editor, Plesk PHP Settings veya PHP-FPM havuz yapılandırmasındaki gerçek limiti yetkili kullanıcıyla kontrol edin. Limit değişikliğini bakım penceresinde uygulayın ve sonrasında hata logunu yeniden inceleyin.
4. PHP sürümü ve eksik uzantıları doğrulayın
PHP sürümü değişiminden sonra başlayan beyaz ekran, eski eklenti veya temadaki uyumsuz fonksiyon kullanımından kaynaklanabilir. Logda “undefined function”, “deprecated” sonrası ölümcül hata veya sözdizimi hatası görülüyorsa önce ilgili bileşenin desteklediği PHP sürümünü doğrulayın. Canlı ortamda doğrudan eski PHP sürümüne dönmek güvenlik riski yaratabilir. Önce staging ortamında test edin; kalıcı çözüm olarak WordPress, tema ve eklentileri desteklenen güncel sürümlerde tutun.
Komut satırında PHP sürümünü ve yüklü uzantıları kontrol etmek için:
php -v
php -m | sort
CLI PHP sürümü ile web sunucusunun kullandığı PHP sürümü farklı olabilir. Bu nedenle panelde alan adına atanmış PHP sürümünü de mutlaka kontrol edin.
5. Önbelleği ve dosya bütünlüğünü değerlendirin
Özellikle güncelleme veya taşıma sonrasında eski sayfa önbelleği, object cache ya da eksik çekirdek dosyaları sorun çıkarabilir. Önce eklenti/CDN kontrol panelinden önbelleği temizleyin. Kalıcı nesne önbelleği kullanılıyorsa, yapılandırmasını değiştirmeden önce hangi eklentinin yönettiğini doğrulayın.
WP-CLI mevcutsa çekirdek dosyalarının sağlama kontrolü yapılabilir:
cd /var/www/example.com/public
wp core verify-checksums --allow-root
Bu komut çekirdek dosyalarındaki farkları listeler; tema ve eklenti dosyalarını doğrulamaz. Çekirdek dosyaları eksik veya değiştirilmişse, veritabanına ve wp-content dizinine dokunmadan aynı WordPress sürümünün temiz paketinden çekirdek dosyaları yeniden yüklemek değerlendirilebilir. Öncesinde tam yedek alın.
Çözümü doğrulama ve güvenli geri dönüş
Bir değişiklikten sonra yalnızca ana sayfayı değil, giriş yapmamış tarayıcıyla ana sayfayı, birkaç içerik sayfasını, iletişim formunu ve /wp-admin/ yolunu test edin. PHP hata günlüğünde yeni ölümcül hata oluşmadığını kontrol edin. Eklentileri yeniden etkinleştirirken her adımda testi tekrarlayın; böylece sorunlu bileşeni kesin olarak ayırabilirsiniz.
Sorun çözülünce geçici olarak açtığınız debug ayarlarını kapatın, yeniden adlandırılan klasörleri normal adına döndürün ve gereksiz test dosyalarını silin. Beyaz ekran devam ediyorsa, aldığınız yedekten staging ortamına dönüş testi yapın. Canlı veritabanını eski yedekle geri yüklemek veri kaybına yol açabileceğinden, geri dönüşten önce son sipariş, form ve içerik değişikliklerini değerlendirin.
WordPress beyaz ekran hatasını önleme
- WordPress çekirdeği, tema ve eklenti güncellemelerini önce staging ortamında deneyin.
- Otomatik veya manuel güncellemeden önce geri yükleme testi yapılmış dosya ve veritabanı yedeği bulundurun.
- Gereksiz, terk edilmiş veya lisanssız eklenti ve temaları kaldırın.
- PHP sürümü yükseltmeden önce tüm aktif bileşenlerin uyumluluğunu kontrol edin.
- Disk alanı, PHP hata logları ve kaynak tüketimi için düzenli izleme uygulayın.
- Özel tema veya eklenti geliştirmelerinde hata kayıtlarını üretimde ziyaretçiye göstermeyin.
Sonuç
WordPress beyaz ekran hatası genellikle tek bir ölümcül PHP hatasının belirtisidir. En hızlı ve güvenli yol; kapsamı belirlemek, hata kaydını toplamak, eklenti ve temayı kontrollü biçimde izole etmek, ardından bellek veya PHP uyumluluğu gibi altyapı nedenlerini log bulgularına göre düzeltmektir. Rastgele çekirdek dosyası değiştirmek veya tüm ayarları sıfırlamak yerine, her değişiklikten sonra test yaparak ilerlemek hem kesintiyi hem de veri kaybı riskini azaltır.
Sık sorulan sorular
WordPress beyaz ekranı sadece yöneticilere mi görünür?
Evet. Bazı hatalar yalnızca oturum açmış kullanıcıların yüklediği yönetim araçlarında, araç çubuklarında veya önizleme işlemlerinde çalışır. Gizli sekmede ve hem ön yüzde hem yönetim panelinde ayrı test yapın.
Eklenti klasörünü yeniden adlandırmak veri siler mi?
Hayır. Klasör adını değiştirmek eklenti dosyalarını geçici olarak devre dışı bırakır. Ancak eklentinin kendi verileri veritabanında kalır. Yine de işlem öncesi yedek alın.
WP_DEBUG açmak güvenli midir?
WP_DEBUG_DISPLAY kapalı tutulursa hatalar ziyaretçiye gösterilmez ve loga yazılır. Teşhis tamamlanınca debug modunu kapatın; log dosyasında hassas yol veya hata bilgileri bulunabilir.
PHP bellek limitini artırmak her zaman çözüm olur mu?
Hayır. Bellek yetersizliği gerçek nedense yardımcı olur; fakat hatalı eklenti, sonsuz döngü veya büyük ve verimsiz sorgu varsa asıl nedeni düzeltmek gerekir.
Yalnızca bir sayfa beyazsa WordPress’i yeniden kurmalı mıyım?
Önce o sayfadaki şablonu, blokları, kısa kodları ve hata logunu inceleyin. Tek sayfa sorunu çoğunlukla çekirdek kurulumundan değil, o içeriğe özgü bir bileşenden kaynaklanır.
