WordPress “Bu web sitesinde kritik bir hata oluştu” sorunu nasıl çözülür?

Site veya yönetim paneli “Bu web sitesinde kritik bir hata oluştu” mesajını gösterebilir. Bu, WordPress’in çalışmasını engelleyen ölümcül bir PHP hatasıyla karşılaştığını belirtir. Neden çoğu zaman eklenti/tema uyumsuzluğu, başarısız güncelleme, desteklenmeyen PHP sürümü veya özel kod hatasıdır; mesaj tek başına hangi bileşenin suçlu olduğunu söylemez.

Kısa yanıt: Önce dosya ve veritabanı yedeği alın. Yönetici e-postasındaki Kurtarma Modu bağlantısını kontrol edin. Son yapılan değişikliği geri alın veya eklentileri kontrollü biçimde devre dışı bırakın. Hata kaydını inceleyin; canlı sitede ayrıntılı hataları ziyaretçilere göstermeyin.

Başlamadan önce güvenlik ve veri kaybı önlemleri

• Barındırma panelinden dosyalar ve veritabanının ayrı yedeğini alın.
• Hata çözülmeden WordPress’i yeniden kurmayın ve veritabanını silmeyin.
• Eklenti klasörlerini silmek yerine geçici olarak yeniden adlandırın; böylece geri dönüş yolu korunur.
• Hata kayıtları sunucu yolları ve başka hassas ayrıntılar içerebilir. Herkese açık forumda tam günlük paylaşmayın.

WordPress kritik hatayı adım adım çözme

1. Son değişikliği belirleyin

Hata başlamadan hemen önce eklenti, tema veya WordPress güncellemesi yaptınız mı? PHP sürümü değişti mi? functions.php ya da kod parçacığı düzenlendi mi? Zaman çizelgesini not alın. Tek değişiklikten hemen sonra başlayan hata, teşhisi önemli ölçüde daraltır.

2. Yönetici e-postasını ve spam klasörünü kontrol edin

WordPress 5.2 ile gelen Kurtarma Modu, kritik hata oluştuğunda site yönetici adresine özel bir bağlantı gönderebilir. E-postada sorun çıkaran eklenti veya tema adı ile kurtarma bağlantısı bulunabilir.

1. Yönetici e-posta hesabının gelen, spam ve karantina klasörlerini kontrol edin.
2. Bağlantının alan adınızla başladığını doğrulayın; şüpheli iletide parola girmeyin.
3. Kurtarma Modu’nda oturum açın.
4. WordPress’in duraklattığı eklenti veya temayı inceleyin.
5. Bileşeni devre dışı bırakın, güncelleyin veya geliştirici desteğine hata ayrıntısıyla başvurun.

Kurtarma Modu hatalı bileşeni yalnızca o tarayıcı oturumu için duraklatabilir; bu, bütün ziyaretçiler için sorun çözüldü anlamına gelmez. Eklentiyi düzeltmeden moddan çıkarsanız hata geri dönebilir.

3. Yönetim paneli açılıyorsa eklentileri kontrollü test edin

1. Tüm eklenti listesinin ekran görüntüsünü veya metin kaydını alın.
2. Son güncellenen ya da yeni kurulan eklentiyi devre dışı bırakın.
3. Site ön yüzünü ve yönetim panelini gizli pencerede test edin.
4. Sorun sürüyorsa önbelleği temizleyin; ardından eklentileri tek tek izole edin.
5. Hatalı bileşen belirlenince uyumlu sürüme geçin veya geliştirici desteğine başvurun.

Önbellek eklentisini temizlerken tüm optimizasyon ayarlarını rastgele sıfırlamayın. Değişiklikleri birer birer yapın ve sonuç kaydı tutun.

4. Yönetim paneli açılmıyorsa eklentileri dosya yöneticisinden durdurun

WordPress’in resmî sorun giderme belgesi, panel erişilemediğinde FTP veya barındırma dosya yöneticisiyle wp-content/plugins klasörünün geçici olarak yeniden adlandırılabileceğini açıklar.

1. Yedek aldıktan sonra wp-content klasörünü açın.
2. plugins klasörünü plugins.hold olarak yeniden adlandırın.
3. Yönetim paneline girmeyi deneyin.
4. Panel açılırsa klasör adını yeniden plugins yapın. Eklentiler devre dışı kalır.
5. Eklentileri tek tek etkinleştirip her adımda siteyi test edin.

Klasörü silmeyin. İşlem konusunda emin değilseniz barındırma desteğinden yardım isteyin. Veritabanındaki active_plugins kaydını elle değiştirme yöntemi de vardır, ancak phpMyAdmin deneyimi olmayan kullanıcının doğrudan uygulaması önerilmez.

5. Tema ihtimalini kontrol edin

Hata tema güncellemesi veya functions.php düzenlemesinden sonra başladıysa aktif temayı geçici olarak devre dışı bırakmak gerekebilir. En az bir güncel varsayılan WordPress teması kuruluysa WordPress ona dönebilir. Tema klasörünü yeniden adlandırmadan önce çocuk tema, özel kod ve tema ayarlarının yedeğini alın. Safir Neva gibi lisanslı temalarda uyumlu güncelleme ve geliştirici desteğini kontrol edin.

6. Hata günlüğünü güvenli biçimde oluşturun

WordPress belgeleri, WP_DEBUG_LOG ile hataların genellikle wp-content/debug.log dosyasına yazılabileceğini belirtir. Canlı sitede hata ayrıntılarını ekrana basmak güvenli değildir. Geçici teşhis gerekiyorsa yedek aldıktan sonra wp-config.php dosyasında “Hepsi bu, düzenlemeyi bırakın” satırından önce şu ayarlar kullanılabilir:

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

Hatayı bir kez yeniden üretin, sonra wp-content/debug.log içindeki en yeni satırları inceleyin. Eklenti/tema yolu, PHP işlevi veya bellek hatası ipucu verebilir. Teşhis bittiğinde WP_DEBUG değerini kapatın ve erişilebilir günlük dosyasını güvenli biçimde kaldırın. WordPress, debug araçlarının canlı sitede sürekli açık tutulmasını önermiyor.

7. PHP ve kaynak sınırlarını doğrulayın

• Barındırma panelindeki PHP sürümünün WordPress, tema ve eklentiler tarafından desteklendiğini kontrol edin.
• “Allowed memory size exhausted” görüyorsanız yalnızca bellek sınırını yükseltmek yerine hangi eklentinin tüketimi artırdığını araştırın.
• “Call to undefined function” veya dosya yolu içeren hata, uyumsuz ya da eksik bileşeni gösterebilir.
• Sunucu düzeyinde 500 hatası varsa barındırma hata günlüğünü ve destek ekibini kullanın.

8. Çözümden sonra doğrulama yapın

1. Ana sayfa, bir yazı, kategori, arama ve iletişim formunu kontrol edin.
2. Mobil görünümü ve yönetici girişini sınayın.
3. Önbelleği temizleyip tekrar test edin.
4. Site Sağlığı ekranını inceleyin.
5. Yeni tam yedek alın ve yapılan değişiklikleri not edin.

Çözüm işe yaramazsa sonraki adımlar

• Çalışan son yedeği doğrudan canlı sitenin üzerine yazmadan önce staging ortamında geri yükleyin.
• Barındırma desteğine hata zamanı, PHP sürümü ve günlüğün ilgili birkaç satırını iletin; parola veya tam veritabanı paylaşmayın.
• Çekirdek dosyaları hasarlı görünüyorsa manuel değişiklik yerine resmî WordPress paketinden güvenli yeniden kurulum için uzman desteği alın.
• Hata şüpheli dosya, bilinmeyen yönetici veya yönlendirme ile birlikteyse bunu uyumluluk sorunu değil olası güvenlik olayı olarak ele alın.

Sık sorulan sorular

Kurtarma Modu bağlantısı neden gelmedi?

Yönetici e-posta adresi yanlış olabilir, sunucu e-posta gönderemiyor olabilir veya ileti spam/karantinaya düşmüş olabilir. Panel açılmıyorsa dosya yöneticisi ve barındırma günlükleriyle ilerleyin.

plugins klasörünün adını değiştirmek ayarları siler mi?

WordPress belgesindeki yöntem eklentileri devre dışı bırakır ve dosyaları korur; yine de işlem öncesi yedek alın. Klasörü silmek aynı şey değildir.

WP_DEBUG sürekli açık kalabilir mi?

WordPress, debug araçlarını canlı sitede sürekli kullanmayı önermez. Teşhis için geçici açın, hataları ziyaretçiden gizleyin ve işlem bitince kapatın.

İlginizi çekebilir

Kurtarma sonrası yönetici hesabını güvene almak için göz atabilirsiniz WordPress yönetici hesabını koruma: Yetki kontrolü, güçlü parola ve iki aşamalı doğrulama

Resmî kaynaklar

• WordPress.org — Recovery Mode
• WordPress Developer Resources — Common WordPress errors
• WordPress Developer Resources — Debugging in WordPress
• WordPress.org — FAQ Troubleshooting