WordPress wp-config.php Sabitleri Rehberi: Güvenlik ve Performans İçin Kritik Ayarlar

18 Mayıs 2026 WPNeta No comments yet

WordPress wp-config.php sabitleri rehberi kapak görseli

Kısa Özet: WordPress sitenizin kalbi wp-config.php dosyasıdır. Bu dosyaya tanımlayacağınız sabitler güvenliği güçlendirir, performansı artırır, geliştirme sürecini kolaylaştırır ve sorun çözümünü hızlandırır. Bu rehberde site sahiplerinin bilmesi gereken tüm kritik wp-config.php sabitlerini, doğru değerleri ve gerçek senaryolarla uygulanışını adım adım ele alıyoruz.

wp-config.php Neden Bu Kadar Kritik?

WordPress kurulumunuzun temel yapılandırma dosyası olan wp-config.php, sitenizin veritabanına bağlanma bilgilerinden tutun da hata ayıklamaya, güvenlik anahtarlarından bellek limitlerine kadar pek çok davranışı tek bir noktadan kontrol etmenizi sağlar. WordPress’in geri kalan tüm dosyalarını güncelleseniz bile, bu dosya kurulumunuza özel kaldığı için sizin özel ayarlarınızı korur.

Bir site sahibi olarak wp-config.php dosyasında ne olduğunu, hangi sabitin neye yaradığını ve hangi durumlarda hangi değeri kullanmanız gerektiğini bilmek; sitenizi karanlıkta kullanmakla, gerçekten yönetmek arasındaki farktır. Yanlış yapılandırılmış bir sabit beyaz ekran hatasına yol açabilir; doğru yapılandırılmış bir set sabit ise sitenizin saldırılara dayanıklılığını ciddi şekilde artırır.

Bu yazıda yedekleme, güvenlik anahtarları, dosya düzenleme kısıtlamaları, bellek limitleri, hata ayıklama bayrakları, otomatik güncelleme, multisite ve veritabanı seçenekleri başta olmak üzere wp-config.php dosyasını üreten, anlamlandıran ve güvenli biçimde kullanmanızı sağlayan tüm temel sabitleri ele alıyoruz.

wp-config.php Dosyasını Bulma ve Düzenleme

Dosyanın Yerini Tespit Etmek

wp-config.php dosyası standart kurulumlarda WordPress kök dizinindedir; yani wp-content, wp-admin ve wp-includes klasörlerinin bulunduğu klasörde. Hosting firmanızın kontrol panelinde Dosya Yöneticisi’ni veya SSH/SFTP erişimini kullanarak dosyaya ulaşabilirsiniz.

Bazı kurulumlarda güvenlik amacıyla wp-config.php dosyası bir üst dizine taşınmış olabilir. WordPress, public dizinin bir üstündeki wp-config.php dosyasını otomatik olarak okur. Bu pratik, dosya web üzerinden erişilemez hale geldiği için ek bir güvenlik katmanı sağlar.

Düzenlemeden Önce Yapılması Gerekenler

Bu dosyada yapacağınız küçük bir yazım hatası bile sitenizi tamamen erişilemez hale getirebilir. Bu yüzden her zaman aşağıdaki sırayı izleyin:

Tam yedek alın. Hem dosya sisteminin hem de veritabanının yedeğini almadan kesinlikle düzenleme yapmayın. UpdraftPlus, BackWPup veya hosting sağlayıcınızın yedek aracını kullanabilirsiniz.
Mevcut dosyanın kopyasını saklayın. Sunucuda wp-config.php dosyasını wp-config.backup.php olarak kopyalayın. Sorun çıktığında orijinale geri dönmek saniyeler sürer.
Yerel düzenleyici kullanın. Notepad++, VS Code veya Sublime gibi UTF-8 destekli bir editör kullanın. Microsoft Word, BBT veya rich text editörler dosyayı bozar.
Staging ortamında test edin. Mümkünse değişiklikleri önce bir staging (deneme) sitesinde test edin ve canlıya öyle uygulayın.

Dosya başında her zaman bir <?php etiketi olduğunu, kapanış etiketi olmadığını unutmayın. Yeni sabitleri her zaman /* That's all, stop editing! Happy publishing. */ satırının üstüne ekleyin.

Güvenlik Sabitleri

Aşağıdaki sabitler, sitenizin saldırı yüzeyini ciddi biçimde küçültür. Hepsini ihtiyacınız ölçüsünde değerlendirin; çoğunu olduğu gibi açabilirsiniz.

DISALLOW_FILE_EDIT — Yönetici Panelinden Dosya Düzenlemeyi Kapatma

WordPress varsayılan olarak, yönetici rolündeki bir kullanıcının “Görünüm > Tema Dosyası Düzenleyicisi” veya “Eklentiler > Eklenti Dosyası Düzenleyicisi” üzerinden tema ve eklenti dosyalarını doğrudan düzenlemesine izin verir. Bir saldırgan yönetici hesabını ele geçirirse bu özelliği kötüye kullanarak siteye arka kapı yerleştirebilir.

define( 'DISALLOW_FILE_EDIT', true );

Bu satırı tanımladığınızda söz konusu düzenleyiciler panelden tamamen kaybolur. Dosya değişikliklerini her zaman SFTP veya Git üzerinden yapın.

DISALLOW_FILE_MODS — Eklenti ve Tema Kurulumunu Tamamen Kapatma

Daha katı bir önlem ister misiniz? Bu sabit, kullanıcıların panelden eklenti/tema yüklemesini, güncellemesini veya silmesini engeller; otomatik güncellemeleri de kapatır:

define( 'DISALLOW_FILE_MODS', true );

Üretim sitelerinde, özellikle kritik ticari sitelerde, değişikliklerin yalnızca planlı bakım pencerelerinde yapılması istenir. Bu sabit panelden gelen tüm değişikliklerin önünü keser.

FORCE_SSL_ADMIN — Yönetim Panelini HTTPS’ye Zorla

SSL sertifikanız varsa yönetim panelinin HTTPS üzerinden çalışmasını zorunlu kılın; aksi halde oturum çerezleri ağ dinleyicileri tarafından çalınabilir.

define( 'FORCE_SSL_ADMIN', true );

Sitenin önünde Cloudflare gibi bir CDN/proxy varsa ve “Flexible SSL” kullanıyorsanız, sonsuz yönlendirme döngülerini önlemek için HTTP_X_FORWARDED_PROTO kontrolü eklemeniz gerekir:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

WordPress Güvenlik Anahtarları (Salts)

Çerez ve oturum verilerini imzalamak için kullanılan sekiz adet rastgele dizgedir. Bu anahtarlar sızdırıldığında veya hiç değiştirilmediğinde, saldırgan oturum çerezlerini taklit edebilir.

define( 'AUTH_KEY',         'rastgele-uzun-bir-dize' );
define( 'SECURE_AUTH_KEY',  'rastgele-uzun-bir-dize' );
define( 'LOGGED_IN_KEY',    'rastgele-uzun-bir-dize' );
define( 'NONCE_KEY',        'rastgele-uzun-bir-dize' );
define( 'AUTH_SALT',        'rastgele-uzun-bir-dize' );
define( 'SECURE_AUTH_SALT', 'rastgele-uzun-bir-dize' );
define( 'LOGGED_IN_SALT',   'rastgele-uzun-bir-dize' );
define( 'NONCE_SALT',       'rastgele-uzun-bir-dize' );

WordPress’in resmi anahtar üretici aracından (api.wordpress.org/secret-key/1.1/salt/) yepyeni anahtarlar üretip dosyanıza yapıştırın. Bu işlem giriş yapmış tüm kullanıcıların oturumunu sonlandırır; ciddi olaylardan sonra anahtarları yenilemek standart bir kurtarma adımıdır.

Veritabanı Tablo Öneki ($table_prefix)

WordPress varsayılan olarak wp_ önekini kullanır. Bu önek tahmin edildiğinde, SQL enjeksiyon saldırıları biraz daha kolaylaşır. Yeni kurulumlarda farklı bir önek seçin:

$table_prefix = 'wpn_2k26_';

Mevcut sitelerde öneki değiştirmek için veritabanı sorguları çalıştırmanız ve seri hale getirilmiş seçenek değerlerini güncellemeniz gerekir; bu işlem profesyonel destekle yapılmalıdır.

Performans ve Bellek Sabitleri

Aşağıdaki sabitler, sitenizin daha hızlı ve daha kararlı çalışmasını sağlar. Özellikle WooCommerce ve sayfa oluşturucu eklentileri kullanan sitelerde bellek limitleri kritik öneme sahiptir.

WP_MEMORY_LIMIT ve WP_MAX_MEMORY_LIMIT

WordPress’in ön yüzü ve API için kullanabileceği maksimum PHP belleğini belirler. Yönetici paneli ve uzun süreli işlemler için ayrıca WP_MAX_MEMORY_LIMIT sabiti tanımlanır.

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

Hata günlüklerinde “Allowed memory size of X bytes exhausted” mesajı görüyorsanız ilk yapacağınız iş bu sabitleri artırmaktır. Yine de hosting paketinizin PHP memory_limit değerini de uygun seviyeye getirmeniz gerekir; php.ini, .user.ini veya cPanel/Plesk’in PHP yapılandırma ekranından bu değişiklik yapılabilir.

WP_CACHE — Sayfa Önbelleği

WP Super Cache, W3 Total Cache veya LiteSpeed Cache gibi eklentiler bu sabitin true olmasını ister:

define( 'WP_CACHE', true );

Eklentinin etkin olabilmesi için wp-content/advanced-cache.php dosyasının kurulu ve bu sabitin tanımlı olması gerekir. Sayfa önbelleğini açtığınızda Time to First Byte (TTFB) belirgin biçimde düşer.

CONCATENATE_SCRIPTS

Yönetici panelindeki çok sayıda küçük JS dosyasının tek bir dosyada birleşmesini engeller. SSL veya HTTP/2 sorunlarına bağlı olarak panel yüklenmiyorsa şu satırı deneyin:

define( 'CONCATENATE_SCRIPTS', false );

Otomatik Kaydetme ve Revizyonlar

WordPress, gönderiyi düzenlerken belirli aralıklarla otomatik kaydeder ve tüm geçmiş sürümleri veritabanında tutar. Yoğun blog sitelerinde revizyonlar veritabanını şişirir. Aşağıdaki değerlerle kontrol altına alın:

define( 'AUTOSAVE_INTERVAL', 120 );   // saniye cinsinden (varsayılan 60)
define( 'WP_POST_REVISIONS', 5 );     // gönderi başına en fazla 5 revizyon
define( 'EMPTY_TRASH_DAYS',  14 );    // çöp 14 günde kalıcı silinir

Revizyonları tamamen kapatmak istiyorsanız WP_POST_REVISIONS değerini false yapabilirsiniz; ancak küçük bir revizyon havuzunun korunmasını öneririz, içerik kazaları için emniyet kemeridir.

Geliştirme ve Hata Ayıklama Sabitleri

Beyaz ekran, eksik içerik veya yavaş istekler gibi belirsiz sorunları tespit etmenin en güvenilir yolu WordPress’in dahili hata ayıklama özelliklerini açmaktır. Bu sabitler bir cerrahın el feneridir.

WP_DEBUG

define( 'WP_DEBUG', true );

Bu sabit aktifken WordPress PHP uyarıları, notlar ve ölümcül hatalar dahil pek çok uyarıyı görünür kılar. Üretim ortamında ekrana hata yazdırmak istemezsiniz; ama günlüğe yazdırmak çok değerlidir.

WP_DEBUG_LOG ve WP_DEBUG_DISPLAY

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

Bu kombinasyon hataları kullanıcılardan saklar; ancak wp-content/debug.log dosyasına yazar. WP_DEBUG_LOG sabitini özel bir yol olarak da tanımlayabilirsiniz: define( 'WP_DEBUG_LOG', '/var/log/wp/site.log' ). Üretim ortamında bir defa açıp ardından log dosyasını incelemek, neredeyse her sorunu hızla tespit etmenizi sağlar.

SCRIPT_DEBUG

define( 'SCRIPT_DEBUG', true );

Geliştiriciye yönelik bir bayraktır. WordPress varsayılan olarak minify edilmiş JS/CSS dosyalarını yükler; SCRIPT_DEBUG açıldığında yorum ve okunabilir kaynak içeren tam sürümler kullanılır. JavaScript hata izleme sürecinde işinizi kolaylaştırır.

SAVEQUERIES

define( 'SAVEQUERIES', true );

Çalıştırılan tüm SQL sorgularını bellekte tutar. Query Monitor eklentisi ile birleştirildiğinde, hangi eklentinin veritabanını yorduğunu anında görebilirsiniz. Yalnızca geliştirme veya teşhis amaçlı açın; üretimde performansı kötüleştirir.

URL ve Site Yapılandırması

WP_HOME ve WP_SITEURL

Site URL bilgisini veritabanından değil, doğrudan dosyadan zorlamak istiyorsanız aşağıdaki sabitleri tanımlayın:

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

Bu sabitler özellikle taşıma veya alan adı değişikliği sonrasında yönlendirme döngülerinden kurtulmak için altın değerindedir. Tanımlı oldukları sürece yönetici panelinden “Genel Ayarlar” altında WordPress Adresi ve Site Adresi alanları gri olarak gözükür.

WP_CONTENT_DIR ve WP_CONTENT_URL

wp-content klasörünüzü farklı bir yere taşıdıysanız (örneğin app/), şu sabitleri tanımlamanız gerekir:

define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . '/app/wp-content' );
define( 'WP_CONTENT_URL', 'https://wpneta.com/app/wp-content' );

Aynı şekilde WP_PLUGIN_DIR, WP_PLUGIN_URL, UPLOADS ve WPMU_PLUGIN_DIR sabitleriyle eklenti, yükleme ve must-use eklenti dizinlerini özelleştirebilirsiniz.

WPLANG ve Dil Ayarı

Eski WordPress sürümlerinde dil tanımı için WPLANG kullanılırdı. Modern sürümlerde dil seçimi panelden yapılır; ancak çok dilli kurulumlarda WPLANG hâlâ bazı eklentilerce okunmaktadır:

define( 'WPLANG', 'tr_TR' );

Veritabanı Sabitleri

DB_HOST, DB_NAME, DB_USER, DB_PASSWORD

define( 'DB_NAME',     'wpneta_db' );
define( 'DB_USER',     'wpneta_user' );
define( 'DB_PASSWORD', 'guclu-sifre' );
define( 'DB_HOST',     'localhost' );
define( 'DB_CHARSET',  'utf8mb4' );
define( 'DB_COLLATE',  '' );

Şifre içinde $ veya ' karakterleri varsa PHP bunları beklenmedik biçimde yorumlayabilir; mümkünse alfanümerik + güvenli sembollerden oluşan şifreler kullanın. DB_HOST alanı; bazı yönetilen hostinglerde “localhost:/var/run/mysqld/mysqld.sock” veya “127.0.0.1:3307” gibi olabilir, doküman kontrolü şarttır.

DB_CHARSET ve DB_COLLATE

Emojiler, özel karakterler ve Türkçe karakterler için utf8mb4 kullanın. Sürüm 4.2 ile birlikte yeni kurulumların varsayılanı budur; ancak eski veritabanlarınızı manuel olarak güncellemeniz gerekebilir.

Veritabanı Onarımı

“One or more database tables are unavailable” hatasında WordPress’in dahili onarım scripti çalıştırılabilir. Geçici olarak şu sabit açılır:

define( 'WP_ALLOW_REPAIR', true );

Ardından https://wpneta.com/wp-admin/maint/repair.php adresine giderek tabloları onarın. Onarımdan hemen sonra bu sabiti kaldırın; aksi halde herkes onarım scriptini çalıştırabilir.

Otomatik Güncelleme Sabitleri

WordPress; çekirdek, eklenti ve tema güncellemelerini otomatik olarak uygulayabilir. Üretim sitelerinde otomatik güncellemeleri kontrollü bir politika ile yönetmek isteyebilirsiniz.

WP_AUTO_UPDATE_CORE

define( 'WP_AUTO_UPDATE_CORE', 'minor' );   // sadece minor güvenlik güncellemeleri
// veya
define( 'WP_AUTO_UPDATE_CORE', true );       // tüm sürümler (minor + major)
// veya
define( 'WP_AUTO_UPDATE_CORE', false );      // tamamen kapalı

Önerimiz: kararlılık ve güvenlik dengesini en iyi sağlayan 'minor' değeridir.

AUTOMATIC_UPDATER_DISABLED

Her türlü otomatik güncellemeyi durdurmak için:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Bu sabit aktifken çekirdek, tema, eklenti ve çeviri güncellemeleri tamamen kapatılır. Hata yapma ihtimaliniz arttığı için ancak bilinçli bir yayın yönetimi süreciniz varsa kullanın.

Multisite Sabitleri

WordPress Multisite (Network) yapılandırması için aşağıdaki sabitler kritik öneme sahiptir:

define( 'WP_ALLOW_MULTISITE', true );
define( 'MULTISITE',          true );
define( 'SUBDOMAIN_INSTALL',  false );
define( 'DOMAIN_CURRENT_SITE', 'wpneta.com' );
define( 'PATH_CURRENT_SITE',   '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Bu sabitleri elle eklemek yerine, “Tools > Network Setup” sihirbazından üretilen blok değerleri kullanmanız çok daha güvenlidir. Yanlış yapılandırılmış multisite, ağ üzerindeki tüm siteleri etkiler.

WP-Cron Sabitleri

DISABLE_WP_CRON

Trafik aldığınız her sayfada WordPress, zamanlanmış görevleri tetiklemek için wp-cron.php dosyasını çağırır. Yüksek trafikli sitelerde bu çok fazla ek yük getirir. Sunucu seviyesinde gerçek bir cron job kurmak en sağlıklı çözümdür:

define( 'DISABLE_WP_CRON', true );

Ardından cPanel/SSH üzerinden 5 dakikada bir çalışan gerçek bir cron tanımlayın:

*/5 * * * * /usr/local/bin/php /home/user/public_html/wp-cron.php > /dev/null 2>&1

WP_CRON_LOCK_TIMEOUT

WP-Cron’un çakışan çalıştırmaları engellemek için kullandığı kilitleme süresidir. Çok yavaş çalışan görev zincirleri için artırılabilir:

define( 'WP_CRON_LOCK_TIMEOUT', 120 );

Diğer Faydalı Sabitler

WP_HTTP_BLOCK_EXTERNAL

Sitenizin dış servislere HTTP isteği yapmasını engeller. Eklentiler tarafından yapılan çağrıları kısıtlamak için kullanılır:

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS',     'api.wordpress.org,*.cloudflare.com' );

İlk sabit tüm dış istekleri engeller; ikinci sabit yalnızca izin verilen alanları tanımlar. Veri sızıntısı yapan şüpheli eklentileri tespit ederken çok değerlidir.

FS_METHOD

WordPress’in dosya yazma yöntemini zorlamak için kullanılır. “FTP bilgileri istiyor” hatasında genelde direct kullanılır:

define( 'FS_METHOD', 'direct' );

Bu sabit aktifken WordPress, dosya işlemlerini doğrudan PHP üzerinden yapar; FTP veya SSH istemez. Ancak dosya izinlerinizin doğru olması (genellikle dosyalar 644, dizinler 755) şarttır.

WP_TEMP_DIR

WordPress’in geçici dosyaları sakladığı dizini belirler. Yükleme hatalarında alternatif bir konum tanımlayabilirsiniz:

define( 'WP_TEMP_DIR', dirname( __FILE__ ) . '/wp-content/tmp' );

IMAGE_EDIT_OVERWRITE

WordPress, görseli her düzenlediğinizde yeni bir kopya oluşturur. Bu sabit etkin olduğunda, eski kopyalar silinir ve disk alanı israfı önlenir:

define( 'IMAGE_EDIT_OVERWRITE', true );

Önerilen Üretim Yapılandırması

Yukarıdaki bilgileri birleştirerek tipik bir üretim sitesi için aşağıdaki wp-config.php bloğunu öneririz:

// --- WPNeta üretim önerisi (wp-config.php) ---
// Güvenlik
define( 'DISALLOW_FILE_EDIT', true );
define( 'FORCE_SSL_ADMIN',    true );

// Hata ayıklama (üretimde gizli loglama)
define( 'WP_DEBUG',         true );
define( 'WP_DEBUG_LOG',     true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// Bellek limitleri
define( 'WP_MEMORY_LIMIT',     '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

// İçerik temizliği
define( 'WP_POST_REVISIONS', 5 );
define( 'AUTOSAVE_INTERVAL', 120 );
define( 'EMPTY_TRASH_DAYS',  14 );

// Önbellek + WP-Cron
define( 'WP_CACHE',          true );
define( 'DISABLE_WP_CRON',   true );

// Güncelleme politikası
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// Dosya işlemleri
define( 'FS_METHOD',            'direct' );
define( 'IMAGE_EDIT_OVERWRITE', true );

Geliştirme ortamında WP_DEBUG_DISPLAY değerini true yapın, üretimde mutlaka false bırakın. Eklenti çatışması yaşıyorsanız DISALLOW_FILE_MODS sabitini geçici olarak kapatmayı unutmayın.

Sorun Giderme Checklist

wp-config.php düzenledikten sonra siteniz açılmıyorsa şu adımları sırayla uygulayın:

Sözdizimi kontrolü: SSH erişiminiz varsa php -l wp-config.php komutuyla dosyada yazım hatası olup olmadığını anında öğrenebilirsiniz.
Yedeği geri yükleyin: Az önce kopyaladığınız wp-config.backup.php dosyasını wp-config.php olarak geri yükleyin.
Bilinmeyen karakterler: Dosyanın başında veya sonunda görünmez bir BOM (byte order mark) varsa beyaz ekran oluşur. Editörünüzü “UTF-8 without BOM” olarak ayarlayın.
İzinler: wp-config.php izinleri 600 veya 640 olmalıdır. 644 yapın ama 777 asla yapmayın.
Hata günlüğü: Hosting kontrol panelinizdeki “Error Log” bölümünden, son hatayı okuyun. Genelde “syntax error, unexpected …” gibi net bir mesaj görürsünüz.
Veritabanı erişimi: DB_HOST, DB_NAME, DB_USER, DB_PASSWORD değerlerini hosting panelinizdeki bilgilerle birebir karşılaştırın.
Eklenti çatışması: wp-content/plugins klasörünü geçici olarak plugins-off şeklinde yeniden adlandırın. Site açılırsa sorunlu eklentiyi bulmak için tekrar eski isme döndürüp eklentileri tek tek aktive edin.
Tema sorunu: Geçerli temayı wp-content/themes içinde geçici olarak yeniden adlandırın; WordPress otomatik olarak varsayılan tema üzerine geçer.
PHP versiyonu: Hosting panelinizden PHP 8.1 veya 8.2’yi seçin. Çok eski sürümlerde bazı sabitler beklenmedik davranabilir.
Önbelleği temizleyin: Hem tarayıcı önbelleğini hem de varsa sunucu seviyesindeki önbellek (LiteSpeed, Varnish, Cloudflare) kayıtlarını silin.

Sık Sorulan Sorular (FAQ)

wp-config.php dosyasını silebilir miyim?

Hayır. WordPress kurulumu bu dosya olmadan çalışamaz. Yedek almadan kesinlikle silmeyin. Yeni bir wp-config.php üretmek için wp-config-sample.php dosyasını kopyalayıp düzenleyebilirsiniz.

Sabitleri kullanmak yerine hosting kontrol panelinden değer girebilir miyim?

PHP bellek limiti, dosya yükleme boyutu gibi bazı değerler hosting panelinden de tanımlanır. Ancak WordPress’e özgü sabitler (örn. DISALLOW_FILE_EDIT, WP_DEBUG) yalnızca wp-config.php içinden tanımlanabilir.

Güvenlik anahtarlarını ne sıklıkta yenilemeliyim?

Standart olarak yılda bir kez yenilemenizi öneririz. Şüpheli bir aktivite, çalınmış yönetici şifresi veya hack şüphesi durumunda ise saniyeler içinde yenileyin. Anahtar değişimi tüm oturumları sonlandırarak saldırganın çerez tabanlı erişimini keser.

WP_DEBUG’ı sürekli açık tutsam ne olur?

Üretimde WP_DEBUG‘ı açık tutabilirsiniz; ama WP_DEBUG_DISPLAY mutlaka false olmalı. Aksi halde uyarı ve hata mesajları ziyaretçilere ve botlara dizin yapısı, eklenti isimleri gibi hassas bilgiler sızdırır.

Yedek almadan değişiklik yaparsam ne olur?

Tek bir nokta veya tırnak hatası bile HTTP 500 yanıtı veya tamamen boş bir sayfa üretebilir. Bu durumda yapacağınız tek şey dosyaya tekrar girerek hatayı düzeltmektir; fakat hatayı bulmak ve sitenin tekrar hizmet vermesi dakikalar veya saatler alabilir. Yedek almadan değiştirmek bir profesyonel için bile risk kabul edilmez.

Sabit tanımladığım halde değişiklik etkili olmuyor, neden?

İki klasik sebep: ilki, sabiti /* That's all, stop editing! Happy publishing. */ satırının altına eklemenizdir; bu durumda WordPress sabiti okumadan başlatılır. İkincisi, başka bir eklenti veya tema aynı sabiti farklı bir değerle tanımlamış olabilir. defined() kontrolü ile yarışma hatalarını ayıklayın.

Birden fazla site yöneten ajanslar için önerileriniz nedir?

Tüm sitelerinize ortak bir wp-config.php şablonu uygulayın. Şifre ve veritabanı bilgilerini ayrı bir .env dosyasından okumak için vlucas/phpdotenv gibi bir kütüphane kullanabilirsiniz. Müşteri sitelerini güçlendirmek ve düzenli tutmak için WPNeta blogundaki diğer rehberleri de inceleyin.

Kaynak Önerileri

WordPress Codex — Editing wp-config.php
WordPress Geliştirici Belgeleri — wp-config.php API
WordPress Salt üretici — api.wordpress.org/secret-key/1.1/salt/
WPNeta — WordPress Bellek Limiti Artırma Rehberi
WPNeta — WordPress Yedekleme Rehberi
WPNeta — WordPress Hack Sonrası Temizlik Adımları

Sonuç

wp-config.php dosyasını anlamak, WordPress’i amatör bir blog motorundan profesyonel bir üretim platformuna dönüştürür. Bu rehberdeki sabitlerin her birini ihtiyacınız ölçüsünde değerlendirin, ufak değişiklikleri staging ortamında deneyin ve canlıya ancak yedek aldıktan sonra geçin. Doğru ayarlanmış birkaç satır kod; veri kaybını, başarısız güncellemeleri, performans çöküşlerini ve saldırgan istilalarını önler.

Sitenizin teknik bakımı ile uğraşmadan içerik ve büyüme stratejinize odaklanmak isterseniz, WPNeta’nın profesyonel WordPress bakım hizmetlerini inceleyebilirsiniz. Yedekleme, güncelleme, güvenlik sıkılaştırma ve performans optimizasyonu paketlerimizle sitenizi her zaman düzenli, hızlı ve güvende tutuyoruz.