WordPress Debug Log Konumu: debug.log Nerede Durur ve Nasıl Taşınır

WordPress debug log’unu varsayılan olarak wp-content/debug.log dosyasına yazar — diskteki mutlak karşılığı /path/to/your/site/wp-content/debug.log şeklindedir. Dosya, gerçekten bir şey kaydedilene kadar var olmaz ve yalnızca wp-config.php içinde WP_DEBUG değeri true ve WP_DEBUG_LOG etkinken yazılır. Bu varsayılan konum aynı zamanda gerçek bir güvenlik sorunudur, çünkü çoğu hostingde dosyayı tarayıcıdan herkes çekebilir.

Üç sabit ve her birinin işi

Üçü de wp-config.php içinde, /* That's all, stop editing! Happy blogging. */ yazan satırın üstüne gider. O satırın altına eklenen her şey WordPress zaten çalıştıktan sonra devreye girer ve yok sayılır.

Sabit	Varsayılan	Ne yapar
WP_DEBUG	false	Ana anahtar. PHP hata raporlamasını bildirimleri, uyarıları ve kullanımdan kaldırma mesajlarını gösterecek seviyeye çıkarır. Bu listedeki hiçbir şey onsuz çalışmaz.
WP_DEBUG_LOG	false	Hataları bir dosyaya gönderir. true değeri wp-content/debug.log demektir. Metin verilirse yazılacak dosya yolu olarak kabul edilir.
WP_DEBUG_DISPLAY	true	Hataları sayfanın HTML’ine yazdırır; her ziyaretçi görür.

İnsanların yanlış anladığı kısım bağımlılıktır. WP_DEBUG_LOG, WordPress’in başlangıç kodundaki WP_DEBUG dalının içinde okunur. WP_DEBUG değeri false ise WP_DEBUG_LOG değerini true yapmak hiçbir şey yapmaz — ne dosya, ne hata, ne uyarı. WP_DEBUG_LOG eklediniz ama log oluşmadıysa önce WP_DEBUG değerine bakın.

Canlı site için çalışan bir yapılandırma:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WP_DEBUG dosyanın yukarısında zaten tanımlıysa — genelde öyledir, false olarak — ikinci bir define() eklemek yerine o mevcut satırı düzenleyin. Aynı sabiti iki kez tanımlamak PHP uyarısı üretir; gösterim açık olan bir sitede bu uyarı doğrudan sayfanızın tepesine düşer.

Neden production’da WP_DEBUG_DISPLAY false olmalı

Gösterim açıkken PHP hataları HTML yanıtın içine basılır. Bir temadan gelen tek bir kullanımdan kaldırma bildirimi, sunucunuzun mutlak dosya sistemi yolunu her ziyaretçiye yazdırır. Bir veritabanı hatası tablo adlarını ve sorgu parçalarını gösterir. Daha kötüsü, başlıklar gönderilmeden önce çıkan çıktı yönlendirmeleri bozar, temiz JSON bekleyen REST ve AJAX yanıtlarını bozar ve insanların sonradan bir eklentiye yıktığı beyaz ekranı üretebilir.

Bilinmeye değer bir incelik: WP_DEBUG_DISPLAY değerini null yapmak, false yapmakla aynı şey değildir. null, WordPress’e PHP’nin display_errors ayarına dokunmamasını ve sunucuda ne ayarlıysa onu devralmasını söyler. false ise onu aktif olarak kapatır. Canlı bir sitede false kullanın ve yukarıdaki ini_set satırını da ek güvenlik olarak ekleyin, çünkü bir eklenti istek sırasında display_errors ayarını sonradan geri açabilir.

Varsayılan konum herkese açık şekilde indirilebilir

wp-content/debug.log web kök dizininin içinde durur. Standart bir WordPress kurulumunda bu dosyaya doğrudan yapılan istekleri engelleyen hiçbir şey yoktur. Tipik bir Apache ya da nginx kurulumunda https://siteniz.com/wp-content/debug.log adresi dosyayı düz metin olarak döndürür. Debug logları mutlak sunucu yollarını, eklenti ve tema iç detaylarını, gerçek sorgu metniyle birlikte veritabanı hatalarını ve bazen hata veren fonksiyonlara geçirilen değerleri içerir. Bu, adresi tahmin eden herkes için bedava keşif demektir — üstelik otomatik tarayıcıların ilk denediği adreslerden biridir.

Bununla başa çıkmanın iki yolu var. İyi olanı log’u taşımaktır.

Log’u bir yol vererek taşıyın

WordPress 5.1’den beri WP_DEBUG_LOG boolean yerine bir dosya yolu metni kabul eder. Doküman kök dizininin dışında bir yeri gösterin:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/youruser/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );

Bu yol için üç kural. Mutlak bir yol kullanın — göreli bir yol PHP’nin çalışma dizinine göre çözümlenir, bu da istekten isteğe ve sunucudan sunucuya değişir, yani dosyanın nereye gittiğini kaybedersiniz. Dizin önceden var olmalıdır; PHP onu oluşturmaz ve dosyayı açamazsa sessizce başarısız olur. Ayrıca dizin PHP kullanıcısı tarafından yazılabilir olmalıdır, ki paylaşımlı hostingde bu, SFTP ile giriş yaptığınız hesapla aynı değildir.

Hosting firmanız sizi web kök dizinine hapsediyorsa ve yazabileceğiniz üst bir dizin yoksa varsayılan yolu koruyup erişimi sunucu seviyesinde engelleyin. Apache için:

<Files "debug.log">
  Require all denied
</Files>

Bu, kök dizindeki değil wp-content içindeki bir .htaccess dosyasına gider — kalıcı bağlantıları kaydettiğinizde WordPress kökteki .htaccess dosyasını yeniden yazar ve eklediğinizi silebilir. nginx üzerinde .htaccess hiçbir işe yaramaz; sunucu yapılandırmasında bir location bloğuna ihtiyacınız olur, ki bu yönetilen hostingde genelde destekten istemek anlamına gelir.

Engellemenin size ne kazandırdığı konusunda dürüst olun: dosya hâlâ, web sunucusunun servis ettiği bir dizinde diskte duruyor. Herhangi bir eklentideki bir dizin geçişi (path traversal) açığı onu yine okuyabilir. Web kök dizininin dışına taşımak daha güçlü çözümdür.

Dosyayı okumak ve canlı izlemek

SSH üzerinden, sorunu tekrarlarken canlı izleyin:

tail -f wp-content/debug.log

Hatayı başka bir sekmede tekrarlayın; yeni satırlar yazıldıkça ekranda belirir. Yalnızca son olanları görmek ya da tek bir eklentiye göre filtrelemek için:

tail -n 100 wp-content/debug.log
grep -i 'plugin-slug' wp-content/debug.log | tail -n 50

PHP dosyanın sonuna ekleme yapar, o yüzden aşağıdan yukarıya okuyun. Her kayıt UTC olarak zaman damgalıdır ve bu, WordPress saat dilimi ayarınızla eşleşmez — bunun sizi eski kayıtlara baktığınız yanılgısına düşürmesine izin vermeyin.

WP-CLI ile sabitleri dosyayı elle düzenlemeden değiştirebilirsiniz:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

--raw bayrağı önemlidir — onsuz değer boolean yerine "true" metni olarak yazılır. Yol biçimi için ise --raw kullanmayın ki tırnaklı bir metin olarak yazılsın.

SSH yok mu? Dosyayı SFTP ile indirin ya da hosting firmanızın dosya yöneticisinde açın. Log’u wp-admin içinde gösteren eklentilerden, onlara tamamen güvenmiyorsanız uzak durun; sunucu iç detaylarıyla dolu bir dosyaya bir eklentiye okuma yetkisi vermiş oluyorsunuz.

Kurulumunuza uygun tam wp-config bloğunu, güvenli bir kök dışı yol ve eşleşen sunucu kuralıyla birlikte istiyorsanız WordPress debug log oluşturucu bunu sizin için hazırlar.

İşiniz bitince kapatın

WordPress çekirdeğinde debug.log dosyasını döndüren ya da kırpan hiçbir şey yoktur. Her sayfa yüklemesinde bildirim fırlatan bir sitede dosya sınırsız büyür ve diski doldurabilir — bu da siteyi, peşine düştüğünüz hatadan çok daha sert şekilde düşürür. Loglamayı açın, sorunu tekrarlayın, log’u okuyun, sonra WP_DEBUG değerini tekrar false yapın.

Dosyayı silmeden içeriğini boşaltmak için:

: > wp-content/debug.log

Log boş kalmaya devam ederse

Şunları sırayla gözden geçirin. WP_DEBUG değeri false — açık ara en yaygın neden ve diğer her şeyi sessizce devre dışı bırakır. Sabit, wp-config.php içinde “stop editing” satırının altında olabilir. Dosya izinleri — PHP wp-content içine ya da belirttiğiniz özel dizine yazamıyordur. wp-config yüklenmesi bitmeden oluşan bir fatal hata, örneğin yapılandırma dosyasının kendisindeki bir söz dizimi hatası, WordPress loglamasının yakalayamayacağı kadar erken gerçekleşir; bunlar sunucunun kendi PHP hata log’una düşer. Hosting firmanız ayarı geçersiz kılıyordur — bazı yönetilen platformlar PHP’nin error_log ayarını sabitler ya da loglamayı kendi panellerine yönlendirir; bu durumda sabitleriniz doğrudur, çıktı sadece başka yerdedir. Yapılandırmanızın bozuk olduğunu varsaymadan önce hosting firmasının log görüntüleyicisine bakın.