# WordPress'te debug modu nasıl etkinleştirilir

> WP_DEBUG, bir “sitede kritik bir hata oluştu” mesajının veya boş ekranın arkasındaki dosyayı, satırı ve tam mesajı ortaya çıkarır. Doğru ayarlandığında bu bilgileri ziyaretçilere hiç göstermeden bir günlük dosyasına yazar.

- Source canonique : [https://allaux.fr/tr/guides/activer-mode-debug-wordpress](https://allaux.fr/tr/guides/activer-mode-debug-wordpress)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> wp-config.php içinde üç sabiti ekleyin veya değiştirin: WP_DEBUG'ı true, WP_DEBUG_LOG'u true ve WP_DEBUG_DISPLAY'i false yapın. Hatalar böylece hiçbir zaman herkese açık şekilde görünmeden wp-content/debug.log dosyasına yazılır.

## wp-config.php

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

## Siteyi açığa çıkarmadan debug modunu etkinleştirme

1. **Site dosyalarına erişin** — wp-config.php, WordPress kurulumunun kökünde, wp-content, wp-admin ve wp-includes klasörleriyle aynı seviyede yer alır. FTP, SFTP veya barındırma sağlayıcısının dosya yöneticisine erişim gerekir.
2. **Değiştirilecek satırı bulun** — define('WP_DEBUG', false); satırını arayın. Eğer yoksa, /* That's all, stop editing! Happy publishing. */ satırından hemen önce üç sabiti ekleyin.
3. **Görüntülemeyi ve günlüklemeyi ayırın** — WP_DEBUG_DISPLAY'in false olması, mesajların herkese açık sayfalarda görünmesini engeller. WP_DEBUG_LOG'un true olması ise bunları bir dosyaya yazar; production ortamındaki bir sitede kullanılması gereken kombinasyon budur.
4. **Sorunu yeniden oluşturun** — WordPress'in olayı günlüğe kaydetmesi için hatayı tetikleyen sayfayı veya işlemi yeniden yükleyin.
5. **wp-content/debug.log dosyasını okuyun** — Bu dosya, PHP hatalarını kronolojik sırayla, dosya, satır ve genellikle sorumlu eklenti veya tema bilgisiyle birlikte listeler.
6. **Normal moda geri dönün** — Neden belirlendikten sonra WP_DEBUG ve WP_DEBUG_LOG'u tekrar false yapın ve hassas bilgiler içeriyorsa debug.log dosyasını silin.

## Görüntülemeyi ve günlüklemeyi neden ayırmalı

WordPress'in varsayılan yapılandırması, ziyaretçilere kod göstermemek için WordPress 5.2'den beri kullanılan “Bu sitede kritik bir hata oluştu” genel mesajının arkasına tüm hataları gizler. Bu iyi bir korumadır, ancak dosyalara erişim olmadan teşhisi imkânsız hale getirir.

Yalnızca WP_DEBUG'ı etkinleştirmek, hataların doğrudan sayfada görünmesi için yeterlidir; bu yerelde pratiktir ama production'da tehlikelidir: herhangi bir ziyaretçi aynı mesajları, bazen dosya yollarını veya iç işlev adlarını görebilir. WP_DEBUG_LOG'u true ve WP_DEBUG_DISPLAY'i false yapma kombinasyonu bu ikilemi çözer: hatalar kaydedilmeye devam eder, ancak yalnızca sunucu dosyalarına erişimi olan biri bunları görebilir.

Bir WooCommerce mağazasında, bu ayar yönetim panelindeki WooCommerce, Durum, Günlükler bölümünden erişilebilen eklentiye özgü günlüklerin okunmasıyla tamamlanır; bu günlükler ödeme, webhook ve stok senkronizasyonu hatalarını ayrı ayrı kaydeder.

## Sık yapılan hatalar

- WP_DEBUG_DISPLAY'i canlı bir sitede true bırakmak: hatalar, kullanılabilir teknik bilgiler dahil olmak üzere tüm ziyaretçiler tarafından görülebilir hale gelir.
- Etkinleştirildikten sonra debug.log dosyasının sınırsız büyüdüğünü unutmak: çok sayıda PHP notice üreten bir sitede, birkaç hafta içinde birkaç yüz megabayta ulaşabilir.
- wp-content/debug.log dosyasını henüz oluşmamışken aramak: WordPress bu dosyayı yalnızca etkinleştirmeden sonra ilk hata oluştuğunda oluşturur.
- wp-config.php dosyasını önceden yedek almadan değiştirmek: bu dosyadaki bir sözdizimi hatası, wp-admin dahil siteyi tamamen erişilemez hale getirir.

## Her müdahaleden sonra gözden geçirilmesi gereken bir ayar

> Geçmişte bir hizmet sağlayıcı veya eklenti wp-config.php dosyasını değiştirdiyse, WP_DEBUG'ın kimse fark etmeden ekranda etkin kalması mümkündür. Bu dosyanın hızlı bir kontrolü, PHP sürümü veya yedeklerin durumu gibi, devralınan bir mağazada yapılan rutin kontroller arasında yer alır.

## FAQ

### Debug modu kritik hatayı daha da kötüleştirebilir mi?

Hayır, günlük dosyası dışında hiçbir veriyi veya dosyayı değiştirmez. Yalnızca WordPress'in kendi hatalarını işleme ve gösterme biçimini değiştirir.

### wp-config.php yok veya bulamıyorum, ne yapmalıyım?

Bu dosya, çalışan her WordPress kurulumunda sitenin kökünde bulunur. Bulunamıyorsa, kurulumun eksik olması veya FTP erişiminin yanlış klasörü göstermesi mümkündür.

### Hata ayıklayıcı birden fazla farklı hata gösteriyor, önce hangisiyle ilgilenmeliyim?

Genellikle günlükteki kronolojik olarak ilk hatayla: sonrakiler genellikle ilkinin zincirleme sonuçlarıdır, örneğin yüklenemeyen bir eklenti ve ona bağımlı diğer eklentiler.

### WordPress çoklu site (multisite) kurulumunda debug modu etkinleştirilmeli mi?

Evet, yöntem aynıdır: sabitler, tüm site ağı tarafından paylaşılan aynı wp-config.php dosyasında tanımlanır.

### WordPress'i teşhis etmek için debug.log'dan daha kapsamlı bir araç var mı?

Query Monitor eklentisi, yönetim panelinde ve ön yüzde doğrudan bir hata ayıklama çubuğu ekler; çalıştırılan SQL sorgularının detayını, tetiklenen hook'ları ve her yavaşlama veya hatadan sorumlu eklentileri WP_DEBUG'a ek olarak gösterir.