WordPress sitenizde “Kritik hata” mesajı
“Bu sitede bir kritik hata oluştu” mesajı varsayılan olarak hiçbir ayrıntı vermez: bu bilinçli bir tercihtir, WordPress hassas bilgileri açığa çıkarmamak için gerçek hatayı gizler. Neyin düzeltilmesi gerektiğini anlamak için hatayı loglardan bulmak gerekir.
Nasıl ilerliyorum
-
Hata ayıklamayı etkinleştirme
Genel mesaj yerine gerçek hatanın wp-content/debug.log dosyasında görünmesini sağlamak için wp-config.php içinde WP_DEBUG ve WP_DEBUG_LOG değerlerini true olarak ayarlıyorum.
-
PHP hatasının okunması
Tam izi okuyorum: sorumlu dosya, satır ve fonksiyon. Çoğu zaman, bir eklentide veya temada kullanımdan kaldırılmış bir fonksiyon ya da eksik bir dosya söz konusudur.
-
Yeniden adlandırarak izolasyon
Şüpheli eklentinin klasörünü (veya tüm wp-content/plugins klasörünü) yeniden adlandırarak, bu durumda genellikle erişilemeyen yönetim arayüzüne gerek kalmadan devre dışı bırakıyorum.
-
Uyumluluk kontrolü
Sunucunun PHP sürümünü kontrol ediyorum: birçok kritik hata, barındırma sağlayıcısının otomatik olarak yükselttiği ve eski bir eklentiyle uyumsuz olan PHP sürümü sonrasında ortaya çıkar.
-
Düzeltme ve yeniden yayına alma
Sorumlu öğeyi düzeltiyor, güncelliyor veya değiştiriyor, aktif önbellekleri (önbellek eklentisi, sunucu önbelleği) temizliyor ve WP_DEBUG değerini tekrar false olarak ayarlıyorum.
debug.log’u okumak: son satır ne söylüyor
WordPress sürümüne göre ekranda “kritik hata” mesajı ya da benzer bir ifade görünür; arkasında, günlükteki işe yarar satır PHP Fatal error ile başlar. Satırda geçen yol suçluyu gösterir: eklenti için wp-content/plugins/eklenti-adi/, tema için wp-content/themes/tema-adi/. En sık karşılaştığım mesajlar:
Uncaught Error: Call to undefined function: eklenti, sunucunun PHP sürümünde artık bulunmayan ya da bağlı olduğu ve devre dışı bırakılmış bir eklentiye ait bir fonksiyonu çağırıyor — örneğin WooCommerce kapalıyken bir WooCommerce eklentisi.Allowed memory size of … bytes exhausted: bellek sınırına ulaşıldı.WP_MEMORY_LIMITdeğerini artırmak siteyi açar, ama bu kadar belleği neyin tükettiğini bulmak gerekir.Cannot redeclare: iki eklenti ya da iki kez kurulmuş bir eklenti aynı fonksiyonu tanımlıyor.Failed opening required: bir dosya eksik; yarıda kalmış bir güncellemenin tipik işareti. Eklentinin aynı sürümünü yeniden kurmak çoğu zaman yeterlidir.syntax error, unexpected: bir dosya elle değiştirilmiş; çoğunlukla yönetim panelindeki dosya düzenleyiciyle temanınfunctions.phpdosyası.
FTP erişimi yoksa: kurtarma modu ve sınırları
5.2 sürümünden beri, bir eklenti ya da tema ölümcül bir hataya yol açtığında WordPress, yönetici e-posta adresine kurtarma modunda giriş bağlantısı içeren bir ileti gönderir. Bu bağlantı, sorunlu öğeyi duraklatarak yönetim panelini açar; böylece FTP olmadan devre dışı bırakabilirsiniz. Bağlantı geçicidir ve yönetici adresi güncel değilse ya da site e-posta gönderemiyorsa hiç gelmez. Bu durumda eklenti klasörünü FTP ile ya da barındırma firmasının dosya yöneticisinden yeniden adlandırmak en güvenli yol olmaya devam eder.
Kritik hata yalnızca sepet ya da ödeme sayfasında görünüyorsa, suçlu neredeyse her zaman yalnızca bu adımda çağrılan ödeme ağ geçidi ya da bir kargo eklentisidir: bkz. WooCommerce ödeme sorunu. Aynı belirti başka bir platformda görülüyorsa, mekanizma 500 hatası nereden gelir sayfasında anlatılıyor.
Düzenli olarak ele aldığım durumlar
- “Bu WordPress sitesinde bir kritik hata oluştu” mesajı
- Sitenin ön yüzünde veya yönetim panelinde tam beyaz ekran
- Bir eklenti veya WordPress'in otomatik güncellemesinin hemen ardından ortaya çıkan hata
- Görünürde hiçbir işlem yapılmadan çalışan sitenin bozulması, genellikle barındırma sağlayıcısının sessiz bir PHP güncellemesi sonrasında
- Sorumlu eklentiyi devre dışı bırakmak için wp-admin'e erişilemiyor
En sık görülen nedenler
Bir WordPress sitesinde kritik hata, büyük çoğunlukla eklentiler arasındaki bir çakışmadan ya da bir eklenti/temanın sunucunun PHP sürümüyle uyumsuzluğundan kaynaklanır. Eski bir eklenti tarafından çağrılan bir fonksiyon, PHP'nin güncel bir sürümünde kaldırılmış olabilir; bu da anında ölümcül bir hataya yol açar.
İkinci sık görülen durum ise yarıda kalan bir güncellemedir: bir eklentinin otomatik güncellenmesi sırasında ağ kesintisi veya zaman aşımı yaşanması, dosyaların yarım yazılmış halde kalmasına neden olur. WordPress bazen bu durumu tespit eder ve takılı kalan bir bakım modunu etkinleştirir (kök dizindeki .maintenance dosyası).
Son olarak, PHP bellek sınırının (WP_MEMORY_LIMIT) aşılması da, özellikle aynı anda çok sayıda eklentinin aktif olduğu veya büyük veri içe aktarma işlemlerinin yapıldığı sitelerde, bu tür bir hataya yol açabilir.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
İlgili sayfalar
-
WordPress hata ayıklama modunu açmak
Kritik hata ekranının arkasındaki gerçek mesajı okumak için.
-
WooCommerce hata günlüklerini okumak
Günlük dosyaları nerede ve içinde işe yarayan satır nasıl bulunur.
-
Başarısız bir güncellemeden sonra geri dönmek
Hata bir güncellemenin hemen ardından ortaya çıktığında.
-
Güncelleme sonrası eklenti çakışması
Her şeyi rastgele kapatmadan sorumlu eklentiyi yalıtmak.
-
WordPress altında PHP’yi güncellemek
Barındırma firmasının PHP yükseltmesi, “hiçbir şeye dokunmadan” çıkan kritik hatanın başlıca nedenidir.
-
500 hatası: her CMS’te aynı mekanizma
Platform ne olursa olsun, ölümcül bir hatanın sunucu tarafında neye yol açtığını anlamak için.
İhtiyacınızı bir dakikada anlatın
Size bir anket daha değil, doğrudan bir tahmin sunabilmem için birkaç hedefli soru.