WordPress Hata Ayıklama Modu: WP_DEBUG Nasıl Açılır

WordPress hata ayıklama modu (WP_DEBUG), bir sorunun arkasındaki gerçek hata mesajını görmenizi sağlar. Beyaz ekran, kritik hata ya da çalışmayan bir eklenti gibi durumlarda WordPress genellikle sebebi saklar. Mod açılınca PHP uyarıları, kullanımdan kalkan işlev bildirimleri ve ölümcül hatalar görünür hale gelir. Ama yanlış kurulursa aynı mod ziyaretçilere dosya yollarınızı gösterir ya da herkesin indirebileceği bir günlük dosyası oluşturur. Bu rehber, sabitlerin her birini, günlüğün nerede olduğunu, nasıl okunacağını ve canlı sitede nasıl güvenli kullanılacağını anlatıyor.

WP_DEBUG ve ilgili sabitler ne işe yarar?

Hata ayıklama davranışı wp-config.php içindeki birkaç sabitle yönetilir. WordPress geliştirici belgelerine göre WP_DEBUG_LOG ve WP_DEBUG_DISPLAY, WP_DEBUG açıkken anlamlıdır.

Canlı sitede hata ayıklama nasıl güvenli açılır?

Güvenli kurulumun amacı hataları toplamak ama ziyaretçiye göstermemektir. Aşağıdaki satırları wp-config.php dosyasında /* That's all, stop editing! Happy publishing. */ satırından önce ekleyin. Sonrasına eklenen tanımlar çalışmaz.

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

Son satır, PHP'nin kendi ekran çıktısını da kapatır. Böylece WP_DEBUG_DISPLAY atlanan yerlerde bile hata sayfaya sızmaz. Dosyayı düzenlemeden önce yedek alın, çünkü wp-config.php'deki küçük bir sözdizimi hatası siteyi tamamen çökertir. Sunucuya erişiminiz varsa aynı işi WP-CLI ile de yapabilirsiniz:

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

İşiniz bittiğinde modu kapatın: wp config set WP_DEBUG false --raw ya da satırları dosyadan silin. WordPress belgeleri de canlı sitelerde bu araçların önerilmediğini açıkça belirtir. Mod yalnızca sorun avı süresince açık kalmalı.

debug.log dosyası nerede ve nasıl görüntülenir?

WP_DEBUG_LOG değeri true ise günlük wp-content/debug.log dosyasına yazılır. Dosya, ilk hata oluşana kadar yoktur, bu yüzden hiç görünmüyorsa henüz bir hata kaydedilmemiş olabilir. FTP ya da hosting dosya yöneticisiyle açabilir veya sunucuda komut satırıyla izleyebilirsiniz:

tail -n 50 wp-content/debug.log
tail -f wp-content/debug.log

İkinci komut günlüğü canlı izler. Başka bir sekmede sorunu yeniden üretip yeni satırların düştüğünü görebilirsiniz. Özel bir yol vermek isterseniz define( 'WP_DEBUG_LOG', '/home/kullanici/loglar/wp-errors.log' ); biçimini kullanın. Yol, web sunucusunun yazabildiği bir klasörde olmalı.

Günlük dosyasını başkalarına açık bırakmamak için ne yapmalıyım?

Varsayılan konum wp-content web kökünün içinde olduğundan, siteadresi.com/wp-content/debug.log adresi çoğu sunucuda doğrudan indirilebilir. Günlük dosya yolları, eklenti adları ve bazen sorgu parçaları içerir. WordPress'in Site Sağlığı ekranı da bunu bilir ve "Siteniz hataları potansiyel olarak herkese açık bir dosyaya kaydedecek şekilde ayarlı" uyarısı verir. Korunmanın üç yolu var:

1. 1Günlüğü web kökü dışına taşıyın. WP_DEBUG_LOG için kök dizinin üstünde bir yol verin. Bu en sağlam yoldur.
2. 2Apache'de erişimi engelleyin. wp-content/.htaccess dosyasına <Files debug.log> bloğu içinde Require all denied ekleyin. Eski Apache sürümlerinde Order allow,deny ve Deny from all kullanılır.
3. 3Nginx'te kural yazın. location ~* /debug\.log$ { deny all; } benzeri bir kuralı sunucu yapılandırmasına ekleyin. Paylaşımlı hostingde bunu hostinginiz yapar.

Günlük dosyası büyüdükçe disk de doldurur. İncelemeyi bitirince dosyayı silin ya da temizleyin. Kapattıktan sonra tarayıcıdan adresi açıp 403 ya da 404 aldığınızı test etmek iyi bir alışkanlıktır.

Günlükteki yaygın satırlar ne anlama gelir?

Her satır bir zaman damgası, hata düzeyi, mesaj ve dosya yolundan oluşur. Önemli olan, düzeyi ve dosya yolunun içindeki plugins ya da themes klasör adını okumaktır, çünkü sorumluyu bu yol gösterir.

[04-Oct-2026 10:15:32 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function foo()
in /wp-content/plugins/ornek-eklenti/inc/yardimci.php:48

• Fatal error: PHP çalışmayı durdurdu, sayfa ya da site açılmaz. Gerçek arıza budur. Dosya yolundaki eklenti ya da temayı devre dışı bırakın.
• Parse error: bir PHP dosyasında sözdizimi hatası var. Genellikle elle düzenlenmiş bir dosyada eksik noktalı virgül ya da parantezdir.
• Warning: hata var ama çalışma devam ediyor. Eksik bir dosya ya da yanlış değişken olabilir, işlevselliği bozuyorsa incelenmeli.
• Notice: tanımsız değişken gibi küçük bir dikkat uyarısı. Çoğunlukla zararsızdır ama JSON yanıtlarını bozabilir.
• Deprecated: kullanılan işlev ileride kaldırılacak. Acil değildir, ama eklenti geliştiricisine bildirilmeli ve PHP sürümü yükseltilirken önem kazanır.

Bir satırdaki dosya yolu eklenti klasörünü gösteriyorsa sorun büyük olasılıkla o eklentidedir. Ölümcül hata sitenizi açılamaz hale getirdiyse kritik hata rehberindeki sıralı adımları izleyin.

WP_DEBUG_LOG ile PHP error_log arasındaki fark nedir?

error_log, PHP'nin kendi yapılandırma yönergesidir ve hosting tarafından ayarlanır. Genellikle sunucunun genel hata dosyasına ya da sitenin klasöründeki bir error_log dosyasına yazar. WP_DEBUG_LOG ise WordPress'in bu çıktıyı kendi dosyasına yönlendirmesidir. Aktif olduğunda WordPress günlük kaydını açar ve hata dosyası yolunu debug.log olarak belirler.

Pratik sonuç: WP_DEBUG_LOG kapalıyken sunucu düzeyindeki PHP günlüğüne bakmanız gerekir. Hosting panelinde "Error Logs" ya da "Hata Günlükleri" bölümünde bulunur. Bellek yetersizliği ya da PHP sürüm uyumsuzluğu gibi WordPress'in yükleneceği anda oluşan hatalar bazen yalnızca orada görünür. İki kaynağa da bakmak en güvenli yöntemdir.

SAVEQUERIES ve SCRIPT_DEBUG ne zaman gerekir?

Bunlar hata yakalama araçları değil, performans ve geliştirme araçlarıdır. SAVEQUERIES açıkken her veritabanı sorgusu, süresiyle ve onu çağıran işlevle birlikte $wpdb->queries dizisine kaydedilir. Yavaş bir sayfanın hangi sorgudan yavaşladığını bulmak için kullanılır (yavaşlığın genel nedenleri için WordPress hızlandırma ipuçları). WordPress belgeleri bu ayarın performansı etkilediğini ve iş bitince kapatılması gerektiğini söyler. SCRIPT_DEBUG ise çekirdeğin .min olmayan dosyalarını yükler, bir admin ekranında JavaScript hatası ararken satır numaralarını okunur kılar.

Hata avında hangi sırayı izlemeliyim?

Hata ayıklama modu tek başına çözüm değildir, bir teşhis aracıdır. Verimli bir sıra, gereksiz kesintiyi önler ve modu en kısa süre açık tutar.

1. 1Önce yedek alın ve sorunun ne zaman başladığını not edin. Bir güncelleme sonrası başladıysa o güncellemeyi hedefleyin.
2. 2Güvenli kurulumu (günlüğe yaz, ekrana yazdırma) açın ve sorunu bir kez yeniden üretin.
3. 3Günlükte en alttaki Fatal error satırını bulun. Dosya yolundaki eklenti ya da tema adı çoğunlukla sorumludur.
4. 4Eklentiyi devre dışı bırakın ya da önceki sürüme döndürün, sorunu tekrar deneyin.
5. 5Çözüldüyse modu kapatın, debug.log dosyasını silin ve adres çubuğundan dosyanın erişilemediğini doğrulayın.

Bir güncellemenin ardından siteniz bozulduysa güncelleme sonrası site bozulduğunda yapılacaklar sayfası bu akışı güncelleme odaklı ele alır. Hata ayıklamaya gerek kalmadan sunucu ve yapılandırma sorunlarını görmek için de Site Sağlığı ekranına bakabilirsiniz. O ekran, hata gösterimi açık kalmış bir siteyi ayrıca uyarır.

Sık sorulan sorular

WP_DEBUG açıkken sitem yavaşlar mı?

Hafif ölçüde yavaşlayabilir, çünkü her uyarı ve bildirim işlenip yazılır. Asıl maliyet SAVEQUERIES'te ortaya çıkar. Yalnızca gerektiği kadar süre açık tutun.

debug.log hiç oluşmuyor, neden?

Sabitleri /* That's all, stop editing! */ satırından sonra yazdıysanız çalışmaz. Dizin yazma izni yoksa da dosya açılamaz. Ayrıca henüz hiç hata oluşmamışsa dosya yaratılmaz, sorunu yeniden üretin.

WP_DEBUG_DISPLAY false olunca neden hâlâ hata görüyorum?

PHP'nin display_errors ayarı hosting tarafından açıksa, çekirdekten bağımsız bir hata ekrana basılabilir. Yukarıdaki @ini_set( 'display_errors', 0 ); satırını ekleyin ya da hostingden ayarı kapatmasını isteyin.

Hata ayıklamayı açınca düzenleyici bozuldu, normal mi?

Ekran çıktısı açıksa evet. Uyarılar JSON yanıtına karışır. Gösterimi kapatıp sadece dosyaya yazdırın. Ayrıntılar düzenleyici hatası rehberinde.

• WordPress Developer Resources: Debugging in WordPress
• WordPress.org: Site Sağlığı ekranı
• WP-CLI: wp config set

Erdinç

Watch Your WP'yi geliştiriyor. WordPress bakım, güvenlik ve site yönetimi deneyiminden yazıyor.

LinkedIn