Web sitenizde kritik bir hata oluştu mesajını gördüğünüzde panik yapmanıza gerek yok. Bu ekran, WordPress 5.2 sürümüyle gelen hata yakalama sisteminin ürünüdür ve aslında yardımcı olmak için vardır: sitenizi tamamen boş bırakmak yerine hatayı yakalar, yöneticiye e-posta atar ve sorunlu parçayı geçici olarak devre dışı bırakacak bir yol sunar. Aşağıdaki adımlar, en az müdahale gerektirenden en çok müdahale gerektirene doğru sıralıdır. Sırayı bozmayın, çünkü ilk adımlar hiçbir dosyaya dokunmadan sorunu çözebilir.
Kritik hata ekranı tam olarak ne anlama gelir?
WordPress 5.2'den itibaren, PHP'de bir ölümcül hata oluştuğunda çekirdek bunu yakalar ve ziyaretçiye genel bir hata mesajı gösterir. Mesajın İngilizcesi "There has been a critical error on this website", Türkçesi "Web sitenizde kritik bir hata oluştu" şeklindedir ve yönetici e-postasına bakılmasını söyler. Yönetici adresine gönderilen e-posta hata türünü, hataya sebep olan dosyayı ve gizli bir kurtarma modu bağlantısını içerir. WordPress geliştirici ekibinin açıklamasına göre bu bağlantı tarayıcınıza bir çerez yerleştirir ve yalnızca o tarayıcıda, hataya sebep olan eklenti veya temayı duraklatarak yönetim paneline girmenizi sağlar.
Bu sistem, WordPress 5.2 öncesindeki "beyaz ekran" davranışının yerini aldı. Eski sürümlerde ya da hata yakalayıcı devre dışıyken hâlâ tamamen boş sayfa görebilirsiniz. İki durumun farkını beyaz ekran rehberinde ayrıca anlattık.
Kritik hata neden oluşur?
| Neden | Tipik belirti | Nasıl anlaşılır |
|---|---|---|
| Eklenti ölümcül hatası | Bir eklenti güncellemesi ya da kurulumu sonrası başlar | E-postada ve günlükte yol wp-content/plugins/... gösterir |
| Tema hatası | Tema güncellemesi veya functions.php düzenlemesi sonrası | Yol wp-content/themes/... gösterir |
| Bellek yetersizliği | Ağır sayfalarda ya da içe aktarmada | Günlükte Allowed memory size exhausted yazar |
| PHP sürümü uyumsuzluğu | Hosting PHP sürümünü yükselttikten sonra | Günlükte Call to undefined function veya deprecated uyarıları |
| Bozuk çekirdek dosyası | Yarım kalmış güncelleme ya da dosya aktarımı | Hata yolu wp-includes veya wp-admin içinde |
| Eksik PHP modülü | Hosting taşıması sonrası | Günlükte Class not found veya Call to undefined function |
Özellikle bir güncellemenin hemen ardından hata geldiyse güncelleme sonrası site bozulduğunda yapılacaklar sayfası, güncelleme odaklı bir yol haritası sunar. Hata yalnızca blok düzenleyicide çıkıyorsa (yayınlama başarısız, geçerli bir JSON yanıtı değil gibi mesajlar) düzenleyici beklenmeyen hata yazısına bakın.
Yönetici e-postasındaki kurtarma bağlantısı nasıl kullanılır?
E-posta, Ayarlar > Genel'deki yönetici e-posta adresine gelir; wp-config.php içinde RECOVERY_MODE_EMAIL sabiti tanımlıysa o adrese gider. Çok siteli (multisite) kurulumlarda ağ genelinde etkinleştirilmiş bir eklentinin hatası kurtarma moduna alınmaz, bu durumda aşağıdaki FTP yöntemini kullanın. Konusu genellikle "Siteniz teknik sorun yaşıyor" gibidir. Önce spam klasörüne bakın. İçindeki bağlantıya tıklayıp giriş yaptıktan sonra panelin üstünde kurtarma modunda olduğunuzu belirten bir bildirim görürsünüz.
- 1E-postayı açın, hatanın hangi eklenti ya da temadan kaynaklandığını okuyun.
- 2Kurtarma modu bağlantısına tıklayıp yönetici hesabınızla giriş yapın.
- 3Eklentiler (veya Görünüm) sayfasında sorunlu parçanın duraklatıldığını göreceksiniz. Devre dışı bırakın ya da güncelleyin.
- 4Üst çubuktaki kurtarma modundan çıkış düğmesine basın ve siteyi normal bir pencerede kontrol edin.
E-posta gelmediyse nedenleri şunlardır: yönetici adresi eski ya da yanlış, sunucu e-posta göndermiyor, ya da mesaj spam'e düştü. Aynı e-posta tekrar tekrar gönderilmez, o yüzden sonraki adımlara geçin.
Hatanın sebebini hata günlüğünden nasıl bulurum?
E-posta gelmediyse ya da yeterince ayrıntı vermiyorsa, hata ayıklama modunu günlüğe yazacak şekilde açın. wp-config.php dosyasında şu satırlar yeterlidir:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Sayfayı yenileyin ve wp-content/debug.log dosyasının son satırlarını okuyun. "PHP Fatal error" ile başlayan satır ve sonundaki dosya yolu asıl bilgidir. Modu canlı sitede güvenle kullanma, günlük dosyasını korumasız bırakmama ve satırları yorumlama konusunda WP_DEBUG rehberine bakın. Ayrıca hatayı ham haliyle görmek istiyorsanız WP_DISABLE_FATAL_ERROR_HANDLER sabiti, kurtarma modunun hatayı gizlemesini engelleyen bir ayardır, ama yalnızca geliştirme ortamında kullanın.
Panele giremiyorsam eklenti ve temayı nasıl devre dışı bırakırım?
Bu en güvenilir yöntemdir ve hosting dosya yöneticisi ya da FTP gerektirir. İlk önce yedeğinizin olduğundan emin olun.
- 1
wp-content/pluginsklasörünüplugins-kapaliolarak yeniden adlandırın. WordPress tüm eklentileri devre dışı bırakır. Siteyi yenileyin. - 2Site açıldıysa önce wp-admin'de Eklentiler sayfasını (
plugins.php) bir kez açın: WordPress dosyası bulunamayan eklentileri etkin listeden ancak bu sayfa yüklendiğinde çıkarır. Bu adımı atlayıp klasörü eski adına çevirirseniz tüm eklentiler yeniden etkinleşir ve site aynı hatayla çöker. Sonra klasörü eski adına çevirin, eklentileri panelden tek tek etkinleştirip hangisinde hatanın döndüğünü bulun (ayrıntısı güncelleme sonrası site bozuldu rehberinde). Daha hızlısı, günlükte geçen eklentinin klasör adını değiştirmektir. - 3Site hâlâ açılmıyorsa
wp-content/themesiçinde aktif temanın klasörünü yeniden adlandırın. WordPress mevcut başka bir temaya (örneğin varsayılan Twenty serisi) döner. Böyle bir tema yüklü değilse önce yükleyin.
SSH erişiminiz varsa WP-CLI aynı işi saniyeler içinde yapar:
wp plugin deactivate --all --skip-plugins
wp plugin deactivate sorunlu-eklenti --skip-plugins
wp theme activate twentytwentyfive --skip-plugins --skip-themesBir eklentiyi güncelledikten sonra kritik hata aldıysanız ve eski sürüme dönmek istiyorsanız eklenti güncellemesini geri alma rehberine bakın.
PHP sürümü ve bellek limiti nasıl kontrol edilir?
Hata, hosting PHP sürümünü yükselttikten sonra başladıysa eski kodlu bir eklenti ya da tema yeni sürümle uyumsuz olabilir. Hosting panelinde (cPanel'de "MultiPHP Manager", Plesk'te "PHP Ayarları") siteniz için bir önceki PHP sürümüne dönün ve sorunun kaybolup kaybolmadığına bakın. Kaybolduysa kalıcı çözüm uyumsuz eklentiyi güncellemek ya da değiştirmektir. Eski sürümde kalmak güvenlik riskidir, çünkü destek süresi dolmuş PHP sürümleri güvenlik yaması almaz.
Günlükte "Allowed memory size exhausted" görüyorsanız bellek sınırını yükseltin. WordPress belgelerine göre varsayılan limit tek siteli kurulumda 40 MB'tır. wp-config.php dosyasına şunu ekleyin:
define( 'WP_MEMORY_LIMIT', '256M' );Hosting planınızın izin verdiği PHP bellek limiti bundan düşükse bu satır etkisiz kalır. O zaman memory_limit değerini panelden ya da destekten yükseltin.
Hâlâ çözülmediyse hosting günlüğüne ve çekirdek dosyalarına nasıl bakılır?
WordPress günlüğü boşsa hata WordPress yüklenmeden önce oluşmuş olabilir. Hosting panelindeki PHP hata günlüğüne (Error Logs) bakın. Orada bir modülün eksikliği, .htaccess hatası ya da sunucu düzeyinde bir sorun görünür. Çekirdek dosyalardan şüpheleniyorsanız WP-CLI ile içeriğe dokunmadan çekirdeği yeniden indirebilirsiniz:
wp core verify-checksums
wp core download --force --skip-contentİlk komut çekirdek dosyalarını resmi sağlama toplamlarıyla karşılaştırır, ikincisi wp-content ve wp-config.php'ye dokunmadan çekirdeği yeniler. Hiçbiri işe yaramadıysa son çare, kaybetmeyi göze alabileceğiniz bir noktaya dönmektir. Yedekten geri yükleme rehberi, yanlış geri yükleme yüzünden veri kaybetmemeniz için adımları açıklar.
Kritik hata tekrar etmesin diye ne yapabilirim?
Kritik hataların büyük çoğunluğu bir değişiklikten hemen sonra gelir: güncelleme, yeni eklenti, elle düzenlenen bir dosya ya da hosting tarafında PHP sürümü değişimi. Bu yüzden önlem de değişikliği güvenli hale getirmektir. Güncellemeden önce yedek alın, güncellemeleri tek seferde değil tek tek uygulayın, yönetici e-posta adresinizin gerçekten okuduğunuz bir kutu olduğunu doğrulayın ve yapılandırmanızı arada Site Sağlığı ekranından kontrol edin. Eski PHP sürümü ve bekleyen güncellemeler orada kritik ya da önerilen olarak görünür.
Sık sorulan sorular
Kritik hata siteme yalnızca yönetici olarak mı görünür?
Hayır. Ziyaretçiler de aynı genel mesajı görür. Kurtarma modu yalnızca bağlantıyı kullanan tarayıcıda hatalı parçayı duraklatır, diğer ziyaretçiler hata ekranını görmeye devam eder.
Kritik hata e-postası ne kadar geçerlidir?
Kurtarma bağlantısı varsayılan olarak 1 gün geçerlidir ve WordPress varsayılan olarak günde en fazla bir kurtarma e-postası gönderir. Geliştiriciler bu süreleri recovery_mode_email_link_ttl ve recovery_mode_email_rate_limit filtreleriyle değiştirebilir. Süre dolduysa FTP ile eklenti klasörünü yeniden adlandırma yöntemini kullanın, bu hiçbir e-postaya ihtiyaç duymaz.
Hata yalnızca ön yüzde mi çıkıyor, panel çalışıyor mu?
Bu da sık görülür. Panel çalışıyorsa tema, ön yüze özgü bir eklenti ya da önbellek sorumlu olabilir. Önce temayı varsayılana çevirin, ardından eklentileri dışlayın.
Kurtarma modundan nasıl çıkılır?
Yönetim panelinin üst çubuğundaki kurtarma modundan çıkış düğmesine basın. Bu yalnızca sizin tarayıcınızdaki kurtarma oturumunu kapatır. Sorunlu eklentiyi ya da temayı devre dışı bırakmadıysanız veya güncellemediyseniz ziyaretçiler hatayı görmeye devam eder, bu yüzden çıkmadan önce sorunun kaynağını giderin.
Güncellemeyi yedekle uygulayın, sorunda geri dönün
Güvenli güncelle, her güncellemeden önce yedek alır ve kritik hata gibi bir sorun çıkarsa dosyaları tek tıkla önceki sürüme çeker. Sürüm kilitleme ile sorunlu eklentiyi sabit sürümde tutabilirsiniz.
- WordPress Core: Fatal error recovery mode in 5.2
- WordPress Developer Resources: recovery_mode_email_link_ttl
- WordPress Developer Resources: recovery_mode_email_rate_limit
- WordPress Developer Resources: wp-config.php
- WordPress Developer Resources: Debugging in WordPress
- WP-CLI: wp core verify-checksums
Erdinç
Watch Your WP'yi geliştiriyor. WordPress bakım, güvenlik ve site yönetimi deneyiminden yazıyor.
LinkedIn