WordPress için Hata Günlükleri Nasıl Oluşturulur ve Erişilir (3 Yöntem)

WordPress hata günlükleri, sunucunuzda meydana gelen PHP hatalarını, ölümcül istisnaları, veritabanı hatalarını, eklenti çakışmalarını ve tema uyumsuzluklarını kaydeden tanılama kayıtlarıdır. Bu günlüklere erişmek ve yorumlamak, bozuk bir sayfanın, ölüm beyaz ekranının veya sessiz bir performans gerilemesinin temel nedenini — eklentileri tek tek tahmin etmeden veya devre dışı bırakmadan — tespit etmenin en hızlı yoludur.

Bu kılavuz, WordPress hata günlüklerini etkinleştirmek, bulmak ve okumak için üretimde test edilmiş üç yöntemi kapsamaktadır: yerel WP_DEBUG yığını, barındırma kontrol paneli aracılığıyla sunucu düzeyinde günlükler ve eklenti tabanlı günlük görüntüleyiciler. Her yöntem farklı bir erişim düzeyine ve kullanım senaryosuna uygundur; üçü de tam dosya yolları, yapılandırma sözdizimi ve güvenlik konuları ile açıklanmaktadır.

WordPress Hata Günlükleri Neden Önemlidir?

WordPress, PHP üzerinde çalışır ve birkaç sınıf çalışma zamanı mesajı üretir: ölümcül hatalar (yürütme durur), uyarılar (yürütme devam eder ancak bir sorun vardır), bildirimler (bilgilendirici, genellikle kullanımdan kaldırılmış kodu gösterir) ve kullanımdan kaldırma mesajları (kaldırılması planlanan işlevler). Varsayılan olarak, bunların hiçbiri çoğu üretim yapılandırmasında kalıcı bir günlüğe yazılmaz — ya bastırılır ya da tarayıcıya yansıtılır ki bu bir güvenlik riskidir.

Günlük olmadan, ölümcül hata içeren bir eklenti güncellemesi yalnızca boş bir ekran üretir. Yanlış yapılandırılmış bir SMTP kitaplığı e-postaları sessizce bırakır. Bellek sınırı aşımı, görünür bir iz bırakmadan bir sayfa yüklemesini sonlandırır. Hata günlükleri bu görünmez hataları, hemen harekete geçebileceğiniz zaman damgalı, dosya referanslı ve satır numaralı girişlere dönüştürür.

Yöntem 1: wp-config.php Aracılığıyla WordPress Hata Ayıklama Modunu Etkinleştirme

WordPress, wp-config.php içinde tanımlanan bir dizi PHP sabiti tarafından kontrol edilen yerleşik bir hata ayıklama alt sistemiyle birlikte gelir. Bu, eklenti API’si, tema yükleyici ve veritabanı soyutlama katmanı (wpdb) tarafından atılan hatalar dahil olmak üzere WordPress’e özgü hataları yakaladığı için en hassas yöntemdir.

Adım 1: wp-config.php Dosyasını Bulun ve Açın

FileZilla veya Cyberduck gibi bir istemci kullanarak SFTP (güvenlik için düz FTP’ye tercih edilir) aracılığıyla sunucunuza bağlanın veya barındırma sağlayıcınızın Dosya Yöneticisini açın. Genellikle /public_html/ veya /var/www/html/ olan WordPress kök dizinine gidin. wp-config.php dosyası bu dizinin kökünde bulunur.

SSH erişiminiz varsa, doğrudan düzenleyebilirsiniz:

nano /var/www/html/wp-config.php

Adım 2: Hata Ayıklama Sabitlerini Yapılandırın

Mevcut satırı bulun:

define( 'WP_DEBUG', false );

Tüm bloğu, site ziyaretçilerine hataları göstermeden günlüğe kaydetmeyi etkinleştiren aşağıdaki yapılandırmayla değiştirin:

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

Her sabitin işlevi:

• WP_DEBUG — WordPress hata ayıklama motorunu etkinleştirir ve E_ALL düzeyinde PHP hata raporlamayı etkinleştirir.
• WP_DEBUG_LOG — yakalanan tüm hataları ekran yerine (veya ek olarak) bir günlük dosyasına yazar.
• WP_DEBUG_DISPLAY — false olarak ayarlandığında, ekran çıktısını bastırır. Bu, üretim sitelerinde kritik öneme sahiptir; bu olmadan PHP bildirimleri dahili dosya yollarını ve değişken adlarını ziyaretçilere sızdırır.
• display_errors — temel PHP yönergesi; ini_set aracılığıyla 0 olarak ayarlamak, bir eklenti veya temanın WP_DEBUG_DISPLAY sabitini geçersiz kılması durumunda ikinci bir bastırma katmanı sağlar.

Adım 3: Hata Ayıklama Günlük Dosyasını Bulun

WP_DEBUG_LOG true olarak ayarlandığında, WordPress hataları şuraya yazar:

/wp-content/debug.log

Bu dosya, ilk günlüğe kaydedilen hatada otomatik olarak oluşturulur. SFTP veya SSH üzerinden görüntüleyebilirsiniz:

tail -f /var/www/html/wp-content/debug.log

tail -f bayrağı, belirli bir hatayı etkileşimli olarak yeniden üretirken son derece değerli olan yeni girişleri gerçek zamanlı olarak aktarır.

Adım 4: Özel Günlük Yolu Kullanın (Güvenlik İçin Önerilir)

Varsayılan debug.log yolu, web sunucunuz bunu açıkça engellemezse herkese açık olarak erişilebilir. Yanlış yapılandırılmış bir sunucu, https://yourdomain.com/wp-content/debug.log dosyasını herhangi bir ziyaretçiye sunarak dahili yolları, veritabanı tablo öneklerini ve sınıf adlarını açığa çıkarır.

Seçenek A — Günlük dosyasını web kökünün dışına taşıyın:

define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );

Hedef dizini oluşturun ve izinleri ayarlayın:

mkdir -p /var/log/wordpress
chown www-data:www-data /var/log/wordpress
chmod 750 /var/log/wordpress

Seçenek B — Varsayılan yolu .htaccess (Apache) aracılığıyla engelleyin:

<Files "debug.log">
    Order allow,deny
    Deny from all
</Files>

Seçenek C — Sunucu bloğunuzdaki Nginx eşdeğeri:

location ~* /wp-content/debug.log {
    deny all;
    return 404;
}

Adım 5: Sorun Giderme Sonrasında Hata Ayıklama Modunu Devre Dışı Bırakın

Canlı bir sitede WP_DEBUG sabitini gerekenden uzun süre true olarak bırakmayın. Sorun çözüldükten sonra:

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

Hata ayıklama modunu üretim sitesinde aktif bırakmak performansı düşürür (PHP her E_ALL bildirimini işler) ve WP_DEBUG_DISPLAY yanlışlıkla true olarak ayarlanırsa hassas yığın izlerini açığa çıkarabilir.

Yöntem 2: Barındırma Kontrol Paneli Aracılığıyla Sunucu Düzeyinde Hata Günlüklerine Erişim

WordPress önyüklemesi tamamlanmadan önce meydana gelen WordPress hataları — bozuk bir wp-config.php, PHP sürüm uyumsuzluğu veya başarısız bir veritabanı bağlantısı gibi — WordPress’in kendisi hiç yüklenmediği için debug.log içinde asla görünmez. Bunlar için sunucunun PHP hata günlüğüne veya Apache/Nginx hata günlüğüne ihtiyacınız vardır.

cPanel Tabanlı Barındırma

Barındırma ortamınız cPanel ile VPS kullanıyorsa, hata günlüğüne kontrol paneli arayüzü üzerinden erişilebilir:

1. cPanel’e giriş yapın.
2. Metrikler > Hatalar bölümüne gidin.
3. Panel, hesabınız için Apache hata günlüğünün son 300 satırını görüntüler.

Tam günlük dosyası için cPanel’in Dosya Yöneticisi‘ni kullanın veya SFTP aracılığıyla bağlanın ve şuraya gidin:

/home/yourusername/logs/yourdomain.com-ssl_log
/home/yourusername/logs/yourdomain.com-error_log

Tam dosya adları sunucu yapılandırmasına göre değişir, ancak desen çoğu cPanel kurulumunda tutarlıdır.

Plesk Tabanlı Barındırma

Plesk’te Web Siteleri ve Etki Alanları > etki alanınızı seçin > Günlükler bölümüne gidin. Günlük türüne göre (erişim, hata, PHP) filtreleyebilir ve tam günlük dosyasını indirebilirsiniz.

Doğrudan Sunucu Erişimi (VPS veya Dedicated)

Root erişiminizin olduğu bir VPS Hosting veya Dedicated Sunucu ortamında, günlük konumları yığınınıza bağlıdır:

PHP-FPM günlüğünü gerçek zamanlı olarak izlemek için:

tail -f /var/log/php8.2-fpm.log

Apache günlüğünde WordPress’e özgü ölümcül hataları aramak için:

grep -i "fatal|wordpress|wp-" /var/log/apache2/error.log | tail -50

Sunucu Düzeyinde PHP Hata Günlüğünü Yapılandırma

PHP hataları bir günlüğe yazılmıyorsa, php.ini yapılandırmanızı kontrol edin:

php --ini | grep "Loaded Configuration"

Belirlenen php.ini dosyasını açın ve şunları doğrulayın veya ayarlayın:

log_errors = On
error_log = /var/log/php_errors.log
display_errors = Off
error_reporting = E_ALL

Değişikliklerden sonra PHP-FPM’yi yeniden başlatın:

systemctl restart php8.2-fpm

Alternatif olarak, .htaccess dosyası (yalnızca Apache) kullanarak site başına PHP ayarlarını geçersiz kılın:

php_flag log_errors on
php_value error_log /var/log/wordpress/php_errors.log
php_flag display_errors off

Yöntem 3: WordPress Hata Günlüğü Eklentisi Kullanma

Doğrudan sunucu erişiminin kısıtlı olduğu ortamlarda — Paylaşımlı Web Hosting gibi — veya teknik olmayan yöneticilerin SSH erişimi olmadan hataları incelemesi gereken ekipler için, bir WordPress eklentisi uygulanabilir bir alternatif sunar.

Önerilen Eklentiler

• WP Log Viewer — mevcut debug.log dosyasını okur ve WordPress yönetici panelinde filtreleme ve arama ile görüntüler.
• Error Log Monitor — son hataları gösteren bir gösterge paneli widget’ı ekler ve yeni hatalar günlüğe kaydedildiğinde e-posta uyarıları gönderebilir.
• Query Monitor — hata günlüğünün ötesine geçerek veritabanı sorgularını, HTTP API çağrılarını, kancaları ve koşullu etiketleri profiler. Performans hata ayıklaması için vazgeçilmezdir.
• Health Check & Troubleshooting — WordPress.org’un resmi eklentisi; diğer ziyaretçileri etkilemeden yalnızca oturumunuz için varsayılan bir temayı etkinleştiren ve tüm eklentileri devre dışı bırakan bir sorun giderme modunu etkinleştirir.

Error Log Monitor’ü Yükleme ve Yapılandırma

1. WordPress yönetici panelinde Eklentiler > Yeni Ekle bölümüne gidin.
2. Error Log Monitor‘ü arayın ve Şimdi Yükle‘ye, ardından Etkinleştir‘e tıklayın.
3. Ayarlar > Error Log Monitor bölümüne gidin.
4. Günlük dosyası yolunu ayarlayın. debug.log dosyasını web kökünün dışına taşıdıysanız, mutlak sunucu yolunu buraya girin.
5. Yeni hata türleri için bildirim almak istiyorsanız e-posta uyarı sıklığını yapılandırın.

Eklenti, WP_DEBUG_LOG‘ın yazdığı aynı debug.log dosyasını okur. Ayrı bir günlük mekanizması oluşturmaz — bir görüntüleyicidir. Bu, eklentinin herhangi bir şey görüntüleyebilmesi için WP_DEBUG ve WP_DEBUG_LOG sabitlerinin wp-config.php içinde etkinleştirilmiş olması gerektiği anlamına gelir.

Kritik sınırlama: Eklentiler WordPress önyüklemesinden sonra yüklenir. WordPress’in yüklenmesini engelleyen herhangi bir hata (veritabanı bağlantı hatası, bozuk çekirdek dosya, uyumsuz PHP sürümü) hiçbir eklenti tabanlı günlük görüntüleyicide görünmez. Bu senaryolar için Yöntem 2 tek seçenektir.

Karşılaştırma: Üç WordPress Hata Günlüğü Yöntemi

WordPress Hata Günlüğü Girişlerini Okuma ve Yorumlama

Ham bir debug.log girişi şöyle görünür:

[04-Jul-2025 14:32:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /var/www/html/wp-content/themes/mytheme/functions.php:47
Stack trace:
#0 /var/www/html/wp-content/themes/mytheme/functions.php(47): get_field()
#1 {main}
thrown in /var/www/html/wp-content/themes/mytheme/functions.php on line 47

Bunu nasıl okuyabilirsiniz:

• Zaman damgası UTC cinsindendir — gerekirse sunucunuzun yerel saat dilimine dönüştürün.
• PHP Fatal error, yürütmenin durduğu anlamına gelir. Bunu tetikleyen sayfa 500 hatası veya boş ekran döndürdü.
• Call to undefined function get_field(), Advanced Custom Fields eklentisinin ya devre dışı bırakıldığı ya da temanın functions.php dosyasının onu çağırmaya çalışmasından sonra yüklendiği anlamına gelir.
• Yığın izleme tam dosyayı ve satır numarasını gösterir. functions.php dosyasının 47. satırından hata ayıklamaya başlayın.

Yaygın hata kalıpları ve nedenleri:

• PHP Warning: require(): Failed opening required — bir dosya yolu yanlış veya bir dosya eksik. Genellikle silinen bir dosyaya başvuran bir eklentinin neden olduğu.
• PHP Deprecated: Function _register_controls is deprecated — bir eklenti veya tema eski bir API kullanıyor. Ölümcül değil, ancak mevcut WordPress/Elementor sürümü için güncellenmemiş bir eklentiye işaret eder.
• WordPress database error ... for query — bir wpdb sorgusu başarısız oldu. Tablo öneki uyumsuzluklarını veya bozuk tabloları kontrol edin.
• Maximum execution time of 30 seconds exceeded — bir betik çok uzun süre çalıştı. Büyük içe aktarmalar, optimize edilmemiş sorgular veya zaman aşımına uğrayan harici API çağrılarıyla yaygındır.
• Allowed memory size of X bytes exhausted — PHP bellek sınırına ulaştı. php.ini içinde memory_limit değerini artırın veya bellek sızdıran eklentiyi belirleyin.

WordPress Hata Günlüklerini Yönetmek İçin En İyi Uygulamalar

Disk tükenmesini önlemek için günlükleri döndürün. Saldırı altındaki veya yinelenen hatası olan yoğun bir WordPress sitesi günde yüzlerce megabayt günlük verisi üretebilir. Linux sunucularda logrotate yapılandırın:

nano /etc/logrotate.d/wordpress-debug

/var/log/wordpress/debug.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 640 www-data www-data
}

debug.log dosyasını asla sürüm kontrolüne eklemeyin. .gitignore dosyasına ekleyin:

wp-content/debug.log

Her sunucu geçişinden sonra wp-config.php dosyanızı denetleyin. Barındırma geçişleri sıklıkla WP_DEBUG sabitini false olarak sıfırlar veya sabitlerinizigeçersiz kılan yeni bir wp-config.php şablonu sunar.

Veritabanı düzeyinde hata ayıklama için SAVEQUERIES kullanın. WordPress’in yürüttüğü her SQL sorgusunu günlüğe kaydetmek için bu sabiti WP_DEBUG ile birlikte ekleyin:

define( 'SAVEQUERIES', true );

Ardından özel bir şablonda veya Query Monitor aracılığıyla $wpdb->queries değişkenini inceleyin. Kullanımdan hemen sonra devre dışı bırakın — her sorguyu bellekte depolar ve RAM tüketimini önemli ölçüde artırır.

Günlük zaman damgalarını dağıtım olaylarıyla ilişkilendirin. Yeni bir hata türü görünürse, bunun bir eklenti güncellemesi, WordPress çekirdek güncellemesi veya sunucudaki PHP sürüm değişikliğiyle örtüşüp örtüşmediğini kontrol edin. Çoğu barındırma kontrol paneli, PHP sürüm değişikliklerini ayrı bir denetim izinde günlüğe kaydeder.

Karar Matrisi: Hangi Yöntemi Kullanmalısınız

Teknik Temel Çıkarımlar Kontrol Listesi

• Canlı trafiği olan herhangi bir sitede WP_DEBUG_LOG etkinleştirmeden önce WP_DEBUG_DISPLAY sabitini false olarak ayarlayın.
• debug.log dosyasını web kökünün dışına taşıyın veya sunucu kuralları aracılığıyla engelleyin — varsayılan yol herkese açık olarak erişilebilir.
• Hataları etkileşimli olarak yeniden üretirken günlük dosyasında tail -f komutunu kullanın; dosyayı manuel olarak yenileme ihtiyacını ortadan kaldırır.
• Sunucu düzeyinde PHP ve Apache/Nginx günlükleri, WordPress yüklenmeden önce meydana gelen hatalar için tek gerçek kaynaktır.
• Eklenti tabanlı günlük görüntüleyiciler, WP_DEBUG_LOG sabitinin etkin olmasını gerektirir — bunlar okuyucu, yazıcı değildir.
• WP_DEBUG_LOG sabitinin birkaç saatten uzun süre etkin olduğu herhangi bir sunucuda günlük döndürmeyi uygulayın.
• Üretimde SAVEQUERIES sabitini asla etkin bırakmayın; bellek ve performans açısından bir yüktür.
• Bir sorunu çözdükten sonra, tüm hata ayıklama sabitlerini false olarak geri ayarlayın ve sayfa kaynağında PHP bildirimlerinin görünmediğini bir tarayıcı isteğiyle doğrulayın.

—

Sıkça Sorulan Sorular

WordPress hata ayıklama günlük dosyası varsayılan olarak nerede bulunur?

WordPress, hata ayıklama günlüğünü WordPress kök dizininize göre /wp-content/debug.log konumuna yazar. Bu yol yalnızca ilk hata günlüğe kaydedildikten sonra oluşturulur ve yalnızca hem WP_DEBUG hem de WP_DEBUG_LOG sabitleri wp-config.php içinde true olarak ayarlandığında geçerlidir. true yerine WP_DEBUG_LOG sabitinin değeri olarak mutlak bir dosya yolu dizesi geçirerek yolu geçersiz kılabilirsiniz.

Canlı üretim sitesinde WP_DEBUG etkinleştirmek güvenli midir?

Yalnızca WP_DEBUG_DISPLAY açıkça false olarak ayarlandığında ve display_errors 0 olarak ayarlandığında güvenlidir. Bu iki ayar olmadan, PHP hataları — dahili dosya yolları ve veritabanı tablo adları dahil — her sayfanın HTML kaynağında doğrudan işlenir. Genel trafiği olan herhangi bir sitede WP_DEBUG true sabitini her zaman WP_DEBUG_DISPLAY false ile eşleştirin.

WP_DEBUG etkin olmasına rağmen debug.log dosyam neden boş?

En yaygın nedenler şunlardır: web sunucusu işleminin /wp-content/ dizinine yazma izni yoktur; WP_DEBUG_LOG sabiti wp-config.php içinde false olarak ayarlanmış veya eksiktir; ya da hata WordPress yüklenmeden önce sunucu düzeyinde meydana gelmektedir, yani debug.log yerine Apache veya PHP-FPM günlüğünde görünecektir. Dizin izinlerini ls -la wp-content/ ile kontrol edin ve sabitlerin wp-config.php içinde doğru sırada tanımlandığını doğrulayın.

WP_DEBUG_LOG ile sunucunun PHP hata günlüğü arasındaki fark nedir?

WP_DEBUG_LOG, WordPress’in özel hata işleyicisi tarafından yakalanan hataları debug.log konumuna yönlendiren bir WordPress düzeyinde sabittir. Sunucunun PHP hata günlüğü (php.ini içindeki error_log aracılığıyla yapılandırılır), WordPress başlatılmadan önce meydana gelenler dahil olmak üzere tüm PHP hatalarını yorumlayıcı düzeyinde yakalar. Düzgün yapılandırılmış bir sunucuda her iki günlük de aynı anda etkindir ve birbirini tamamlar.

SSH erişimi olmadan paylaşımlı barındırmada hata günlüğünü etkinleştirebilir miyim?

Evet. cPanel veya Plesk’teki barındırma sağlayıcınızın Dosya Yöneticisi aracılığıyla wp-config.php dosyasını düzenleyebilir, WP_DEBUG ve WP_DEBUG_LOG sabitlerini etkinleştirebilir ve ardından aynı Dosya Yöneticisi arayüzü üzerinden debug.log dosyasını okuyabilirsiniz. Paylaşımlı Web Hosting üzerindeki sunucu düzeyinde günlükler için cPanel’deki Metrikler altındaki Hatalar bölümünü kullanın. PHP yapılandırması ve günlük yolları üzerinde daha ayrıntılı kontrole ihtiyaç duyuyorsanız, bir VPS Hosting planına yükseltmek size php.ini dosyasına doğrudan erişim ve tüm günlük dosyalarına tam SSH erişimi sağlar.