Kayıt ol

Tovala Akıllı Fırın Deneyimi: Paket Servisten Daha İyi mi?FortiMail'de Kritik Zero-Day Açığı Aktif Saldırılarda Kullanılıyor Meadow: Sosyal Medyasız Minimalist Telefon Deneyimi California'da Gizli Kayıt Yapan Akıllı Gözlük Yasasına Veto Hello Robot Stretch 4, TechCrunch Disrupt 2026'da Canlı Tanıtılacak

JavaScript devre dışı. Daha iyi bir deneyim için, önce lütfen tarayıcınızda JavaScript'i etkinleştirin.

WordPress Beyaz Sayfa Hatası: Nedenleri ve Adım Adım Çözümü

Mesaj: <blockquote data-quote="Admin" data-source="post: 12838" data-attributes="member: 1"><p><h2>WordPress Beyaz Sayfa Hatası: Nedenleri ve Adım Adım Çözümü</h2><p>WordPress sitenizi açtığınızda içerik yerine tamamen boş bir ekran görüyorsanız, ilk yapılacak iş rastgele ayar değiştirmek değildir. Önce sorunun hangi sayfalarda ortaya çıktığını ve hata başlamadan önce neyin değiştiğini belirlemek gerekir.</p><p>“White Screen of Death” veya kısaca WSOD olarak bilinen beyaz ekran, tek bir hatanın adı değildir. PHP ya da veritabanı hataları bu şekilde görünebilir; tema ve eklenti uyumsuzlukları da olası nedenler arasındadır. Bu yüzden her boş sayfayı bellek yetersizliği olarak değerlendirmek doğru olmaz.</p><p>Bu rehberde, yönetim paneline erişemediğiniz durumlar dâhil, sorunu kontrollü biçimde incelemek için kullanabileceğiniz adımları bulabilirsiniz.</p><h2>İlk Kontrol: Sorun Nerede ve Ne Zaman Başladı?</h2><p>İşlem yapmadan önce birkaç soruya cevap verin:</p><ul> <li data-xf-list-type="ul">Ana sayfa ve diğer sayfalar da boş mu?</li> <li data-xf-list-type="ul"><code class="bbCodeInline">/wp-admin/</code> üzerinden yönetim paneli açılıyor mu?</li> <li data-xf-list-type="ul">Sorun bütün ziyaretçilerde mi görülüyor?</li> <li data-xf-list-type="ul">Son işlem bir eklenti, tema veya PHP sürümü değişikliği miydi?</li> <li data-xf-list-type="ul">Güncelleme tamamlandı mı, yarıda mı kaldı?</li> </ul><p>Örneğin sorun bir kod düzenlemesinin hemen ardından başladıysa, önce o değişikliği incelemek daha anlamlıdır. Yalnızca tek bir sayfanın etkilenmesi ise o sayfada kullanılan şablon veya işlevlere odaklanmayı gerektirebilir.</p><p>Mümkünse mevcut dosyaların ve veritabanının yedeğini alın. En azından değiştireceğiniz dosyaların bir kopyasını saklayın. Her seferinde tek değişiklik yapıp sonucu kontrol edin; böylece hangi müdahalenin etkili olduğunu anlayabilirsiniz.</p><h3>Gerçekten boş yanıt mı, görüntüleme sorunu mu?</h3><p>Tarayıcının geliştirici araçlarından ana sayfa isteğinin durumunu ve yanıt içeriğini inceleyin. Sunucudan HTML geliyor fakat ekranda görünmüyorsa, JavaScript veya sayfa görünümüyle ilgili bir sorun da araştırılmalıdır.</p><p>WordPress’in resmî dokümanlarında tarayıcı araçlarıyla JavaScript hatalarının incelenmesi ayrı bir sorun giderme yöntemi olarak açıklanır.</p><p>Farklı tarayıcıyla kontrol etmek faydalıdır. Ancak önbelleği temizlemek, sunucudaki bir PHP hatasını tek başına düzeltmez.</p><h2>1. Hata Kayıtlarını İnceleyin</h2><p>Hosting panelindeki PHP ve web sunucusu hata kayıtlarıyla başlayın. Sorunun oluştuğu saati not edip ilgili kayıtları arayın.</p><p>WordPress hata ayıklaması için <code class="bbCodeInline">wp-config.php</code> dosyasındaki mevcut tanımları düzenleyebilirsiniz:</p><p>[CODE]define('WP_DEBUG', true);</p><p>define('WP_DEBUG_LOG', true);</p><p>define('WP_DEBUG_DISPLAY', false);</p><p>@ini_set('display_errors', 0);[/CODE]</p><p>Aynı sabitleri ikinci kez eklemeyin. Tanımları, dosyadaki “That’s all, stop editing” yorumundan ve WordPress’in yüklenmesinden önce yerleştirin. <code class="bbCodeInline">true</code> ve <code class="bbCodeInline">false</code> değerlerini tırnak içine almayın.</p><p>Bu yapılandırmada WordPress kayıtları genellikle <code class="bbCodeInline">wp-content/debug.log</code> dosyasına yazar. Hatayı yeniden oluşturup günlüğün son satırlarını kontrol edin. Hata ayıklamasını mümkünse test ortamında, canlı sitede gerekiyorsa kısa süreli kullanın.</p><p><strong>Önemli:</strong> Hataların ekranda gösterilmemesi, günlük dosyasının özel olduğu anlamına gelmez. Dosya web üzerinden erişilebilir olabilir. Günlüğü web kökü dışında tutmak veya HTTP erişimini sunucu seviyesinde engellemek gerekir.</p><p>Kayıt oluşmuyorsa dosya izinleri, günlük ayarları veya WordPress başlamadan önce gerçekleşen bir hata araştırılmalıdır. Hosting tarafındaki PHP günlüğünü de inceleyin.</p><h3>Hata mesajları nasıl yorumlanır?</h3> <table style='width: 100%'><tr><th>Kayıt veya belirti</th><th>Araştırılacak konu</th></tr><tr><td><code class="bbCodeInline">Allowed memory size ... exhausted</code></td><td>İşlemin bellek tüketimi ve etkin PHP limiti</td></tr><tr><td><code class="bbCodeInline">Call to undefined function</code></td><td>Eksik dosya, bağımlılık veya sürüm uyumsuzluğu</td></tr><tr><td><code class="bbCodeInline">Parse error</code> / <code class="bbCodeInline">Syntax error</code></td><td>PHP kodundaki yazım hatası</td></tr><tr><td>Tema klasörünü gösteren hata yolu</td><td>Tema, child theme veya ilgili özel kod</td></tr><tr><td>Güncelleme sonrasında başlayan sorun</td><td>Güncellemenin tamamlanıp tamamlanmadığı</td></tr><tr><td>HTTP 500 yanıtı</td><td>PHP hatası, sunucu ayarı veya diğer sunucu sorunları</td></tr></table><p></p><p>Dosya yolu önemli bir ipucudur; fakat hatada adı geçen bileşen tek başına kesin suçlu sayılmaz. Başka bir eklentiyle etkileşim veya eksik bağımlılık da incelenmelidir.</p><h2>2. Kurtarma Modu E-postasını Kontrol Edin</h2><p>WordPress, bazı kritik PHP hatalarında yönetici adresine kurtarma bağlantısı gönderebilir. Gelen kutusuyla birlikte spam klasörünü de kontrol edin.</p><p>Kurtarma Modu, sorunlu tema veya eklentiyi ilgili oturum için duraklatarak yönetim paneline erişmenize yardımcı olabilir. Bu erişim, sitenin bütün ziyaretçiler için düzeldiği anlamına gelmez; sorunun ayrıca giderilmesi gerekir.</p><p>Her hata için kurtarma e-postası gelmesi garanti değildir. Hata oluşma aşaması veya e-posta teslimi buna engel olabilir. Bağlantıyı da başkalarıyla paylaşmayın.</p><h2>3. Eklentileri Kontrollü Şekilde Test Edin</h2><p>Hata kaydı veya son değişiklik belirli bir eklentiyi işaret ediyorsa, önce o bileşeni devre dışı bırakın.</p><p>Panele girebiliyorsanız <strong>Eklentiler</strong> ekranını kullanabilirsiniz. Erişemiyorsanız dosya yöneticisi veya SFTP üzerinden ilgili klasörün adını geçici olarak değiştirmek mümkündür.</p><p>Örneğin:</p><p><code class="bbCodeInline">wp-content/plugins/ornek-eklenti</code></p><p>Geçici ad:</p><p><code class="bbCodeInline">wp-content/plugins/ornek-eklenti-test</code></p><p>Ardından etkilenen sayfayı tekrar kontrol edin.</p><h3>Hangi eklentiden kaynaklandığı belli değilse</h3><p>Normal eklentileri topluca test etmek için:</p><ol> <li data-xf-list-type="ol"><code class="bbCodeInline">wp-content/plugins</code> klasörünü geçici olarak <code class="bbCodeInline">plugins.hold</code> şeklinde yeniden adlandırın.</li> <li data-xf-list-type="ol">Yönetim panelindeki eklenti sayfasını açmayı deneyin.</li> <li data-xf-list-type="ol">WordPress’in eksik eklentileri devre dışı bırakmasının ardından klasör adını tekrar <code class="bbCodeInline">plugins</code> yapın.</li> <li data-xf-list-type="ol">Eklentileri tek tek etkinleştirip her aşamada kontrol edin.</li> </ol><p>Bu yöntem WordPress’in resmî sorun giderme belgesinde açıklanır. Klasörün adını geri vermeden önce devre dışı bırakma adımının gerçekleşmesi önemlidir.</p><p>Eklentiler kapalıyken ödeme, form veya üyelik işlevleri çalışmayabilir. Testi kısa tutun ve mümkünse site kopyasında uygulayın.</p><p>Ayrıca bu işlem <code class="bbCodeInline">mu-plugins</code> içindeki zorunlu eklentileri kapatmaz. Bunlar normal eklentilerden farklı şekilde yüklenir.</p><p>Site açılırsa silme işlemine hemen geçmeyin. Sorunlu bileşenin sürümünü, bağımlılıklarını ve uyumluluğunu inceleyin.</p><h2>4. Temayı ve Son Kod Değişikliklerini Kontrol Edin</h2><p>Sorun tema güncellemesi veya <code class="bbCodeInline">functions.php</code> düzenlemesi sonrasında başladıysa önce ilgili değişikliği geri alın.</p><p>Panele erişebiliyorsanız, kurulu ve WordPress sürümünüzle uyumlu bir resmî temayı geçici olarak etkinleştirin. Ardından aynı sayfayı kontrol edin.</p><p>Aktif tema klasörünü yeniden adlandırmanın her durumda otomatik geçiş sağlayacağını varsaymayın. WordPress’in geri dönüş yapabilmesi için uygun varsayılan temanın mevcut olması ve tema doğrulama sürecinin çalışabilmesi gerekir.</p><p>Yönetim paneline erişilemiyorsa, WP-CLI bulunan ortamlarda kurulu başka bir tema komut satırından etkinleştirilebilir. Bu işlem mevcut sitenin görünümünü değiştireceği için doğru tema klasörünün seçilmesi gerekir.</p><p>Child theme kullanıyorsanız hem child theme’i hem de ihtiyaç duyduğu ana temayı inceleyin.</p><h2>5. Bellek Limitini Yalnızca Gerekliyse Düzenleyin</h2><p>Günlükte <code class="bbCodeInline">Allowed memory size ... exhausted</code> mesajı varsa, işlem PHP’nin izin verdiği belleği aşmıştır.</p><p>PHP’nin <code class="bbCodeInline">memory_limit</code> ayarı, bir betiğin ayırabileceği belleği sınırlar. Bu değer sunucunun toplam RAM’iyle aynı şey değildir.</p><p>WordPress tarafında örnek olarak şu tanımlar kullanılabilir:</p><p>[CODE]define('WP_MEMORY_LIMIT', '256M');</p><p>define('WP_MAX_MEMORY_LIMIT', '256M');[/CODE]</p><p>Mevcut tanımlar varsa onları düzenleyin. Bu değerler bütün siteler için zorunlu minimum değildir; ihtiyaç ve hosting sınırlarına göre belirlenmelidir.</p><p><code class="bbCodeInline">WP_MEMORY_LIMIT</code> genel işlemlerle, <code class="bbCodeInline">WP_MAX_MEMORY_LIMIT</code> ise yönetim gibi daha fazla bellek isteyebilen işlemlerle ilişkilidir. Tanımlar, hostingin izin vermediği bir artışı zorla uygulayamaz.</p><p>Etkin PHP limitini doğrulayın. Limit yükselince hata kaybolsa bile anormal bellek tüketiminin nedenini araştırın. Sorunlu bir sorgu veya döngü, daha yüksek limiti de tüketebilir.</p><h2>6. <code class="bbCodeInline">.htaccess</code> Dosyasını Sunucu Türüne Göre İnceleyin</h2><p><code class="bbCodeInline">.htaccess</code>, bu dosyayı işleyen Apache gibi ortamlarda önemlidir. Nginx ise <code class="bbCodeInline">.htaccess</code> kurallarını kullanmaz; ilgili yapılandırma başka yerde yönetilir.</p><p>Özellikle yakın zamanda bu dosyaya bir kural eklediyseniz:</p><ol> <li data-xf-list-type="ol">Mevcut dosyanın kopyasını alın.</li> <li data-xf-list-type="ol">Önce son eklenen kuralı inceleyin.</li> <li data-xf-list-type="ol">Gerekirse kısa süreli test için dosyayı yeniden adlandırın.</li> <li data-xf-list-type="ol">Sonuca göre hatalı kuralı düzeltin veya dosyayı geri getirin.</li> </ol><p>Dosya; yönlendirme ve erişim koruması gibi özel kurallar içerebilir. Bu nedenle tamamını kaldırıp unutmayın. <code class="bbCodeInline">.htaccess</code> dosyasının etkisi sunucu yapılandırmasına da bağlıdır.</p><p>Panel açılıyorsa <strong>Ayarlar → Kalıcı Bağlantılar</strong> üzerinden kaydetmek WordPress yönlendirme kurallarını yenilemeye yardımcı olabilir. Özel kurallarınızın ayrıca korunması gerekir.</p><h2>7. Eksik veya Bozulmuş Çekirdek Dosyalarını Kontrol Edin</h2><p>Yarım kalmış güncelleme veya başarısız aktarım şüphesi varsa çekirdek dosyalarını inceleyin. Dosya yenileme işleminden önce tam yedek alın.</p><p>Teknik erişiminiz ve WP-CLI kurulumunuz varsa şu kontrol kullanılabilir:</p><p><code class="bbCodeInline">wp core verify-checksums</code></p><p>Komut, çekirdek dosyalarını resmî sağlama toplamlarıyla karşılaştırır. Tema ve eklentilerin tamamı için kapsamlı güvenlik taraması yapmaz.</p><p>Dosyaları yeniden yüklemek gerekiyorsa sürümün tutarlı olduğundan emin olun. Aynı sürümü onarmak ile daha yeni sürüme geçmek ayrı işlemlerdir.</p><p>Manuel yenilemede yalnızca <code class="bbCodeInline">wp-admin</code> ve <code class="bbCodeInline">wp-includes</code> değil, kök dizindeki çekirdek dosyaları da değerlendirilmelidir. <code class="bbCodeInline">wp-content</code>, <code class="bbCodeInline">wp-config.php</code> ve özel dosyalar gelişigüzel silinmemelidir. WordPress’in resmî manuel güncelleme yönergesi bu ayrımları açıklar.</p><h2>8. Hosting Desteğine Hangi Bilgileri Vermelisiniz?</h2><p>Önceki kontroller sonuç vermediyse sağlayıcıdan sunucu kayıtlarını incelemesini isteyin. “Site beyaz ekran veriyor” ifadesinin yanında şu bilgileri paylaşın:</p><ul> <li data-xf-list-type="ul">Etkilenen adresler</li> <li data-xf-list-type="ul">Sorunun görüldüğü tarih, saat ve saat dilimi</li> <li data-xf-list-type="ul">Son yapılan değişiklik</li> <li data-xf-list-type="ul">Kullanılan WordPress ve PHP sürümü</li> <li data-xf-list-type="ul">Gizli bilgiler çıkarılmış hata kaydı</li> <li data-xf-list-type="ul">Denediğiniz işlemler ve sonuçları</li> </ul><p>Destekten PHP-FPM hataları, bellek nedeniyle sonlandırılan süreçler, disk alanı, izinler ve hesap kaynak sınırları gibi konuların kontrolünü isteyebilirsiniz.</p><p>Yeni hosting paketine geçmeyi veya kaynak yükseltmeyi, neden belirlenmeden kalıcı çözüm saymayın.</p><h2>Sorun Çözüldükten Sonra Yapılacak Kontroller</h2><p>Ana sayfanın açılmasıyla yetinmeyin. Yönetici girişi, iletişim formu, arama, üyelik ve varsa ödeme akışını test edin.</p><p>Ardından:</p><ul> <li data-xf-list-type="ul">Hata ayıklamayı kapatın.</li> <li data-xf-list-type="ul">Günlükleri güvenli şekilde kaldırın veya arşivleyin.</li> <li data-xf-list-type="ul">Gerekli önbellekleri temizleyin.</li> <li data-xf-list-type="ul">Geçici klasör adlarını kontrol edin.</li> <li data-xf-list-type="ul">Yapılan değişikliği ve çözümü kaydedin.</li> <li data-xf-list-type="ul">Yeni yedeğin başarıyla alındığını doğrulayın.</li> </ul><p>Birden fazla ayar aynı anda değiştirildiyse hangilerinin gerekli olduğunu yeniden değerlendirin.</p><p></p><h2>Sıkça Sorulan Sorular</h2><h3>Beyaz ekran, sitenin içeriğinin silindiği anlamına mı gelir?</h3><p>Tek başına böyle bir anlam taşımaz. Sayfa oluşturulamıyor olabilir. Dosya ve veritabanı durumunu ayrıca kontrol etmek gerekir.</p><h3>Yönetim paneli açılıyor ama site boşsa nereden başlamalıyım?</h3><p>Son değişiklikleri ve hata kayıtlarını inceleyin. Tema, sayfa şablonu ve yalnızca ön yüzde çalışan bileşenlere odaklanın.</p><h3><code class="bbCodeInline">debug.log</code> oluşmuyorsa ne yapmalıyım?</h3><p>Tanımları, dosya izinlerini ve günlük yolunu kontrol edin. Hostingin PHP kayıtlarına da bakın; hata WordPress günlük sistemi başlamadan önce oluşmuş olabilir.</p><h3>Eklentileri kapatınca site açılırsa sorun kesin olarak tek eklenti midir?</h3><p>Eklenti katmanının sorunla ilişkili olduğunu gösterir. Tek bir bileşen, eklentiler arası etkileşim veya kaynak tüketimi araştırılmalıdır.</p><h3>Belleği 512 MB yapmak her beyaz ekranı çözer mi?</h3><p>Hayır. Sözdizimi hatası, eksik dosya veya uyumsuzluk daha fazla bellekle düzelmez. Limiti hata kaydına göre değerlendirin.</p><h3>Yedekten dönmek en hızlı çözüm mü?</h3><p>Temiz ve çalışan bir yedek yardımcı olabilir. Ancak geri dönüş tarihinden sonraki içerikler ve siparişler kaybolabilir. Veri kaybını ve sorunun tekrar etme ihtimalini birlikte değerlendirin.</p></blockquote><p></p>