WordPress Beyaz Ekran Hatası: PHP ve Hosting Çözümü

WordPress Beyaz Ekran Hatası (White Screen of Death) Nedir?

WordPress beyaz ekran hatası, sayfada görünür içerik olmamasıdır; yanıtın gerçekten boş olduğunu veya mutlaka PHP fatal error oluştuğunu tek başına kanıtlamaz. PHP ve veri tabanı hataları, eklenti/tema sorunları, sunucu kuralları veya önbellek davranışı olası nedenlerdir. Önce isteğin durum kodunu, yanıtını ve aynı zamandaki günlükleri karşılaştırın.

Beyaz ekran hatasını teşhis ederken, hata günlüklerini ve son yapılan değişiklikleri birlikte değerlendirmek gerekir. Önemli olan, sorunun gerçekten hosting/PHP katmanından mı yoksa sadece WordPress tarafındaki bir eklenti ya da temadan mı kaynaklandığını ayırt edebilmek. Bu rehberde, hem paylaşımlı hosting hem de VPS/dedicated sunucu kullananlar için, beyaz ekran hatasını sunucu ve PHP tarafında sistematik şekilde nasıl teşhis edip çözeceğinizi adım adım anlatacağız.

Değişikliklerden önce mevcut dosya, veri tabanı ve ayarların kurtarılabilir kopyasını koruyun; olay saatini ve son değişiklikleri kaydedin. Eklenti, tema, PHP ve sunucu kuralı denemelerini mümkünse ayrı veri tabanı/cache kullanan, e-posta ve ödeme gibi dış işlemleri kapatılmış staging ortamında yapın. Canlı müdahale gerekiyorsa kapsamını sınırlayın ve geri dönüş yolunu hazırlayın.

İlk Adım: Sorun Hosting mi, WordPress mi?

Beyaz ekran hatasını çözerken ilk hedefiniz şu olmalı: Problem sunucu/hosting katmanında mı, yoksa WordPress uygulamasında mı? Bunu hızlıca anlamak için birkaç temel kontrol yapabilirsiniz.

1. Farklı Sayfaları ve Admin Panelini Deneyin

Önce aşağıdaki üç testi yapın:

• Ana sayfaya gidin: https://siteadresiniz.com
• Rastgele bir iç sayfaya gidin: https://siteadresiniz.com/ornek-sayfa
• Admin paneline girmeyi deneyin: https://siteadresiniz.com/wp-admin

Çıkan sonuçlar size önemli ipuçları verir:

• Her yerde beyaz ekran: Ortak uygulama başlangıcı, PHP yapılandırması veya cache katmanı incelenebilir; bu sonuç sunucu arızasını tek başına kanıtlamaz.
• Yalnız admin panelinde: Yönetim isteğine özgü eklenti/kod ve kaynak kullanımını inceleyin; genel bellek ayarından farklı yönetim işlemleri de olabilir.
• Belirli sayfalarda: İlgili şablon, kısa kod, sorgu ve harici çağrıyı aynı isteğin hata kaydıyla eşleştirin. Tarayıcı tarafında HTML bulunup görünmüyorsa CSS/JavaScript hatalarını da değerlendirin.

2. Tarayıcının Network Sekmesi ve HTTP Durum Kodu Kontrolü

Beyaz ekranla birlikte bir 5xx HTTP hata kodu dönebilir; ancak beyaz ekran tek başına durum kodunu göstermez. Tarayıcıda Geliştirici Araçları’nı (F12) açıp Network sekmesi açıkken sayfayı yenileyin ve ana sayfa isteğinin durum kodunu kontrol edin. HTTP durum kodları hakkında daha derin bir okuma yapmak isterseniz, 301, 404 ve 5xx HTTP durum kodlarını anlatan detaylı rehberimizi inceleyebilirsiniz.

3. Basit Bir PHP Dosyası ile Sunucuyu Test Edin

PHP yapılandırması hâlâ belirsizse, ilgili sitenin belge kökünde (genellikle public_html) geçici test dosyası kullanılabilir. Önce dosyanın web erişimini yalnız size açan kısıtlamayı yapılandırıp doğrulayın; adını gizlemek erişim kontrolü değildir. Bu koruma sağlanamıyorsa paneldeki bilgileri veya sağlayıcının doğrulamasını kullanın:

<?php
phpinfo();

Bunu info.php olarak kaydedin ve tarayıcıdan https://siteadresiniz.com/info.php adresine gidin. Bu sayfa sunucu ve PHP yapılandırma bilgilerini açığa çıkarabileceğinden çıktıyı herkese açık paylaşmayın; kontrol bittiğinde dosyayı silin.

• PHP bilgi ekranı düzgün geliyorsa: Bu dosya için PHP çalışıyor demektir. Bu sonuç, WordPress’in ihtiyaç duyduğu kaynakların ve yapılandırmanın sorunsuz olduğunu kanıtlamaz; WordPress hata günlükleriyle devam edin.
• Bu dosyada da beyaz ekran veya 500 hatası görüyorsanız: Sorun hosting veya PHP yapılandırmasında olabilir (bozuk PHP, modül eksikliği, global konfigürasyon vb.).

Hosting Kaynak Limitleri: Bellek ve CPU Yetersizliği

CloudLinux kullanılan hesaplarda her limit aynı tepkiyi vermez. CPU ve disk IO/IOPS çoğunlukla işi yavaşlatır. PMEM sınırında önbellek geri kazanımı yetmezse LVE içindeki bazı süreçler sonlandırılabilir ve 500/503 görülebilir. Apache mod_hostinglimits altında EP giriş reddi 508 üretebilir; NPROC doluluğu yeni süreç oluşturulmasını engeller. EP, PHP worker sayısı değildir ve LiteSpeed sayımı farklıdır. Olay saatindeki gerçek limit/fault ve uygulama kaydı olmadan “PHP öldürüldü” sonucuna varmayın.

1. cPanel Kaynak Limitlerini Kontrol Edin

Kullandığınız cPanel ortamında Kaynak Kullanımı (Resource Usage) bölümü etkinse, sunulan zaman aralıklarında CPU, RAM, IO ve EP limitlerine ilişkin kayıtları inceleyin. Bu konuda detaylı bir arka plan için, cPanel'de kaynak limitleri ve "Resource Limit Reached" hatasını açıklayan rehberimize mutlaka göz atın.

Grafiklerde sık sık kırmızı alanlar, "fault" ya da "limit reached" uyarıları görüyorsanız, bunların zamanlarını beyaz ekranın oluştuğu isteklerle ve hata günlükleriyle karşılaştırın. Bu uyarılar tek başına PHP sürecinin sonlandığını veya beyaz ekranın nedenini kanıtlamaz.

2. PHP memory_limit Değerini Artırmak

Allowed memory size of XXX bytes exhausted kaydı, PHP’nin o istek için yapılandırılmış bellek tahsis sınırının aşıldığını gösterir; fiziksel sunucu RAM’inin bittiğini veya CloudLinux PMEM faultunu tek başına göstermez. İsteğin gerçek bellek ihtiyacını ve beklenmedik büyümenin nedenini araştırın.

Hata günlüğü bellek limitinin aşıldığını gösteriyorsa, mevcut ayarları yedekleyip hesabınızın izin verdiği sınırlar içinde memory_limit artışını değerlendirebilirsiniz:

• Etkinse cPanel MultiPHP INI Editor içinde önce ilgili alan adını seçin; Home Directory seçimi birden fazla siteyi etkileyebilir. Basic Mode’da memory_limit değerini düzenleyip Apply, Editor Mode’da geçerli INI satırını düzenleyip Save kullanılır. Select PHP Version ayrı bir sağlayıcı/CloudLinux arayüzüdür; aynı sekme ve düğmeleri varsaymayın. 256M/512M evrensel hedefler değildir.
• wp-config.php içinde mevcut tanımı düzenleyin; ikinci kez eklemeyin. Örnek: define( 'WP_MEMORY_LIMIT', '256M' );. Tanım WordPress yüklenmeden, wp-settings.php dahil edilmeden ve “That’s all, stop editing!” yorumundan önce olmalıdır. Bu, WordPress’in PHP limitini yükseltme isteğidir; sağlayıcının değiştirilemez sınırını veya hesap PMEM kotasını aşmaz. Yönetim işlemlerinin WP_MAX_MEMORY_LIMIT davranışını ve gerçek etkin değeri ayrıca kontrol edin.
• .htaccess için eski örnek: php_value memory_limit 256M. Apache adı tek başına bunu geçerli kılmaz: mod_php altında uygun AllowOverride izinleri gerekir; cPanel LSAPI bazı koşullarda ayrı bölüm üretir. PHP-FPM/CGI ortamına bu satırı körlemesine eklemek 500 hatası doğurabilir. Handler ve izinler doğrulanmadan kullanmayın; panelin desteklenen INI yöntemini tercih edin.

Etkin ayarı aynı alan adının web PHP isteğinde doğrulayın; CLI farklı yapılandırma kullanabilir. Aynı isteği yeniden ölçün, hata ve kaynak kullanımını karşılaştırın. Daha yüksek limitte açılması tek başına kök nedeni açıklamaz; eşzamanlı isteklerin toplam belleği hesabın kapasitesini aşabilir. Sürekli artış yerine pahalı kodu düzeltin ve yalnız doğrulanmış kapasite ihtiyacını büyütün.

Özellikle paylaşımlı hosting kullanıyorsanız, kaynak limitleriyle ilgili daha detaylı ipuçları için paylaşımlı hostingde "Resource Limit Reached" hatasını önleme rehberimize bakmanız faydalı olacaktır.

3. max_execution_time ve Zaman Aşımı Sorunları

Uzun süren sorgular veya büyük veri işleyen eklentiler (yığın içe aktarma, yedek alma, toplu ürün güncelleme gibi) max_execution_time limitine takıldığında da beyaz ekran görülebilir. PHP betiği zaman aşımı nedeniyle sonlanabilir; hata gösterimi kapalıysa ve henüz çıktı üretilmemişse sonuç beyaz ekran olabilir.

Günlükte hangi zaman aşımının oluştuğunu belirleyin. max_execution_time değişikliği web sunucusu, proxy veya PHP-FPM’nin ayrı süre sınırlarını otomatik değiştirmez. Uzun işleri küçük, sınırlı partilere ayırmayı ve yavaş sorgu/harici çağrıyı düzeltmeyi değerlendirin; süre artırımı gerekiyorsa kullanıcı bekleme süresini ve eşzamanlı yükü ölçerek seçin.

PHP Hatalarını Görünür Yapmak: debug.log ve error_log

Beyaz ekran hatasını çözmenin kilit adımı, gerçekte hangi PHP hatasının oluştuğunu görmek. Hataları ziyaretçiye göstermek yerine hata günlüklerine kaydedip inceleyin.

1. WordPress Hata Ayıklama Modunu Açmak

Önce staging’de çalışın. wp-config.php dosyasında mevcut tanımları düzenleyin; aynı sabiti ikinci kez eklemeyin. Aşağıdaki satırlar wp-settings.php dahil edilmeden ve “That’s all, stop editing!” yorumundan önce gelmelidir. true/false boolean değerlerini tırnak içine almayın. Log dosyasının web erişimini engelleyip PHP’nin yazma yetkisini doğrulayın; canlıda gerekiyorsa yalnız kısa, kontrollü teşhis süresince etkinleştirin:

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

Bu ayarlar sayesinde:

• WordPress debug gösterimi kapanır; PHP başlangıcındaki veya WordPress’in devreye girmesinden önceki hatalar için sunucu düzeyinde display_errors ayarının da kapalı olması gerekir.
• WordPress’in yakalayabildiği hatalar yazma izni varsa wp-content/debug.log dosyasına kaydedilir. WP_DEBUG_LOG=true dosyayı özel yapmaz; erişim engelini ayrıca doğrulayın. Boş günlük, hatasız çalışıldığının kanıtı değildir.

Bir kez daha beyaz ekranı tetikleyin ve ardından debug.log dosyasında aynı zamana ait kayıtları inceleyin. Çoğu zaman, sorunu doğrudan işaret eden fatal error satırları göreceksiniz (örneğin belirli bir eklenti dosyasında "Call to undefined function" veya "Allowed memory size exhausted" gibi). Günlük hassas bilgiler içerebilir; web üzerinden erişimini engelleyin. Teşhis tamamlanınca hata ayıklamayı kapatın ve gerekli kayıtları güvenli bir yere aldıktan sonra geçici günlük dosyasını kaldırın.

2. Sunucu error_log Dosyalarını Kontrol Edin

cPanel’de etkinse Metrics → Errors son web sunucusu hata kayıtlarını gösterir; bütün PHP-FPM, Nginx, cron veya CLI hatalarını kapsadığı varsayılmamalıdır. Raw Access erişim kayıtlarını indirir; Awstats trafik istatistiklerini gösterir. Bunlar PHP hata günlüğünün yerine geçmez. Yapılandırılmış error_log konumu web kökü, logs dizini veya başka bir yol olabilir; DirectAdmin’de de gerçek alan adı/handler günlüğünü sağlayıcıdan doğrulayın.

Eklenti ve Tema Çakışmaları: Güncelleme Sonrası Kontroller

WordPress beyaz ekran hatası, hatalı güncellenen veya uyumsuz bir eklenti ya da temadan kaynaklanabilir. Özellikle yeni bir eklenti kurduktan, tema değiştirdikten veya toplu güncelleme yaptıktan sonra beyaz ekranla karşılaştıysanız, ilk şüpheliniz burası olmalı.

1. Tüm Eklentileri Toplu Olarak Devre Dışı Bırakma

Önce güvenli staging kopyasında, son değişiklik ve logun işaret ettiği eklentiyi izole edin. Admin paneline erişemiyorsanız yetkili SFTP veya Dosya Yöneticisi erişimiyle şu dosya yöntemi kullanılabilir. Canlıda eklenti kapatmak ödeme, giriş, güvenlik ve kuyruk işlerini etkileyebileceğinden bakım planı gerekir:

1. wp-content/plugins klasörünün mevcut durumunu kaydedip adını geçici olarak plugins-disabled yapın; bu, bu dizindeki normal eklentilerin yüklenmesini engeller.
2. Kontrollü isteği ve mümkünse WordPress Eklentiler ekranını açın. Must-use, ağ düzeyi yapılandırmalar ve drop-in dosyalarının bu testle tamamen elenmediğini unutmayın.
3. Klasörü tekrar plugins adına döndürün ve gerçek etkinlik durumunu kontrol edin; yalnız geri adlandırmak bütün kurulumlarda kalıcı devre dışı bırakma sağlamaz.
4. Staging’de eklentileri tek tek etkinleştirip aynı işlemi test edin. Sonucu hata kaydıyla doğrulayın; canlı kritik işlevleri açmadan önce ödeme, giriş ve zamanlanmış görevleri kontrol edin.

Sorunlu bileşende desteklenen düzeltmeyi veya uyumlu alternatifi test edin. Önceki sürüme dönüş ancak kod, veri tabanı şeması ve güvenlik durumu uyumluysa uygundur; yalnız eklenti dosyalarını eski sürümle değiştirmek veri göçünü geri almaz.

2. Temayı Değiştirerek Test Etmek

Bazen sorun eklentide değil, kullanılan temadadır. Özellikle yoğun sayfa oluşturucu (page builder) içeren, kendi framework'ünü kullanan temalarda PHP sürüm değişikliğinden sonra hatalar sık görülür.

wp-content/themes dizinindeki aktif tema üzerinde işlem yapmadan önce kurulumla uyumlu bir varsayılan temanın gerçekten yüklü olduğunu ve gerekliyse parent/child tema ilişkisini doğrulayın. Staging’de panelden bu temayı etkinleştirmek tercih edilir. Panel yoksa mevcut klasörü silmeden geçici adlandırma denenebilir; otomatik geri dönüşün gerçekleştiğini kontrol edin. Açılan sayfa tema yolunu şüpheli yapar; logla doğrulamadan tek kök neden saymayın.

3. Bu İşlemleri Canlı Sitede Değil, Staging'te Yapmak

Üretim sitenizde (canlı ortam) bu tür denemeler kullanıcılarınızı etkileyebilir. Özellikle e-ticaret veya yoğun trafik alan sitelerde, denemeleri bir staging (önizleme) ortamında yapmak çok daha güvenlidir. Bunun için, WordPress staging ortamı kurulumunu adım adım anlatan rehberimize göz atabilirsiniz.

PHP Sürümü Uyumsuzlukları: Çok Eski ya da Çok Yeni PHP

WordPress, eklenti ve temaların PHP uyumluluğu sürüme göre değişir. Güvenlik desteği devam eden bir PHP dalı ve güncel düzeltme sürümü seçin; yeni sürüme geçmeden kaldırılmış işlevleri, değişen davranışları ve gerekli uzantıları staging’de kontrol edin.

1. Hangi PHP Sürümünü Kullandığınızı Öğrenin

Gerekliyse daha önce erişimi kısıtlanmış info.php çıktısı veya panelin alan adına uyguladığı sürüm/handler bilgisiyle web isteğinin kullandığı PHP’yi doğrulayın; test dosyasını sonra silin. PHP 8.0/8.1 artık upstream güvenlik desteği alan dallar değildir. Güncel PHP destek tablosu ile uygulama uyumluluğunu birlikte kontrol edin; yalnız “8.x” yazması yeterli değildir.

2. cPanel / DirectAdmin ile PHP Sürümü Değiştirmek

Alan adı başına PHP seçimi, sağlayıcının etkinleştirdiği araçlara ve kurulu sürümlere bağlıdır. cPanel MultiPHP Manager ile CloudLinux PHP Selector aynı arayüz değildir; DirectAdmin’deki seçenekler de kurulumdan kuruluşa değişir. Uygulanacak kapsamı doğruladıktan sonra cPanel ve DirectAdmin’de çoklu PHP sürümü yönetimi rehberini kullanın.

Beyaz ekran hatasını çözerken, şu iki senaryo sık görülür:

• Eski bir PHP dalından güncel dala geçiş, kaldırılmış işlev veya değişen tür davranışı yüzünden fatal error oluşturabilir. Tek başına “Deprecated” uyarısı normalde fatal error değildir; uygulamanın hata işleyicisi davranışı ayrıca değerlendirilir.
• Eski PHP üzerinde yeni söz dizimi kullanan eklenti parse error verebilir. Çözüm, güvenlik desteği sona ermiş sürüme kalıcı dönüş değil, desteklenen uyumlu sürüm ve bileşen düzeltmesidir.

Geçici geri dönüş ancak önceki PHP dalı hâlâ güvenlik desteği alıyor ve mevcut uygulamayla uyumluysa değerlendirilmelidir. Aksi durumda uyumsuz bileşeni düzeltin veya değiştirin. Sürüm, uzantı ve handler değişikliklerini test etmek için PHP 8.x yükseltme kontrol listesini kullanın; başarılı görünen ana sayfanın yanında yönetim, cron ve iş akışlarını da doğrulayın.

.htaccess, Dosya İzinleri ve Bozulmuş Çekirdek Dosyalar

Bazen sorun ne eklentide, ne temada, ne de PHP sürümünde olur. Özellikle manuel taşıma, yarım kalan FTP yüklemeleri veya yanlış güvenlik eklentisi ayarları sonrası .htaccess dosyası, dosya izinleri veya WordPress çekirdek dosyaları bozulabilir.

1. .htaccess Kurallarını Kontrollü Test Etmek

Sunucu bu dosyayı okuyorsa, .htaccess içindeki geçersiz yönerge 500 hatası yaratabilir; Nginx bu dosyayı doğrudan okumaz. Önce hata satırını ve etkin handler’ı kontrol edin. Tüm dosyayı kaldırmak erişim kısıtlarını, HTTPS yönlendirmesini ve PHP handler seçimini kaldırabilir; korumaları ayrı katmanda sürdürmeden canlıda denemeyin.

1. İlgili belge kökündeki (public_html veya siteye özel yol) .htaccess dosyasını yedekleyin; .htaccess.bak gibi kopyaların webden indirilemediğini de kontrol edin. Staging’de önce logun işaret ettiği yönergeyi ayrı test edin.
2. Bir kuralı çıkardıktan sonra açılması .htaccess etkisini gösterir; gerekli erişim, TLS ve handler kurallarını korunmuş tutun ve kök nedeni belirleyin.
3. WordPress permalink kuralları gerekiyorsa, admin panelinde Kalıcı Bağlantılar ekranını kullanın. Yazma izni yoksa WordPress’in verdiği kuralları inceleyerek uygulayın. Aşağıdaki .htaccess örneği yalnız kök dizindeki klasik tek site için eski, asgari rewrite örneğidir; multisite, alt dizin, kimlik doğrulama ve sunucuya özel kurallar için tam dosya yerine kullanmayın.

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

2. Dosya İzinlerini Kontrol Etmek

Yanlış dosya izinleri de PHP'nin dosyalara erişememesine ve buna bağlı fatal error'lara neden olabilir. Temel olarak:

• Dosyalarda 644 ve dizinlerde 755 sık görülen örneklerdir; gerekli değer, dosya sahibi/grubu ve PHP’nin çalıştığı kullanıcıya bağlıdır. Bütün ağacı körlemesine yeniden izinlendirmeyin.
• PHP’nin yalnız gerekli dosyaları okuyabilmesini, gerekli dizinleri geçebilmesini ve yalnız tasarlanmış konumlara yazabilmesini sağlayın. ACL, güvenlik politikası ve handler koşullarını sağlayıcıyla kontrol edin; gizli yapılandırmalar daha dar izin isteyebilir.

777 gibi herkesin yazabildiği izinler hem güvenlik açığı hem de beklenmedik hatalar doğurabilir; uzak durmanızı öneririz.

3. WordPress Çekirdeğini Yeniden Yüklemek

Bazı durumlarda wp-admin veya wp-includes klasörlerinde eksik/bozuk dosyalar beyaz ekrana yol açabilir. Çözüm için:

1. Önce eksik veya bozuk dosyayı doğrulayın; mevcut dosya, yapılandırma ve veri tabanı yedeğini alın. Aynı WordPress sürümünün resmî temiz paketini edinin; sürüm yükseltmeyi ayrı işlem olarak planlayın.
2. Kontrollü bakımda wp-admin ve wp-includes dosyalarını temiz paketle yenileyin. Hata kök dizindeki çekirdek dosyasındaysa onu da aynı sürümle doğrulayın; iki klasörü kopyalamak her bozulmayı düzeltmez.
3. wp-content ve mevcut yapılandırmayı koruyun; bunları temiz paketle değiştirmeyin. Eksik/yanlış sürüm dosyası kalmadığını ve uygulama işlemlerini kontrol edin.

Aynı sürümde dosya onarımı ile sürüm/veri tabanı yükseltmesi farklı işlemlerdir. Şüpheli yetkisiz değişiklik varsa yalnız çekirdeği yeniden kopyalamak olayı çözmez; giriş yolunu ve kalıcılığı araştırın, kanıtları koruyun. Geri dönüş hazırlığı için WordPress dosya ve veri tabanı yedekleme rehberini kullanın.

Veritabanı ve Önbellek Kaynaklı Beyaz Ekran Senaryoları

Daha az görülse de, bazı veritabanı hataları ve nesne önbelleği (object cache) sorunları da beyaz ekran üretebilir.

1. Veritabanı Bağlantısını ve Tablo Sağlığını Kontrol Edin

wp-config.php dosyanızda veritabanı adı, kullanıcı adı, parola ve sunucu adresi (DB_HOST) bilgilerini kontrol edin. Özellikle siteyi yeni sunucuya taşıdıysanız, burada yapılan küçük bir yazım hatası bile sitenin çökmesine neden olabilir.

Bağlantı hatası, parola veya ağ sorunu tablo onarımıyla çözülmez. Yalnız kayıtlar tablo bozulmasına işaret ediyorsa, doğrulanmış veri tabanı yedeği ve uygun bakım planıyla onarım düşünün. WordPress’in aşağıdaki onarım ekranı etkin olduğunda giriş gerektirmez; önce erişimi yalnız yetkili kişilere sınırlayın:

1. wp-config.php içinde, WordPress yüklenmeden önce ve yinelenen tanım oluşturmadan geçici olarak define( 'WP_ALLOW_REPAIR', true ); kullanılabilir.
2. Erişimi kısıtlanmış https://siteadresiniz.com/wp-admin/maint/repair.php yolunu açın.
3. Yalnız doğrulanmış tablo sorunu ve kullanılan veri tabanı motorunun desteklediği işlem için onarımı değerlendirin; sırf beyaz ekran var diye onarım/optimizasyon çalıştırmayın.
4. İşlemden hemen sonra tanımı wp-config.php içinden kaldırın, ekranın kapandığını doğrulayın ve uygulama/veri kontrollerini yapın.

2. Nesne Önbelleği (Redis/Memcached) ve object-cache.php

Performans için Redis veya Memcached tabanlı nesne önbelleği kullanan WordPress sitelerinde, yanlış yapılandırılmış veya çökmiş bir önbellek katmanı da fatal error üretebilir. Şu adımları deneyin:

• Önce wp-content içindeki object-cache.php dosyasını yedekleyin; eklentinin belgelenmiş devre dışı bırakma yolunu tercih edin. Gerekirse staging’de geçici adlandırın, silmeyin. Cache devreden çıkınca veri tabanı yükünün artabileceğini hesaba katın.
• Redis/Memcached hizmetini ancak loglar gerektiriyor ve etki kapsamı biliniyorsa yeniden başlatın. Sağlayıcı panelinde böyle bir yetki olduğunu varsaymayın; yönetici olduğunuz sistemde systemctl kullanımı için gerçek hizmeti ve diğer uygulamaları doğrulayın.
• İlgili eklenti/drop-in ayarını, bağlantı ve kimlik doğrulamayı test edin. Paylaşılan Redis/Memcached üzerinde bütün veriyi temizlemeyin; diğer uygulama veya oturum verileri etkilenebilir.

Cache devre dışıyken sorunun kaybolması bağımlılığı işaret eder; servisi yeniden kurmadan önce bağlantı, yetki, sürüm ve eklenti uyumunu günlüklerle doğrulayın. Kalıcı çözümden sonra cache’i kontrollü açıp yanlış veya eski verinin sunulmadığını ve yükün uygun olduğunu test edin.

WordPress Beyaz Ekranı İçin Teşhis Sırası

Aşağıdaki sıra, denemelerin birbirine karışmasını önler. Her adıma koşulsuz geçmek yerine önceki adımın kanıtına göre ilgili dala ilerleyin:

1. Yanıt kodunu/içeriğini, olay saatini ve etkilenen yolları kaydedin; mevcut durumu yedekleyin ve güvenli staging hazırlayın.
2. PHP yapılandırması belirsizse erişimi önceden kısıtlanmış info.php ile yalnız o web isteğini doğrulayın; dosyayı kaldırın.
3. Etkinse cPanel kaynak verilerini aynı zamanın hata ve erişim kayıtlarıyla eşleştirin; CPU, PMEM, IO, EP ve NPROC aynı tepkiyi vermez.
4. Günlük gerektiriyorsa memory_limit veya max_execution_time ayarını handler ve hesap kapasitesi içinde test edin.
5. wp-config.php içinde doğru konumda, yinelenmeyen WP_DEBUG/WP_DEBUG_LOG tanımlarıyla ve kapalı debug gösterimiyle kısa teşhis yapın; debug.log web erişimini engelleyin.
6. İşaret edilen eklenti/tema, kural, izin veya çekirdek dosyasını staging’de tek değişkenle test edin; geniş sıfırlama yapmayın.
7. Veri tabanı onarımını yalnız doğrulanmış tablo bozulmasında, yedek ve kısıtlı erişimle değerlendirin.
8. Çözümü aynı istek, yönetim, giriş, ödeme ve zamanlanmış işler üzerinde doğrulayın; geçici teşhis dosyalarını kaldırıp debug ayarlarını kapatın.

Erişemediğiniz log veya sunucu ayarı varsa sağlayıcıya alan adı, saat dilimiyle olay zamanı, son değişiklik ve ilgili hata satırını iletin. debug.log içeriğinden parola, token, kişisel veri ve gereksiz ayrıntıları çıkarın; yalnız yetkili destek kanalını kullanın. Çözüm süresi veya sağlayıcının sizin yerinize yapacağı işlem kapsamı varsayılmamalıdır.

Bu Hata Tekrar Yaşanmasın: Önleyici Adımlar

WordPress beyaz ekran hatasını bir kez çözdükten sonra, asıl önemli olan tekrar yaşamamak için ne yapacağınız. Özellikle üretim ortamında çalışan, gelir üreten sitelerde önleyici bakım hayati önem taşır.

1. Sağlam Bir Yedekleme Stratejisi Kurun

Her değişiklikten önce birbiriyle tutarlı dosya, veri tabanı, yapılandırma ve varsa dış depolanan medya/anahtarları kapsayan geri dönüş noktası hazırlayın. Bağımsız kopyalar tutun; sıklığı kabul edilebilir veri kaybına, saklamayı geri dönüş ve yasal ihtiyaca göre belirleyin. İzole geri yükleme testi ve WordPress yedekleme rehberindeki doğrulama adımları kurtarma planının parçasıdır.

2. Güncellemeleri Önce Staging Ortamında Test Edin

Özellikle WooCommerce veya özel geliştirmeli sitelerde, güncellemeleri doğrudan canlı ortamda yapmak risklidir. Staging ortamı kullanarak:

• PHP sürümü/handler, uzantı ve cache davranışını canlıya benzetin; dosya, veri tabanı, kullanıcı ve cache alanlarını ayırın.
• Gerekli test verisini sınırlayın veya anonimleştirin. E-posta, ödeme, webhook, sipariş aktarımı ve dış görev tetiklemelerini klonu çalıştırmadan önce kapatın.
• Eklenti, tema, PHP ve gerçek iş akışlarını test edin. Staging yalnız alt alan adı açıldığı için yalıtılmış sayılmaz; sonuçları kontrollü canlı doğrulamayla tamamlayın.

Staging kurulumunu manuel yapmak isterseniz, WordPress staging ortamı kurulum rehberimiz size adım adım yol gösterecektir.

3. Kaynak Kullanımını ve Hata Loglarını Periyodik Olarak İzleyin

Periyodik kaynak ve hata takibi, kullanıcı işlemlerini etkileyen tekrarlayan sorunları belirlemeye yardımcı olur. Tek grafik rengi yerine olay zamanındaki limit/fault, istek gecikmesi ve tamamlanan işlemleri birlikte inceleyin:

• Bozulan veya hataya düşen eklentileri erken fark edebilirsiniz.
• Aşırı kaynak tüketen sorgu veya cron işleri hakkında ipuçları yakalayabilirsiniz.
• Gerekirse hosting paketinizi zamanında yükseltip daha güçlü bir VPS veya dedicated sunucuya geçme kararını önceden planlayabilirsiniz.

4. Sunucu Tarafı Optimizasyonları İhmal Etmeyin

PHP-FPM, OPcache, nesne önbelleği ve veri tabanı ayarları ancak ölçülen ihtiyaca göre değiştirildiğinde değerlendirilebilir; fazla worker veya hatalı cache daha fazla sorun doğurabilir. WordPress sunucu optimizasyon rehberindeki ayarları yetkiniz, handler’ınız ve gerçek iş yükünüz kapsamında test edin.

Özet ve Yol Haritası

Beyaz ekran bir belirtidir; tek bir PHP fatal error veya hosting yetersizliği teşhisi değildir. Yanıt, günlük ve son değişikliği eşleştirerek şu soruları yanıtlayın:

• Bu bir hosting/kaynak sorunu mu (bellek, CPU, PHP versiyonu)?
• Yoksa WordPress katmanında bir problem mi (eklenti, tema, bozuk çekirdek, veritabanı)?
• Hangi adımı attıktan sonra bu sorun ortaya çıktı (update, taşıma, PHP yükseltme)?

Tanı süresi olayın kapsamına bağlıdır. Destek talebinde son işlem, saat dilimiyle zaman, etkilenen URL, gerçek HTTP yanıtı ve hassas verileri çıkarılmış debug.log veya sunucu hata satırlarını paylaşın. Yaptığınız değişiklikleri ve geri dönüş durumunu da belirtin; kayıt bulunmaması sorunu dışlamaz.

İşlem sonunda yalnız ana sayfanın açıldığını değil, etkilenen kullanıcı akışının doğru tamamlandığını doğrulayın. Geri yükleme testi, yalıtılmış staging ve ölçüme dayalı kaynak takibi, sonraki olayın teşhisini ve güvenli geri dönüşünü kolaylaştırır; tekrar etmeme garantisi vermez.