WordPress kritik hata verdiğinde ne yapılır? Debug log ve kurtarma modu

WordPress kritik hata ekranı, sitenizde bir PHP kodu ölümcül hata (fatal error) verdiğinde ve WordPress sayfayı çizemediğinde çıkar. Sorunun kaynağı çoğunlukla bir eklenti, tema, uyumsuz PHP sürümü, yetersiz bellek ya da bozulmuş çekirdek dosyalarıdır. Hatayı kalıcı olarak gidermek için önce yedek alır, ardından log kaydıyla suçluyu bulur ve yalnızca o parçaya müdahale edersiniz.

Aşağıda kurtarma modu e-postasını nasıl kullanacağınızı, debug log dosyasını nasıl okuyacağınızı, panele giremediğinizde eklenti ve temaları nasıl kapatacağınızı ve son çare olarak çekirdek dosyalarını nasıl yenileyeceğinizi sırasıyla bulacaksınız.

WordPress kritik hata nedir ve neden olur?​

Kritik hata ekranı, arka planda PHP'nin ölümcül bir hatayla durduğunu gösterir. — Fotoğraf: Markus Spiske / Pexels
WordPress kritik hata, PHP'nin çalışmayı tamamen durduran bir hatayla karşılaştığını gösteren genel bir uyarıdır. İngilizce kurulumlarda There has been a critical error on this website, Türkçe kurulumlarda ise Bu web sitesinde kritik bir hata oluştu mesajı görünür. Ekran hatanın kendisini değil, yalnızca bir şeylerin çöktüğünü söyler.

WordPress 5.2 sürümüyle gelen hata koruma özelliğinden önce aynı durumda çoğunlukla bembeyaz bir sayfa görülürdü. Bu açıdan kritik hata mesajı, eski WordPress beyaz ekran hatası sorununun daha konuşkan bir halidir. Arka planda yaşanan şey ise aynıdır: bir dosya, var olmayan bir fonksiyonu çağırmış, bir sınıfı iki kez tanımlamış ya da belleği tüketmiştir.

En sık karşılaşılan nedenler şunlardır:

• Eklenti çakışması veya hatalı güncelleme: Yeni sürümdeki bir hata ya da başka bir eklentiyle uyumsuzluk.
• Tema veya functions.php düzenlemesi: Eksik bir noktalı virgül ya da kapanmamış parantez bile siteyi düşürebilir.
• PHP sürümü uyumsuzluğu: Eski bir eklentinin yeni PHP sürümünde kaldırılmış fonksiyonları kullanması ya da tersi.
• Bellek limitinin aşılması: Ağır sayfa oluşturucular ve büyük eklentiler ayrılan belleği aşabilir.
• Bozuk çekirdek dosyaları: Yarıda kalan bir güncelleme veya kötü amaçlı kod bulaşması.

Hatanın 500 sunucu hatasıyla karıştırılması da sık görülür. Tarayıcıda 500 kodu görüyor ama WordPress mesajını görmüyorsanız sorun .htaccess ya da sunucu yapılandırmasında olabilir; bu durum için 500 Internal Server Error çözüm adımlarına bakmanız daha doğru olur.

Müdahaleye başlamadan önce yedek nasıl alınır?​

Herhangi bir dosyayı değiştirmeden önce wp-content klasörünü, wp-config.php dosyasını ve veritabanını yedeklemeniz gerekir. Site zaten çalışmadığı için yedekleme eklentisi kullanamazsınız; bu işi hosting panelinin yedekleme aracı, dosya yöneticisi ve phpMyAdmin üzerinden yaparsınız. Yedek, yanlış bir adımı geri almanın tek güvenli yoludur.

Pek çok kişi panik anında doğrudan dosya silmeye başlar. Diyelim ki suçlu sandığınız eklenti klasörünü sildiniz ama hata devam etti; o eklentinin ayarlarını ve lisans bilgisini de kaybetmiş olursunuz. Bu yüzden her adımda silmek yerine yeniden adlandırmayı tercih edin ve işe şu sırayla başlayın:

1. Hosting panelinizde otomatik yedekleme aracı varsa güncel bir tam yedek oluşturun ya da son sağlıklı yedeğin tarihini not edin.
2. Dosya yöneticisi veya FTP istemcisiyle wp-content klasörünü sıkıştırıp bilgisayarınıza indirin.
3. wp-config.php dosyasının bir kopyasını ayrıca indirin; bu dosyayı birazdan düzenleyeceksiniz.
4. phpMyAdmin'de sitenizin veritabanını seçip Dışa Aktar (Export) seçeneğiyle SQL dosyası olarak kaydedin.

Bu dört dosya elinizdeyse aşağıdaki adımların hiçbiri geri dönüşü olmayan bir zarar bırakmaz.

WordPress kurtarma modu nasıl kullanılır?​

WordPress kurtarma modu, ölümcül hata yakalandığında yönetici e-posta adresine gönderilen özel bir bağlantıyla açılan güvenli giriş ortamıdır. Bu bağlantıyla panele girdiğinizde hatayı veren eklenti veya tema yalnızca sizin oturumunuz için duraklatılır. Böylece dosyalara dokunmadan sorunlu bileşeni devre dışı bırakabilir ya da güncelleyebilirsiniz.

E-postanın konusu genellikle sitenizde teknik bir sorun yaşandığını belirtir. İçeriğinde hatanın hangi eklenti veya temadan kaynaklandığı, hatanın hangi dosyanın hangi satırında oluştuğu ve kurtarma modu bağlantısı yer alır. Bağlantının geçerlilik süresi sınırlıdır, bu yüzden e-postayı gördüğünüzde vakit kaybetmeden kullanın.

Kurtarma modunda yapılacaklar​

1. E-postadaki bağlantıya tıklayın ve normal yönetici bilgilerinizle giriş yapın.
2. Panelin üst kısmında kurtarma modunda olduğunuzu belirten bir uyarı göreceksiniz. Eklentiler sayfasına gidin.
3. Duraklatılmış olarak işaretlenen eklentiyi bulun. Güncellemesi varsa güncelleyin, yoksa devre dışı bırakın.
4. Sorun temadaysa Görünüm > Temalar bölümünden varsayılan bir temaya geçin.
5. İşiniz bitince üst çubuktaki Kurtarma Modundan Çık seçeneğine tıklayın ve siteyi gizli pencerede kontrol edin.

Kurtarma e-postası gelmiyorsa ne yapmalı?​

E-posta hiç gelmeyebilir. Bunun en yaygın nedeni, Ayarlar > Genel bölümündeki yönetici adresinin artık kullanılmayan bir adres olması ya da sunucunun PHP mail fonksiyonuyla gönderim yapamamasıdır. Önce istenmeyen klasörünü kontrol edin. Gelecekte e-postanın farklı bir adrese gitmesini istiyorsanız wp-config.php dosyasına şu satırı ekleyebilirsiniz:


Şu anda e-postaya ulaşamıyorsanız beklemeye gerek yok. Bir sonraki adım olan debug modu, aynı bilgiyi doğrudan sunucudan almanızı sağlar.

WordPress debug modu nasıl açılır ve log nasıl okunur?​

WordPress debug modu, wp-config.php dosyasına eklenen birkaç satırla hataların wp-content klasöründeki debug.log dosyasına yazılmasını sağlar. Hatayı ziyaretçilere göstermeden kaydetmek için WP_DEBUG ve WP_DEBUG_LOG açılır, WP_DEBUG_DISPLAY kapatılır. Log dosyası, kritik hatanın hangi eklenti, tema veya dosya satırından geldiğini açıkça gösterir.

wp-config debug ayarları​

Dosya yöneticisinde sitenin kök dizinindeki wp-config.php dosyasını açın. Dosyada zaten define( 'WP_DEBUG', false ); satırı varsa onu silin ve yerine aşağıdaki bloğu yapıştırın. Blok, That's all, stop editing ifadesinin geçtiği yorum satırının üstünde olmalıdır; Türkçe kurulumlarda bu satırın karşılığı düzenlemeyi bırakmanızı söyleyen yorumdur.


Dosyayı kaydedin ve sitenizi tarayıcıda bir kez yenileyin. Hatanın tekrar tetiklenmesi, log dosyasının oluşması için gereklidir. Ardından wp-content/debug.log dosyasını açın.

Log satırını doğru yorumlamak​

Dosyada onlarca uyarı (Notice, Warning, Deprecated) görebilirsiniz. Bunlar çoğunlukla siteyi düşürmez. Aramanız gereken şey PHP Fatal error ile başlayan satırdır. Örnek bir kayıt şöyle görünür:


Bu satırda üç bilgi vardır: hatanın türü (tanımsız fonksiyon çağrısı), dosya yolu ve satır numarası. Yolun içinde /plugins/ornek-eklenti/ geçiyorsa suçlu o eklentidir. /themes/tema-adi/ geçiyorsa temaya, /wp-includes/ veya /wp-admin/ geçiyorsa çekirdeğe ya da çekirdeği yanlış kullanan bir eklentiye bakarsınız. Allowed memory size of ... exhausted ifadesi ise bellek limitinin aşıldığını gösterir.

Debug sürecinde pluggable.php gibi çekirdek dosyalarının adı geçen hatalarla karşılaşırsanız, pluggable.php hatası ve debugging çözümü konusundaki örnekler işinize yarayabilir.

Sorunu çözdükten sonra debug ayarlarını yeniden false yapmayı ve debug.log dosyasını silmeyi ihmal etmeyin. Bu dosya herkese açık bir dizinde durur ve sunucu yolları gibi hassas bilgiler içerir.

Panele giremiyorsanız eklentiler nasıl devre dışı bırakılır?​

Panele giremediğinizde eklentileri FTP veya dosya yöneticisinden klasör adını değiştirerek kapatabilirsiniz. — Fotoğraf: Digital Buggu / Pexels
Panele erişim yoksa eklentileri FTP veya hosting dosya yöneticisi üzerinden, klasör adlarını değiştirerek devre dışı bırakırsınız. WordPress, adı değişen bir eklenti klasörünü bulamadığında o eklentiyi otomatik olarak pasif hale getirir. Bu yöntem eklenti dosyalarını ve veritabanındaki ayarları silmez, geri dönüş kolaydır.

Tek eklentiyi kapatmak​

Log dosyası suçluyu net gösteriyorsa yalnızca o eklentiye dokunun:

1. wp-content/plugins/ dizinine girin.
2. Logda adı geçen klasörü bulun, örneğin ornek-eklenti.
3. Klasörün adını ornek-eklenti-kapali olarak değiştirin.
4. Siteyi yenileyin. Açıldıysa panelden eklentinin güncel sürümünü kontrol edin ya da bir alternatif arayın.

Tüm eklentileri birden kapatmak​

Log yoksa veya birden fazla eklentiden şüpheleniyorsanız plugins klasörünün adını plugins-eski yapın. Site açılırsa sorun kesin olarak eklentilerdedir. Klasörün adını tekrar plugins yapın; bu aşamada eklentiler pasif görünecektir. Panelden eklentileri tek tek etkinleştirip her seferinde siteyi kontrol edin. Hangi eklentiden sonra hata dönerse suçlu odur.

Çok sayıda eklentiyi yeniden kurmanız gerekirse WordPress'te toplu eklenti yükleme yöntemleri zaman kazandırır.

Dosya yöneticisine de erişemiyorsanız phpMyAdmin'de wp_options tablosundaki active_plugins satırının değerini a:0:{} yaparak tüm eklentileri kapatabilirsiniz. Tablo öneki kurulumunuza göre wp_ yerine farklı olabilir. Bu değişiklikten önce mevcut değeri bir not dosyasına kopyalayın.

Sorun temadan kaynaklanıyorsa ne yapmalı?​

Kritik hata temadan geliyorsa aktif temanın klasör adını değiştirerek WordPress'i varsayılan temaya düşürürsünüz. Bunun çalışması için wp-content/themes dizininde Twenty Twenty-Five gibi resmi bir varsayılan temanın yüklü olması gerekir. Hiç varsayılan tema yoksa önce birini klasör olarak yüklemeniz gerekir.

Tema kaynaklı hataların büyük kısmı functions.php dosyasına yapıştırılan kod parçacıklarından çıkar. Diyelim ki bir rehberden bulduğunuz kodu tema düzenleyicisine eklediniz ve kaydet düğmesine bastığınız anda site çöktü. Bu durumda temayı tamamen kapatmak yerine dosya yöneticisinden wp-content/themes/tema-adi/functions.php dosyasını açıp eklediğiniz son kodu silmek yeterlidir. Log satırındaki satır numarası size doğrudan yeri gösterir.

Alt tema (child theme) kullanıyorsanız önce alt temanın klasörünü kontrol edin; özel kodlar genellikle oradadır. Ana temayı güncelledikten sonra hata başladıysa alt temadaki şablon dosyalarının ana temanın yeni yapısıyla uyumsuz hale gelmiş olması da mümkündür.

PHP sürümü ve bellek limiti kritik hataya neden olur mu?​

Evet. Eklentilerin veya temanın desteklemediği bir PHP sürümü ve yetersiz bellek limiti, WordPress kritik hata ekranının en yaygın sunucu kaynaklı nedenleridir. Hosting firması PHP sürümünü güncellediğinde ya da siz yeni ve ağır bir eklenti kurduğunuzda, kodun hiç değişmemesine rağmen site çökebilir.

PHP sürümünü değiştirmek​

PHP'nin yeni ana sürümleri bazı eski fonksiyonları tamamen kaldırır. Uzun süredir güncellenmeyen bir eklenti bu fonksiyonları kullanıyorsa yeni sürümde ölümcül hata verir. Tersi de geçerlidir: güncel bir eklenti, eski bir PHP sürümünde bulunmayan dil özelliklerine ihtiyaç duyabilir.

PHP sürümünü genellikle hosting panelinizdeki PHP sürümü seçici veya MultiPHP yöneticisi gibi bir araçtan değiştirirsiniz; aracın adı sağlayıcınıza ve panel sürümünüze göre farklı olabilir. Hata PHP güncellemesinden hemen sonra başladıysa geçici olarak bir önceki sürüme dönün, siteyi açın ve ardından uyumsuz eklentiyi güncelleyip tekrar yeni sürüme geçin. Eski sürümde kalıcı olarak beklemek güvenlik açısından iyi bir fikir değildir.

Bellek limitini artırmak​

Log dosyasında Allowed memory size exhausted ifadesini gördüyseniz wp-config.php dosyasına şu satırı ekleyebilirsiniz:


Bu ayar, sunucunun izin verdiği üst sınırı aşamaz. Hosting tarafındaki memory_limit değeri daha düşükse panelden veya destek ekibi aracılığıyla artırmanız gerekir. Bellek ayarlarının php.ini ve .htaccess üzerinden nasıl yapıldığını WordPress PHP bellek limiti hatası konusunda ayrıntılı bulabilirsiniz.

Bellek artırmak bazen sorunu çözmez, yalnızca erteler. Tek bir eklenti sürekli belleği tüketiyorsa asıl çözüm o eklentiyi değiştirmektir.

WordPress çekirdek dosyaları nasıl yenilenir?​

Çekirdek dosyalarını yenilemek için sitenizdeki sürümle aynı WordPress paketini resmi WordPress.org sitesinden indirip yalnızca wp-admin ve wp-includes klasörlerini sunucudakilerin üzerine yazarsınız. wp-content klasörü ve wp-config.php dosyası değiştirilmez. Bu işlem yarıda kalan güncellemeleri ve bozulmuş dosyaları onarır.

Bu adıma ancak eklenti, tema ve sunucu ayarlarını eledikten sonra geçin. Log dosyasında hata yolu doğrudan wp-includes içindeki bir dosyayı gösteriyor ve hiçbir eklenti adı geçmiyorsa çekirdek bozulmuş olabilir.

1. Mevcut sürümü öğrenmek için wp-includes/version.php dosyasını açın ve $wp_version değerini not edin.
2. Aynı sürümün zip paketini resmi WordPress.org sürüm arşivinden indirin ve bilgisayarınızda açın.
3. Paketteki wp-content klasörünü silin; sunucudaki içeriğinizin üzerine yazılmasını istemezsiniz.
4. Sunucudaki wp-admin ve wp-includes klasörlerini yeniden adlandırın, örneğin sonuna -eski ekleyin.
5. Paketteki wp-admin ve wp-includes klasörlerini yükleyin, kök dizindeki tekil PHP dosyalarını da (wp-config.php hariç) üzerine yazın.
6. Siteyi kontrol edin. Panel bir veritabanı güncellemesi isterse onaylayın. Her şey yolundaysa -eski klasörlerini silin.

Çekirdek dosyaları, siz hiçbir şey yapmadığınız halde değişmişse bu bir güvenlik işareti olabilir. Bilmediğiniz PHP dosyaları, garip adlı yönetici hesapları veya yönlendirmeler görüyorsanız WordPress sitesine virüs bulaştığında yapılması gerekenler adımlarını uygulamadan çekirdeği yenilemek yeterli olmaz.

Hangi belirti hangi adıma işaret eder?​

Hangi adımdan başlayacağınıza karar vermek için aşağıdaki tablo hızlı bir yol haritası sunar. Sıralama, en az riskli ve en sık sonuç veren yöntemden başlayacak şekilde düşünülmüştür.


Son satırdaki durum aslında farklı bir sorundur. Ekranda kritik hata yerine veritabanı bağlantısı kurulamadığını söyleyen bir mesaj görüyorsanız WordPress veritabanı bağlantı hatası çözüm yolları sizin için daha doğru başlangıç noktası olacaktır.

Kritik hatayı tekrar yaşamamak için ne yapılabilir?​

Kritik hatanın büyük kısmı güncellemelerin canlı sitede, yedeksiz ve toplu biçimde yapılmasından doğar. Güncellemeleri tek tek yapmak, önce bir test ortamında denemek ve düzenli otomatik yedek almak, sorunu yaşasanız bile dakikalar içinde geri dönmenizi sağlar.

Birkaç alışkanlık fark yaratır. Tüm eklentileri aynı anda güncellemek yerine birer birer güncelleyin; böylece hata çıktığında suçluyu aramanıza gerek kalmaz. Hosting firmanız hazırlık (staging) ortamı sunuyorsa büyük güncellemeleri önce orada deneyin. Uzun süredir güncelleme almayan eklentileri alternatifleriyle değiştirin. functions.php dosyasına doğrudan kod eklemek yerine kod parçacığı yönetimi sağlayan bir eklenti kullanmak, hatalı bir kodun siteyi düşürme riskini azaltır.

Yönetici e-posta adresinizin güncel ve aktif olduğundan emin olun. Kurtarma modu e-postası, panele dosya yöneticisi açmadan girmenin en hızlı yoludur ve ancak o adres çalışıyorsa işe yarar.

Sıkça Sorulan Sorular​

WordPress kritik hata verirken ziyaretçiler ne görür?​

Ziyaretçiler yalnızca sitede kritik bir hata oluştuğunu söyleyen kısa bir mesaj görür, hatanın teknik ayrıntılarını görmez. Hata yalnızca belirli bir sayfada oluşuyorsa diğer sayfalar normal açılmaya devam edebilir. Bu yüzden sorunu fark etmek için siteyi gizli pencerede farklı sayfalardan kontrol etmek faydalıdır.

Debug modunu açık bırakmak zararlı mı?​

Evet, uzun süre açık bırakılmamalıdır. debug.log dosyası herkese açık bir dizinde durur ve sunucu yolları, eklenti adları gibi saldırganların işine yarayacak bilgiler içerebilir. Sorunu çözdükten sonra WP_DEBUG değerini false yapın ve log dosyasını silin.

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

Hayır. Klasör adını değiştirdiğinizde eklenti yalnızca pasif hale gelir; veritabanındaki ayarları yerinde kalır. Klasörü eski adına döndürüp eklentiyi yeniden etkinleştirdiğinizde ayarlarınız genellikle aynen geri gelir.

Kritik hata yalnızca yönetim panelinde çıkıyorsa ne yapmalıyım?​

Bu durumda sorun büyük olasılıkla yalnızca panelde çalışan bir eklenti bileşeninden ya da panel sayfası açıldığında yüklenen bir koddan kaynaklanır. Aynı log okuma yöntemini uygulayın ve hatanın oluştuğu dosya yoluna bakın. Ön yüz açıksa ziyaretçileriniz etkilenmez, ancak hatayı yine de kısa sürede gidermeniz gerekir.

Hiçbir adım işe yaramazsa ne yapabilirim?​

Hosting panelinizdeki son sağlıklı yedeğe dönmek en hızlı çözümdür. Yedeğe dönmeden önce mevcut durumun yedeğini de alın ki sonradan eklenen içerikleri kaybetmeyin. Ayrıca debug.log içeriği ve hatanın başladığı zaman bilgisiyle hosting destek ekibine başvurmak, sunucu tarafındaki sorunların hızla tespit edilmesini sağlar.

Kurtarma modu bağlantısının süresi dolduysa ne olur?​

Süresi dolan bağlantı çalışmaz, ancak hata tekrar tetiklendiğinde WordPress belirli aralıklarla yeni bir e-posta gönderebilir. Beklemek yerine doğrudan debug modunu açıp eklenti veya temayı dosya yöneticisinden devre dışı bırakmak çoğu zaman daha hızlıdır.

WordPress kritik hata ekranı ilk bakışta korkutucu görünse de çözümü genellikle sistematik bir eleme işinden ibarettir: önce yedek, sonra log, ardından sorunlu eklenti, tema veya sunucu ayarı. Bu sırayı koruduğunuzda siteyi kalıcı bir zarar görmeden ayağa kaldırırsınız.

Sizin sitenizde kritik hatanın kaynağı hangisi çıktı ve hangi adımda çözdünüz?