WordPress Debug Nedir? WP_DEBUG ve debug.log Nasıl Açılır?

WordPress Debug sitenizde bir anda kritik hata oluştuğunda, bir eklenti çalışmadığında veya yaptığınız bir güncellemeden sonra beklenmeyen bir problem meydana geldiğinde en önemli aşamalardan biri hatanın kaynağını doğru şekilde tespit etmektir.

Çünkü WordPress’te görülen her hata aynı nedenden kaynaklanmaz.

Bir problem;

🔌 Eklenti çakışması

🎨 Tema uyumsuzluğu

🐘 PHP sürümü

🧠 PHP Memory Limit

⚙️ Sunucu yapılandırması

🗄️ Veritabanı

veya doğrudan PHP kodundan kaynaklanabilir.

İşte WordPress Debug Modu, bu problemlerin kaynağını araştırırken kullanabileceğiniz yerleşik araçlardan biridir.

WP_DEBUG, WP_DEBUG_LOG ve WP_DEBUG_DISPLAY gibi ayarlarla WordPress’in hata raporlama davranışını kontrol edebilir, oluşan hataları debug.log dosyasına kaydedebilir ve ziyaretçilere teknik hata mesajlarının gösterilmesini engelleyebilirsiniz.

Bu rehberde WordPress Debug Modu nedir, WP_DEBUG nasıl açılır, debug.log nerede bulunur, eklenti hataları nasıl tespit edilir ve Debug Modu güvenli şekilde nasıl kapatılır? sorularını adım adım ele alacağız.

🔍 WordPress Debug Modu Nedir?

WordPress Debug Modu, WordPress’in hata ayıklama amacıyla sunduğu yerleşik debugging sistemidir.

Normal bir WordPress kurulumunda bazı PHP hataları kullanıcıya doğrudan gösterilmeyebilir. Bu durum ziyaretçi deneyimi açısından olumlu olsa da geliştirici açısından hatanın nedenini bulmayı zorlaştırabilir.

Debug sistemi etkinleştirildiğinde WordPress, PHP tarafındaki hata, uyarı ve bazı teknik bildirimleri daha ayrıntılı şekilde incelemenize yardımcı olur.

Özellikle:

🔌 Eklenti hataları

🎨 Tema problemleri

🐘 PHP uyumsuzlukları

🧠 Memory Limit sorunları

🚨 Kritik WordPress hataları

🐞 Kodlama problemleri

gibi durumlarda kullanılabilir.

WordPress’in resmi geliştirici dokümantasyonunda da WP_DEBUG, WP_DEBUG_LOG ve WP_DEBUG_DISPLAY gibi yapılandırmalar hata ayıklama amacıyla açıklanıyor. WordPress Debugging – Resmi Dokümantasyon

💡 İpucu: Debug Modu hatayı otomatik olarak çözmez. Asıl amacı, problemin kaynağını bulmanıza yardımcı olmaktır.

⚙️ WP_DEBUG Ne İşe Yarar?

WP_DEBUG, WordPress’in hata ayıklama modunu etkinleştiren temel sabittir.

wp-config.php içerisinde:

define( 'WP_DEBUG', false );

şeklinde bir tanımlama bulunuyorsa Debug Modu kapalıdır.

Etkinleştirmek için:

define( 'WP_DEBUG', true );

kullanılır.

Bu değişiklik sonrasında WordPress hata ayıklama davranışını etkinleştirir.

Örneğin bir eklenti PHP tarafında hata oluşturuyorsa veya temanız eski bir fonksiyon kullanıyorsa Debug Modu bu problemin daha görünür hale gelmesini sağlayabilir.

💡 İpucu: Bir problem bir eklenti veya tema güncellemesinden hemen sonra başladıysa, Debug Modu’nu açmadan önce son yaptığınız değişikliği not edin. Hatanın zamanlaması teşhis sürecinde çok değerlidir.

📝 WP_DEBUG_LOG Nedir?

WP_DEBUG_LOG, Debug Modu tarafından yakalanan hata kayıtlarının bir log dosyasına yazılmasını sağlar.

Temel kullanım:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );

Bu yapılandırmayla hata kayıtları varsayılan olarak:

/wp-content/debug.log

dosyasına yazılabilir.

Bu özellikle hata ekranda görünmediğinde oldukça kullanışlıdır.

Örneğin bir AJAX isteği sırasında hata oluşuyorsa kullanıcı yalnızca işlemin gerçekleşmediğini görebilir. Ancak hata debug.log içerisine kaydedilmiş olabilir.

💡 İpucu: WP_DEBUG_LOG, özellikle ekranda görünmeyen PHP, AJAX veya zamanlanmış görev hatalarını araştırırken çok değerlidir.

👀 WP_DEBUG_DISPLAY Nedir?

WP_DEBUG_DISPLAY, hata mesajlarının doğrudan ziyaretçinin ekranında gösterilip gösterilmeyeceğini kontrol eder.

Örneğin:

define( 'WP_DEBUG_DISPLAY', false );

kullanıldığında hata mesajlarının sayfa üzerinde gösterilmesi engellenebilir.

Canlı bir sitede genellikle:

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

şeklindeki yapı tercih edilir.

Böylece:

Hata oluşur → log dosyasına kaydedilir → ziyaretçiye gösterilmez.

🔐 İpucu: Canlı sitede hata detaylarını ziyaretçinin karşısına çıkarmak yerine log dosyasından incelemek daha güvenlidir.

🛠️ WordPress Debug Modu Nasıl Açılır?

Şimdi işlemi adım adım uygulayalım.

1️⃣ Önce WordPress Yedeği Alın

wp-config.php dosyası WordPress’in önemli yapılandırma dosyalarından biridir.

Bu dosyada değişiklik yapmadan önce güncel bir yedeğinizin olması önemlidir.

Özellikle canlı bir sitede işlem yapıyorsanız WordPress yedekleme yöntemlerini bilmek büyük avantaj sağlar.

WordPress Yedekleme Nasıl Yapılır? Veri Kaybından Korunma Rehberi

💡 İpucu: wp-config.php üzerinde değişiklik yapmadan önce yalnızca site dosyalarını değil, mümkünse veritabanını da kapsayan güncel bir yedek bulundurun.

2️⃣ wp-config.php Dosyasını Bulun

WordPress kurulumunun ana dizininde:

wp-config.php

dosyasını bulabilirsiniz.

Örneğin:

public_html/
├── wp-admin/
├── wp-content/
├── wp-includes/
├── index.php
└── wp-config.php

cPanel veya Plesk kullanıyorsanız ilgili dosya yöneticisi üzerinden dosyaya erişebilirsiniz.

3️⃣ WP_DEBUG’u Etkinleştirin

Mevcut satır:

define( 'WP_DEBUG', false );

ise:

define( 'WP_DEBUG', true );

şeklinde değiştirin.

Eğer WP_DEBUG satırı bulunmuyorsa uygun yere ekleyebilirsiniz.

4️⃣ WP_DEBUG_LOG’u Açın

Ardından:

define( 'WP_DEBUG_LOG', true );

ekleyin.

5️⃣ Hata Mesajlarının Ekranda Görünmesini Engelleyin

Canlı site için:

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

kullanabilirsiniz.

Böylece hata kayıtları loglanırken ziyaretçilerin karşısına teknik hata mesajları çıkarılmaz.

6️⃣ Dosyayı Kaydedin

Değişiklikleri kaydettikten sonra problem yaşadığınız işlemi tekrar gerçekleştirin.

Örneğin:

🔌 Problemli eklentiyi etkinleştirin.

📄 Problemli sayfayı açın.

⚙️ Hata oluşturan işlemi tekrar çalıştırın.

Ardından debug.log dosyasını kontrol edin.

📌 Önerilen WP_DEBUG Yapılandırması

Genel hata teşhisi için:

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

kullanılabilir.

Bu kodun wp-config.php içerisinde:

/* That's all, stop editing! Happy blogging. */

satırından önce bulunması gerekir.

⚠️ Dikkat: wp-config.php içerisinde bu sabitler zaten tanımlıysa ikinci kez define() eklemeyin. Mevcut tanımlamaları düzenleyin.

🧠 WP_DEBUG Değerleri Nasıl Yazılmalı?

PHP’de true ve false boolean değerlerdir.

Doğru:

define( 'WP_DEBUG', true );

Yanlış:

define( 'WP_DEBUG', 'true' );

Benzer şekilde:

define( 'WP_DEBUG', false );

doğru kullanımdır.

Bu küçük ayrıntı, özellikle wp-config.php üzerinde ilk defa değişiklik yapan kullanıcılar için önemlidir.

📂 WordPress debug.log Nerede Bulunur?

Varsayılan durumda:

/wp-content/debug.log

konumunda bulunabilir.

Örneğin:

public_html/
└── wp-content/
    ├── plugins/
    ├── themes/
    ├── uploads/
    └── debug.log

şeklinde bir yapı görebilirsiniz.

Dosya her zaman önceden bulunmak zorunda değildir.

Debug ayarlarını etkinleştirdikten sonra yeni bir hata meydana geldiğinde oluşturulabilir.

💡 İpucu: Debug’u açtıktan sonra hatayı yeniden oluşturun. Ardından debug.log dosyasının son satırlarını kontrol edin. Eski kayıtlarla yeni hataları karıştırmamış olursunuz.

🐞 debug.log Nasıl Okunur?

İlk bakışta log dosyası karmaşık görünebilir.

Örneğin:

[27-Aug-2026 16:32:10 UTC] PHP Fatal error:
Uncaught Error: Call to undefined function
in /wp-content/plugins/example-plugin/plugin.php:125

Burada birkaç önemli bilgi bulunur.

🚨 Hata türü

PHP Fatal error

hatanın ciddi bir PHP problemi olduğunu gösterir.

📁 Dosya yolu

/wp-content/plugins/example-plugin/plugin.php

hata oluşan dosyanın bir eklentiye ait olduğunu gösterir.

🔢 Satır numarası

:125

hatanın dosyanın yaklaşık hangi satırında oluştuğunu gösterir.

🧩 Hata mesajı

Call to undefined function

problemin türü hakkında önemli bir ipucu verir.

Bu bilgileri birlikte değerlendirerek hatanın kaynağını daha kolay araştırabilirsiniz.

🔌 Eklenti Çakışması debug.log ile Nasıl Bulunur?

WordPress’te bir eklentiyi güncelledikten veya yeni bir eklenti kurduktan sonra hata başladıysa debug.log önemli ipuçları sağlayabilir.

Özellikle:

/wp-content/plugins/

yolunun geçtiği hatalar dikkatle incelenmelidir.

Örneğin:

/wp-content/plugins/example-plugin/includes/class-example.php

gibi bir kayıt görüyorsanız ilgili eklenti araştırılması gereken adaylardan biridir.

Fakat yalnızca dosya yoluna bakarak “kesin olarak bu eklenti hatalı” demek doğru değildir.

Eklentinin diğer eklentilerle, temayla ve WordPress sürümüyle ilişkisi de incelenmelidir.

Bu nedenle yeni yayınladığımız WordPress Eklenti Çakışması rehberiyle birlikte değerlendirmek daha doğru olur:

WordPress Eklenti Çakışması Nedir? Nasıl Tespit Edilir ve Çözülür?

💡 İpucu: Eklenti güncellemesinden hemen sonra hata oluştuysa güncelleme zamanını ve debug.logiçerisindeki yeni kayıtları karşılaştırın.

🚨 WordPress Debug Kritik Hata Nasıl Araştırılır?

WordPress’te:

“Bu web sitesinde kritik bir hata oluştu.”

mesajını gördüğünüzde ekrandaki bilgi problemin tamamını açıklamayabilir.

Bu durumda şu sırayla ilerleyebilirsiniz:

1️⃣ Debug Modu’nu açın.

2️⃣ WP_DEBUG_LOG değerini etkinleştirin.

3️⃣ WP_DEBUG_DISPLAY değerini kapatın.

4️⃣ Hatayı tekrar oluşturun.

5️⃣ debug.log dosyasını açın.

6️⃣ Son hata kayıtlarını inceleyin.

7️⃣ Eklenti veya tema dosya yolunu kontrol edin.

8️⃣ Sorunlu bileşeni izole edin.

WordPress’teki yaygın hata türleri hakkında daha fazla bilgi için:

WordPress Hata Kodları ve Çözümleri Rehberi

Bu bağlantı aynı zamanda kritik yetim durumundaki WordPress Hata Kodları içeriğine bağlamsal destek sağlar.

💡 İpucu: “Kritik hata” mesajını yalnızca ekranda gördüğünüz metin üzerinden çözmeye çalışmayın. Mümkünse gerçek PHP hata kaydını bulun.

🐘 PHP Sürümü Kaynaklı Hatalar

Her PHP hatasının kaynağı eklenti değildir.

Eski bir eklenti veya tema, kullanılan PHP sürümüyle uyumlu olmayabilir.

Örneğin hata kaydında:

Deprecated

veya:

Fatal error

gibi ifadeler görülebilir.

Bu nedenle hata araştırırken:

🐘 PHP sürümü

🔌 Eklenti sürümleri

🎨 Tema sürümü

🧩 WordPress sürümü

birlikte değerlendirilmelidir.

WordPress hosting tarafında PHP sürümünün neden önemli olduğunu şu rehberimizde daha ayrıntılı ele alıyoruz:

WordPress Hosting PHP Sürümü Kaç Olmalı? 8.3–8.5 Rehberi

🧠 PHP Memory Limit Hataları

Bazı WordPress problemleri eklenti çakışması gibi görünebilir ancak aslında PHP’nin kullanabileceği bellek sınırına ulaşılmış olabilir.

Örneğin:

Allowed memory size of XXXXX bytes exhausted

gibi bir hata görüyorsanız PHP Memory Limit değerini incelemek gerekir.

Bu durumda:

🧠 Memory Limit

🔌 Eklentiler

🎨 Tema

🐘 PHP sürümü

🖥️ Hosting kaynakları

birlikte değerlendirilmelidir.

Detaylı rehber:

WordPress PHP Memory Limit Nedir? Nasıl Artırılır? 2026 Rehberi

💡 İpucu: Bir eklenti kurduktan sonra hata oluşması, otomatik olarak eklentinin bozuk olduğu anlamına gelmez. PHP Memory Limit yetersizliği de benzer bir tablo oluşturabilir.

🧪 Staging Ortamında Debug Yapmak

Debug işlemlerini doğrudan canlı sitede yapmak yerine mümkünse staging ortamında gerçekleştirmek daha güvenlidir.

Staging ortamında:

🔄 Eklenti güncellemelerini

🐘 PHP değişikliklerini

🎨 Tema güncellemelerini

⚡ Cache ayarlarını

🐞 Debug işlemlerini

ziyaretçileri etkilemeden test edebilirsiniz.

WordPress Staging hakkında hazırladığımız rehber:

WordPress Staging Nedir? Siteyi Yayına Almadan Nasıl Test Edilir?

Bu bağlantı da mevcut kritik yetimlerden biri olmasa bile hata teşhisi kümesinin doğal bir parçası olarak kullanılabilir.

💡 İpucu: Özellikle canlı ve ticari sitelerde büyük eklenti güncellemelerini önce staging ortamında test etmek, hata oluştuğunda ziyaretçilerin etkilenmesini önleyebilir.

⚡ LiteSpeed Cache Kullanırken Debug

WordPress sitenizde LiteSpeed Cache kullanıyorsanız bazı problemler doğrudan PHP kaynaklı olmayabilir.

Özellikle:

⚡ JavaScript geciktirme

📦 JavaScript birleştirme

🎨 CSS optimizasyonu

🧹 CSS küçültme

⚙️ HTML optimizasyonu

gibi seçenekler bazı eklentilerin çalışma biçimini etkileyebilir.

Bu nedenle bir cache ayarını değiştirdikten hemen sonra problem başladıysa, son yaptığınız değişikliği geri alıp tekrar test etmek mantıklıdır.

WordPress Hosting İçin LiteSpeed Cache Ayarları: 2026 Rehberi

Ayrıca mevcut LiteSpeed Cache rehberimiz de sitemap’te yer alıyor; bu nedenle burada yeni bir konu açmak yerine mevcut içeriğe bağlanmak daha doğru bir yapı oluşturuyor.

💡 İpucu: Cache ayarlarını aynı anda değiştirmeyin. Bir ayarı değiştirin, siteyi test edin ve ancak sorun yoksa sonraki optimizasyona geçin.

❤️ Heartbeat API ve Debug

WordPress Heartbeat API, tarayıcı ile WordPress arasında belirli aralıklarla AJAX iletişimi sağlayan mekanizmalardan biridir.

Bazı eklentiler Heartbeat veya AJAX işlemlerini yoğun şekilde kullanabilir.

Bu durum özellikle yönetim panelinde:

🐌 Yavaşlama

🔄 Çok sayıda AJAX isteği

⚙️ Kaynak tüketimi

gibi problemlere neden olabilir.

Heartbeat API’nin kendisini doğrudan problem olarak görmek yerine, hangi işlemlerin yoğun kaynak kullandığını araştırmak daha doğru olacaktır.

Bu konu için mevcut rehberimiz:

WordPress Heartbeat API Nedir? Sunucu Kaynağını Nasıl Etkiler?

Bu bağlantı özellikle önemli çünkü güncel kritik yetim raporunda WordPress Heartbeat API yazısı hâlâ 0 bağlamsal gelen bağlantıyla görünüyor.

💡 İpucu: Heartbeat kaynaklı bir problemden şüpheleniyorsanız API’yi doğrudan kapatmak yerine önce hangi eklenti veya işlemin yoğun istek oluşturduğunu araştırın.

🔐 WordPress Debug ve Güvenlik Eklentileri

Debug kayıtlarında eklenti kaynaklı bir hata gördüğünüzde güvenlik eklentilerini de tamamen göz ardı etmemek gerekir.

Özellikle:

🛡️ Firewall

🔐 Login koruması

🚫 IP engelleme

🤖 Bot kontrolleri

gibi özellikler WordPress’in farklı bölümlerine müdahale edebilir.

Birden fazla güvenlik eklentisi aynı görevi gerçekleştiriyorsa beklenmeyen davranışların ortaya çıkma ihtimali de artabilir.

WordPress güvenliği hakkında detaylı rehberimiz:

WordPress Güvenlik Eklentileri ve Ayarları Rehberi

Bu yazı da kritik yetim raporunda 0 bağlamsal gelen bağlantıyla yer alıyor.

🛡️ İpucu: Aynı görevi yapan birden fazla güvenlik eklentisini birlikte kullanmadan önce her birinin hangi özelliği sağladığını kontrol edin.

🖥️ WordPress Debug Hosting Kaynaklı Hatalar

Bazen WordPress’te meydana gelen bir hata doğrudan sitenin kodundan kaynaklanmayabilir.

Hosting tarafındaki:

🧠 RAM

⚙️ CPU

🐘 PHP yapılandırması

📦 PHP process limitleri

💾 Disk kaynakları

gibi faktörler de WordPress’in çalışma şeklini etkileyebilir.

Bu nedenle debug kayıtlarını incelerken yalnızca WordPress tarafına odaklanmak yerine hosting altyapısını da değerlendirmek gerekir.

Özellikle WordPress için hosting seçimi yaparken kaynakların sitenin ihtiyaçlarına uygun olması önemlidir.

WordPress Hosting Satın Al: Doğru Hosting Nasıl Seçilir? 2026

Bu yazı da güncel kritik yetim listesinde 0 bağlamsal gelen bağlantıya sahip.

🧩 SCRIPT_DEBUG Nedir?

Bazı WordPress problemleri PHP tarafında değil JavaScript veya CSS tarafında meydana gelir.

Örneğin:

❌ Mobil menü açılmıyor.

❌ Buton çalışmıyor.

❌ Gutenberg editörü düzgün yüklenmiyor.

❌ Popup çalışmıyor.

❌ Slider çalışmıyor.

gibi problemler tarayıcı tarafında oluşabilir.

Bu durumda:

define( 'SCRIPT_DEBUG', true );

kullanılabilir.

SCRIPT_DEBUG, WordPress’in geliştirme sürümü JavaScript ve CSS dosyalarını kullanmasına yardımcı olabilir.

Ayrıca tarayıcının geliştirici araçlarındaki Console bölümünü de kontrol etmek gerekir.

💡 İpucu: Problem yalnızca menü, buton veya popup gibi tarayıcı tarafındaki bir özellikteyse debug.log ile birlikte tarayıcı Console kayıtlarını da inceleyin.

📱 Mobilde Görülen WordPress Debug Hataları

Bir hata yalnızca mobil cihazlarda ortaya çıkıyorsa problemin doğrudan PHP kaynaklı olduğu varsayılmamalıdır.

Örneğin:

📱 Mobil menü

📱 JavaScript

📱 Responsive CSS

📱 Lazy Load

📱 Cache

gibi bileşenler mobil tarafta farklı davranabilir.

WordPress mobil uyumluluğu hakkında mevcut rehberimiz:

WordPress Mobil Uyumluluk Nedir? Mobil SEO Rehberi

Bu yazı da kritik yetim raporunda 0 bağlamsal gelen bağlantıyla listeleniyor.

🗑️ WordPress Debug Modu Nasıl Kapatılır?

Hata teşhis işlemi tamamlandıktan sonra Debug Modu’nu kapatmanız gerekir.

Örneğin:

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

şeklinde production yapılandırmasına geri dönebilirsiniz.

Ardından artık gerekli değilse:

/wp-content/debug.log

dosyasını da güvenli şekilde temizleyebilirsiniz.

🔐 İpucu: Sorun çözüldükten sonra Debug Modu’nu açık bırakmayın. Özellikle log dosyasının web üzerinden erişilebilir durumda olmadığını kontrol edin.

🔒 debug.log Güvenlik Açığı Oluşturabilir mi?

Yanlış yapılandırılmış bir debug sistemi güvenlik riski oluşturabilir.

Bir log dosyasında:

📁 Dosya yolları

🔌 Eklenti isimleri

🎨 Tema bilgileri

🐘 PHP detayları

⚙️ Teknik hata mesajları

bulunabilir.

Bu nedenle debug.log dosyasının herkese açık şekilde görüntülenebilir olmaması önemlidir.

WordPress’in wp-config.php dokümantasyonunda da debug kayıtlarının güvenliği konusunda dikkat edilmesi gereken noktalar açıklanmaktadır. wp-config.php – Resmi WordPress Dokümantasyonu

🛠️ WordPress Debug İçin Uygulanabilecek Kontrol Listesi

Bir WordPress hatasıyla karşılaştığınızda:

1️⃣ Yedek alın.

2️⃣ Problemin ne zaman başladığını belirleyin.

3️⃣ Son yüklenen veya güncellenen eklentiyi not edin.

4️⃣ WP_DEBUG’u etkinleştirin.

5️⃣ WP_DEBUG_LOG’u etkinleştirin.

6️⃣ WP_DEBUG_DISPLAY’i kapatın.

7️⃣ Hatayı tekrar oluşturun.

8️⃣ debug.log dosyasını inceleyin.

9️⃣ Eklenti ve tema dosya yollarını kontrol edin.

🔟 PHP sürümünü kontrol edin.

1️⃣1️⃣ Memory Limit değerini kontrol edin.

1️⃣2️⃣ Gerekirse staging üzerinde tekrar test edin.

1️⃣3️⃣ Problemi çözdükten sonra Debug Modu’nu kapatın.

Bu sıralama sayesinde rastgele eklenti silmek veya onlarca ayarı aynı anda değiştirmek yerine problemi sistematik şekilde izole edebilirsiniz.

🚫 WordPress Debug Kullanırken Yapılmaması Gerekenler

❌ WordPress Debug Ayarını Sürekli Açık Bırakmayın

Debug işlemi tamamlandıktan sonra production yapılandırmasına dönün.

❌ Hataları Ziyaretçiye Göstermeyin

Özellikle canlı sitelerde PHP hata detaylarını doğrudan ekrana bastırmayın.

❌ wp-config.php Dosyasını Yedeksiz Değiştirmeyin

Yanlış bir PHP yapılandırması sitenin çalışmasını etkileyebilir.

❌ Aynı Anda Çok Fazla Değişiklik Yapmayın

Hangi değişikliğin problemi çözdüğünü belirleyemezsiniz.

❌ debug.log’u Kontrolsüz Bırakmayın

Log dosyasının erişilebilirliği ve içeriği kontrol edilmelidir.

🧠 WordPress Debug Modu ile Eklenti Çakışması Arasındaki Fark

Bu iki kavramı birbirinden ayırmak önemlidir.

Eklenti çakışması, problemin kaynağı olabilir.

Debug Modu, bu problemin kaynağını araştırmak için kullanılan araçlardan biridir.

Örneğin:

Eklenti güncellendi
       ↓
Site hata verdi
       ↓
WP_DEBUG açıldı
       ↓
debug.log incelendi
       ↓
Eklenti dosyasında hata görüldü
       ↓
Eklenti izole edildi
       ↓
Sorun doğrulandı

Bu nedenle Debug Modu, eklenti çakışması gibi problemlerde teşhis aşamasında oldukça değerlidir.

📌 Sonuç

WordPress Debug Modu, sitenizde meydana gelen teknik problemlerin kaynağını araştırmak için kullanabileceğiniz en önemli yerleşik araçlardan biridir.

Özellikle:

🔌 Eklenti hataları

🎨 Tema problemleri

🐘 PHP uyumsuzlukları

🧠 Memory Limit sorunları

🚨 Kritik WordPress hataları

🐞 PHP hataları

gibi durumlarda WP_DEBUG ve debug.log önemli ipuçları sağlayabilir.

En temel yapı:

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

şeklindedir.

Ancak Debug Modu’nu açmak kadar işiniz bittiğinde kapatmak da önemlidir.

💡 AydınCloud İpucu: Debug’u açın, hatayı tekrar oluşturun, debug.log üzerinden kaynağı bulun, problemi çözün ve ardından Debug Modu’nu kapatın.

Böylece WordPress problemlerini tahmin ederek değil, mümkün olduğunca teknik kayıtlar üzerinden analiz edebilirsiniz.

❓ Sık Sorulan Sorular

WordPress Debug Modu nedir?

WordPress Debug Modu, WordPress içerisinde meydana gelen PHP hata, uyarı ve bazı teknik bildirimleri daha ayrıntılı şekilde incelemenizi sağlayan hata ayıklama sistemidir.

WP_DEBUG nasıl açılır?

wp-config.php dosyasına:

define( 'WP_DEBUG', true );

satırı eklenerek veya mevcut false değeri true olarak değiştirilerek etkinleştirilebilir.

WP_DEBUG_LOG ne işe yarar?

WordPress hata kayıtlarının log dosyasına kaydedilmesini sağlar. Varsayılan yapılandırmada kayıtlar wp-content/debug.logiçerisinde tutulabilir.

debug.log nerede bulunur?

Varsayılan olarak:

/wp-content/debug.log

konumunda bulunabilir.

WP_DEBUG_DISPLAY nedir?

Hata mesajlarının ziyaretçinin ekranında gösterilip gösterilmeyeceğini kontrol eder.

WordPress Debug Modu canlı sitede açık bırakılır mı?

Genellikle hayır. Sorun teşhis edildikten sonra kapatılması ve hata detaylarının ziyaretçilere gösterilmemesi gerekir.

Eklenti çakışması debug.log üzerinden bulunabilir mi?

Birçok PHP tabanlı eklenti probleminde log içerisinde eklenti dosyasının yolu ve hata mesajı görülebilir. Ancak kesin sonuca ulaşmak için hata mesajı, zamanlama, tema ve diğer eklentiler de değerlendirilmelidir.

WordPress Debug kritik hata aldığımda ne yapmalıyım?

Son yapılan değişiklikleri kontrol edin, Debug Modu’nu etkinleştirin, hatayı tekrar oluşturun ve debug.log içerisindeki son kayıtları inceleyin.

WordPress Debug Modu siteyi yavaşlatır mı?

Debug işlemleri ek hata raporlama ve loglama yaptığı için sürekli açık bırakılması önerilmez. Sorun teşhis edildikten sonra kapatılmalıdır.

debug.log silinebilir mi?

Sorun teşhis edildikten sonra log dosyası temizlenebilir. İleride ihtiyaç duyulabilecek kayıtlar varsa güvenli bir yerde saklanabilir.