wp-config.php'de Bilinmesi Gereken Sabitler: WP_DEBUG, DISALLOW_FILE_EDIT ve Daha Fazlası

wp-config.php Neden Bu Kadar Kritik?

wp-config.php, bir WordPress kurulumunun en temel yapılandırma dosyasıdır. Veritabanı bağlantı bilgilerinden tablo önekine kadar sitenin çalışması için zorunlu olan ayarları barındırır. Ancak dosyanın asıl gücü, buraya eklenebilecek isteğe bağlı PHP sabitlerinde (constant) saklıdır: hata ayıklama davranışını, admin panelindeki dosya düzenleyicilerin açık olup olmadığını, SSL zorunluluğunu, bellek limitini ve daha birçok çekirdek davranışı bu sabitlerle değiştirebilirsiniz. Sorun şu ki bu sabitlerin çoğu bir WordPress kurulumunda varsayılan olarak tanımlı değildir ve nereye, nasıl ekleneceği bilinmezse hiçbir etki göstermez.

Sabitleri Doğru Yere Eklemek: Sıralama Kuralı

PHP'de bir sabit define() ile bir kez tanımlandıktan sonra yeniden tanımlanamaz — ikinci bir define() çağrısı sessizce yok sayılır, hata da vermez. WordPress çekirdeği de bu sabitlerin bir kısmı için kendi varsayılan değerlerini, çekirdek dosyalar yüklenirken daha aşağıda tanımlar. Bu yüzden eklediğiniz sabitler mutlaka /* That's all, stop editing! Happy publishing. */ satırından önce yer almalıdır. Sabit bu satırdan sonra eklenirse — yani çekirdeğin kendi varsayılan tanımı zaten çalışmışsa — define() satırınız dosyanın içinde durur ama hiçbir işe yaramaz; ne bir hata mesajı görürsünüz ne bir uyarı, sadece beklediğiniz davranış hiç gerçekleşmez.

En Çok Kullanılan 8 Sabit

Diğer Sabitler Hakkında Kısa Notlar

Tablodaki bazı sabitler daha az konuşulur ama günlük yönetimde işe yarar. FORCE_SSL_ADMIN, sertifikanız kurulu olduğu hâlde birileri admin paneline yanlışlıkla http:// üzerinden erişmeye çalışırsa oturumu otomatik olarak şifreli bağlantıya yönlendirir; giriş bilgilerinizin düz metin olarak ağ üzerinde dolaşmasını engeller. WP_POST_REVISIONS, varsayılan olarak sınırsız olan revizyon geçmişini belirli bir sayıya sabitler — sık düzenlenen bir içerik sitesinde bu, zamanla veritabanı tablolarının gereksiz yere şişmesini önler. WP_MEMORY_LIMIT ise sunucunuzun genel PHP bellek limitinden ayrı olarak, yalnızca WordPress'in kullanabileceği bellek miktarını belirler; barındırma sağlayıcınızın php.ini ayarı zaten yeterliyse bu sabitin pratikte bir etkisi olmaz, ama paylaşımlı barındırmada düşük bir varsayılan limitle karşılaşıldığında ilk başvurulacak çözümlerden biridir. AUTOMATIC_UPDATER_DISABLED ise dikkatli kullanılmalıdır: otomatik güncellemeleri kapatmak güncellemeleri sizin kontrolünüze bırakır, ancak güncellemeleri elle takip etmeyi de sizin sorumluluğunuza yükler.

Üretim Ortamında Doğru Hata Ayıklama: WP_DEBUG_LOG ve WP_DEBUG_DISPLAY

WP_DEBUG tek başına açıldığında PHP hataları, uyarıları ve bildirimleri doğrudan sayfa üzerinde, ziyaretçinin de görebileceği şekilde yazdırır. Bu, geliştirme ortamında sorun bulmak için yararlıdır ama canlı bir sitede bırakılırsa bilgi sızıntısı (information disclosure) riski taşır: hata çıktıları sunucu dosya yollarını, kullanılan eklenti sürümlerini ve dizin yapısını saldırganlara ifşa eder — bu, yaygın ve iyi bilinen bir zafiyet türüdür. Doğru yaklaşım WP_DEBUG_LOG ile WP_DEBUG_DISPLAY sabitlerini birlikte kullanmaktır: hatalar ekranda gösterilmez, bunun yerine wp-content/debug.log dosyasına yazılır. Böylece siz log dosyasını inceleyerek sorunu teşhis edebilirsiniz, ziyaretçiler ise hiçbir hata çıktısı görmez. Bu kombinasyon, üretim (production) sitelerinde önerilen hata ayıklama biçimidir.

DISALLOW_FILE_EDIT: Hem Önlem Hem Müdahale Adımı

wp-admin panelindeki yerleşik Tema Düzenleyici ve Eklenti Düzenleyici ekranları, admin paneline erişim sağlamış bir saldırganın doğrudan bir tema veya eklenti dosyasına kötü amaçlı PHP kodu eklemesinin en sık görülen yollarından biridir. Bu yüzden DISALLOW_FILE_EDIT sabiti iki farklı senaryoda karşımıza çıkar: bir site ele geçirildikten sonra uygulanan bilinen ilk müdahale adımlarından biri olarak, ve tehlike anını hiç beklemeden baştan uygulanan standart bir sertleştirme (hardening) adımı olarak. İkinci kullanım daha isabetlidir — sorun çıkmadan önce önlemi almış olursunuz ve saldırganın eline geçen bir admin oturumu bile bu yoldan kod ekleyemez.

Örnek: Birkaç Sabiti Birlikte Kullanmak

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

define( 'DISALLOW_FILE_EDIT', true );
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_POST_REVISIONS', 5 );
define( 'EMPTY_TRASH_DAYS', 30 );

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

Dikkat edilmesi gereken nokta, bu satırların tamamının yukarıdaki yorum satırından önce, dosyanın hâlâ düzenlenebilir kısmında yer almasıdır. Sıra önemli değildir, ama konum kesinlikle önemlidir.

Sık Yapılan Hatalar

• Sabitleri /* That's all, stop editing! */ satırından sonra eklemek — dosyada dururlar ama hiçbir etkileri olmaz.
• WP_DEBUG_DISPLAY'i canlı bir sitede açık bırakmak ve hata çıktılarını ziyaretçilere göstermek.
• Bu sabitlerin gerçek güvenlik önlemlerinin (güçlü parola, güncel yazılım, güvenlik duvarı, düzenli yedekleme) yerine geçtiğini düşünmek — bunlar destekleyici, tamamlayıcı ayarlardır, tek başına bir güvenlik stratejisi değildir.
• Aynı sabiti dosyada iki kez tanımlamaya çalışmak; PHP bunu bir hatayla karşılamaz ama sonraki define() çağrısı sessizce göz ardı edilir.

wp-config.php Sabit Oluşturucu

İhtiyacınız olan sabitleri seçin, doğru sıradaki kod bloğunu otomatik oluşturun ve doğrudan wp-config.php dosyanıza yapıştırın.

Bu sabitleri elle yazmak yerine, doğru sözdizimini ve konumu garanti eden bir araçla oluşturmak, özellikle birden fazla siteyi yöneten geliştiriciler için hem zaman kazandırır hem de sıralama hatasından kaynaklanan 'neden çalışmıyor' sorularını ortadan kaldırır.