wp-config.php: Her WordPress yöneticisinin bilmesi gereken 9 ayar

WordPress kurulumunda wp-config.php dosyasını genellikle bir kez açar, veritabanı adını ve şifresini yazıp kapatırız. Sonra yıllarca kimse dokunmaz. Oysa bu dosya, WordPress yüklenmeden önce okunan ilk yapılandırma dosyasıdır. Buraya yazdığınız sabitler bazı eklentilerin yaptığı işi tek satırla, eklentisiz yapar.

Aşağıdaki ayarların hepsi /* That's all, stop editing! */ satırının üstüne yazılmalıdır. Bu satırdan sonra eklenen tanımlar geç kalır ve çoğu zaman etkisiz olur.

1. Güvenlik anahtarlarını yenileyin

Dosyada AUTH_KEY, SECURE_AUTH_KEY gibi sekiz sabit vardır. Bunlar oturum çerezlerini imzalar. Kurulumda boş bırakılmışsa ya da site el değiştirdiyse yenileyin. WordPress'in resmi anahtar üreticisi (api.wordpress.org/secret-key/1.1/salt/) her açılışta yeni bir set verir.

Anahtarları değiştirdiğiniz anda tüm kullanıcıların oturumu kapanır. Bu, ele geçirildiğinden şüphelendiğiniz bir sitede tam da istediğiniz şeydir.

2. Panelden dosya düzenlemeyi kapatın

define( 'DISALLOW_FILE_EDIT', true );

Yönetim panelindeki tema ve eklenti düzenleyicisini kaldırır. Bir saldırgan yönetici hesabını ele geçirse bile panelden doğrudan PHP kodu yazamaz. Ben bu satırı her kurulumda ilk iş eklerim.

Daha katı bir seçenek DISALLOW_FILE_MODS sabitidir. Eklenti ve tema kurmayı, güncellemeyi de kapatır. Güncellemeleri WP-CLI ya da dağıtım sistemiyle yapıyorsanız uygundur. Aksi hâlde güncellemeleri unutturur; dikkatli olun.

3. Hata ayıklamayı doğru açın

Canlı sitede hatayı ekrana basmak, ziyaretçiye dosya yollarınızı göstermek demektir. Doğru kombinasyon şu:

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

Hatalar wp-content/debug.log dosyasına yazılır, ekranda görünmez. Sorunu çözdükten sonra WP_DEBUG değerini tekrar false yapın. Unutulan bir debug.log aylar içinde yüzlerce megabayta ulaşabilir ve dışarıdan okunabilir durumda kalabilir.

4. Revizyon sayısını sınırlayın

define( 'WP_POST_REVISIONS', 5 );

WordPress varsayılan olarak her kaydetmede sınırsız revizyon tutar. Yoğun düzenlenen bir yazının yüzlerce kopyası olabilir. Beş revizyon geri dönmek için yeterlidir, veritabanını da şişirmez.

5. Otomatik kaydetme aralığı

define( 'AUTOSAVE_INTERVAL', 120 );

Varsayılan 60 saniyedir. Çok yazarlı ve yoğun sitelerde 120 saniye sunucudaki gereksiz isteği azaltır.

6. Çöp kutusunun boşaltılması

define( 'EMPTY_TRASH_DAYS', 14 );

Silinen içerik varsayılan olarak 30 gün çöpte bekler. Bunu kısaltabilirsiniz. Ancak 0 yapmayın; çöp kutusu tamamen kapanır ve "Kalıcı olarak sil" tek seçenek olur.

7. Bellek sınırı

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

İlki ziyaretçi tarafı, ikincisi yönetim paneli içindir. Unutmayın: PHP'nin kendi memory_limit değeri bunun altındaysa WordPress'in istediği bir şey değiştirmez. Önce sunucunun sınırına bakın.

8. WP-Cron'u kapatıp gerçek cron'a geçin

define( 'DISABLE_WP_CRON', true );

Bu satırı tek başına eklerseniz zamanlanmış yazılar yayımlanmaz. Mutlaka sunucuda gerçek bir cron görevi tanımlamalısınız. Bunu ayrı bir yazıda adım adım anlattım.

9. Adresleri sabitleyin

define( 'WP_HOME', 'https://ornek.com' );
define( 'WP_SITEURL', 'https://ornek.com' );

Taşıma sonrası "siteye giriyorum, eski alan adına atıyor" sorunlarının en hızlı çözümüdür. Veritabanındaki siteurl ve home değerlerini ezer. Bir yan etkisi var: panelde Ayarlar → Genel'deki adres alanları kilitlenir. Bu bilinçli bir davranış.

Dosyanın kendisini koruyun

Son olarak wp-config.php'nin izinlerini kontrol edin. Paylaşımlı olmayan bir sunucuda 600 ya da 640 yeterlidir. Herkesin okuyabildiği (644) bir wp-config, aynı sunucudaki başka bir hesap ele geçirildiğinde veritabanı şifrenizi açık eder.

Bu dokuz ayarın hiçbiri eklenti gerektirmiyor. Hepsini bir kere doğru yaptığınızda yıllarca sorun çıkarmazlar.