# 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.

- Source canonique : [https://allaux.fr/tr/wordpress-woocommerce/erreur-critique](https://allaux.fr/tr/wordpress-woocommerce/erreur-critique)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> wp-config.php içinde WP_DEBUG ve WP_DEBUG_LOG değerlerini true yapın, hata veren sayfayı yeniden yükleyin ve wp-content/debug.log dosyasının son satırını okuyun: hatalı dosyayı ve satırı orada bulursunuz. Yönetim paneline erişemiyorsanız, site yönetim adresine gelen “Sitenizde teknik bir sorun yaşanıyor” e-postasını açın: WordPress kurtarma moduna giden bağlantı oradadır.

## Nasıl ilerliyorum

1. **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.
2. **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.
3. **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.
4. **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.
5. **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_LIMIT değ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ın functions.php dosyası.

## 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.

## wp-config.php

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

## İçerikleriniz kaybolmaz

> Kritik bir hata görüntülemeyi engeller, ancak yazılarınızı, siparişlerinizi veya veritabanınızı silmez. Sorumlu dosya veya eklenti düzeltilir düzeltilmez ortadan kalkar.

## İlgili sayfalar

- **WordPress hata ayıklama modunu açmak** — Kritik hata ekranının arkasındaki gerçek mesajı okumak için. ([/guides/activer-mode-debug-wordpress](/guides/activer-mode-debug-wordpress))
- **WooCommerce hata günlüklerini okumak** — Günlük dosyaları nerede ve içinde işe yarayan satır nasıl bulunur. ([/guides/lire-logs-erreurs-woocommerce](/guides/lire-logs-erreurs-woocommerce))
- **Başarısız bir güncellemeden sonra geri dönmek** — Hata bir güncellemenin hemen ardından ortaya çıktığında. ([/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee](/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee))
- **Güncelleme sonrası eklenti çakışması** — Her şeyi rastgele kapatmadan sorumlu eklentiyi yalıtmak. ([/wordpress-woocommerce/problemes/conflit-extensions-apres-mise-a-jour](/wordpress-woocommerce/problemes/conflit-extensions-apres-mise-a-jour))
- **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. ([/wordpress-woocommerce/mise-a-jour/php-wordpress](/wordpress-woocommerce/mise-a-jour/php-wordpress))
- **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. ([/problemes/erreur-500-d-ou-vient-elle](/problemes/erreur-500-d-ou-vient-elle))

## FAQ

### Yazılarımı veya siparişlerimi kaybetme riski var mı?

Hayır. Kritik hata sayfaların görüntülenmesini engeller, veritabanını bozmaz. İçerikleriniz, siparişleriniz ve müşterileriniz olduğu gibi kalır.

### Hiçbir şeye dokunmadığım halde site neden kendiliğinden bozuldu?

Bu sık görülen bir durum: bir eklentinin otomatik güncellenmesi veya barındırma sağlayıcısının önceden haber vermeden yaptığı bir PHP sürüm yükseltmesi, aylardır sorunsuz çalışan bir siteyi bozmaya yeter.

### Bana hangi erişimleri sağlamam gerekir?

Dosyaları ve logları okuyabilmem için FTP veya SSH erişimi ile veritabanı erişimi. wp-admin erişilebilir durumdaysa, bu bilgiler de yardımcı olur ama şart değildir.

### Siteyi yeniden yayına almak ne kadar sürer?

Çoğu durumda, erişimler sağlandıktan sonra sorumlu eklenti veya dosyanın tespiti bir saatten kısa sürede yapılır. Düzeltmenin kendisi ise neyin bozulduğuna bağlıdır.

### Bunun tekrar yaşanmasını nasıl önleyebilirim?

Hassas eklentilerin otomatik güncellemelerini sınırlayabilir ve güncellemeleri canlı ortama uygulamadan önce doğrulamak için bir test ortamı kurabilirim.

### Kurtarma modu e-postası gelmezse ne yapmalıyım?

Önce WordPress genel ayarlarındaki, çoğu zaman güncel olmayan yönetici adresinin istenmeyen klasörüne bakın. Hiçbir şey gelmiyorsa FTP’yi ya da barındırma firmasının dosya yöneticisini kullanın: wp-content/plugins içindeki sorunlu eklentinin klasörünü yeniden adlandırmak onu hemen devre dışı bırakır ve ayarları veritabanında kalır.