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.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Siteyi açığa çıkarmadan debug modunu etkinleştirme
-
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.
-
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.
-
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.
-
Sorunu yeniden oluşturun
WordPress'in olayı günlüğe kaydetmesi için hatayı tetikleyen sayfayı veya işlemi yeniden yükleyin.
-
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.
-
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.
Sıkça sorulan sorular
Debug modu kritik hatayı daha da kötüleştirebilir mi?
wp-config.php yok veya bulamıyorum, ne yapmalıyım?
Hata ayıklayıcı birden fazla farklı hata gösteriyor, önce hangisiyle ilgilenmeliyim?
WordPress çoklu site (multisite) kurulumunda debug modu etkinleştirilmeli mi?
WordPress'i teşhis etmek için debug.log'dan daha kapsamlı bir araç var mı?
İhtiyacınızı bir dakikada anlatın
Size bir anket daha değil, doğrudan bir tahmin sunabilmem için birkaç hedefli soru.