WordPress kurulumunun en önemli dosyalarından biri yapılandırma dosyasıdır. Kök dizinde bulunur ve WordPress’in istediğiniz şekilde çalışmasını sağlayan sabit tanımlar ve PHP talimatları içerir.
wp -config.php dosyası, veritabanı bağlantı ayrıntıları, tablo öneki, belirli dizinlere giden yollar ve bu yazıda ele alacağımız belirli özelliklerle ilgili birçok ayar gibi verileri depolar.
wp-config.php Dosyası
WordPress’i ilk yüklediğinizde , veritabanı ayrıntıları ve tablo öneki gibi gerekli bilgileri girmeniz istenir. Bazen sunucunuz sizin için WordPress’i kurar ve kurulumu manuel olarak çalıştırmanız gerekmez. Ancak 5 dakikalık kurulumu manuel olarak çalıştırdığınızda, wp-config.php dosyasında depolanan en alakalı verilerden bazılarını girmeniz istenecektir.
İşte temel bir wp-config.php dosyası:
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'database_name_here');
/** MySQL database username */
define('DB_USER', 'username_here');
/** MySQL database password */
define('DB_PASSWORD', 'password_here');
/** MySQL hostname */
define('DB_HOST', 'localhost');
/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');
/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');
define('AUTH_SALT', 'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT', 'put your unique phrase here');
define('NONCE_SALT', 'put your unique phrase here');
$table_prefix = 'wp_';
/* That's all, stop editing! Happy blogging. */
Genellikle bu dosya, kurulumu çalıştırdığınızda otomatik olarak oluşturulur, ancak bazen WordPress’in kurulum klasörüne yazma ayrıcalıkları olmayabilir. Bu durumda, boş bir wp-config.php dosyası oluşturmalı , içeriği wp-config-sample.php dosyasından kopyalayıp yapıştırmalı ve tanımlanan tüm sabitlere uygun değerleri ayarlamalısınız. İşiniz bittiğinde dosyanızı kök klasöre yükleyin ve WordPress’i çalıştırın.
Not: Sabit tanımlar ve PHP talimatları asla değiştirmememiz gereken belirli bir sırayla gelir. Ve asla aşağıdaki yorum satırının altına içerik eklememeliyiz:
/* That's all, stop editing! Happy blogging. */
İlk olarak, ana makinenizden almanız gereken veritabanı sabitlerinin tanımlarına gelin:
DB_NAMEDB_USERDB_PASSWORDDB_HOSTDB_CHARSETDB_COLLATE
Veritabanı ayrıntılarının ardından sekiz güvenlik anahtarı, siteyi bilgisayar korsanlarına karşı daha güvenli hale getirecek. Kurulumu çalıştırdığınızda WordPress otomatik olarak güvenlik ve tuz anahtarları oluşturacaktır, ancak bunları istediğiniz zaman herhangi bir dize ekleyerek değiştirebilirsiniz. Daha iyi güvenlik için çevrimiçi oluşturucuyu kullanmayı düşünün .
$table_prefixdeğişken tüm WordPress tablolarının önekini saklar. Ne yazık ki, herkes bunun varsayılan değerini biliyor ve bu, WordPress veritabanını$table_prefix , kurulumu çalıştırırken özel bir değer ayarlayarak kolayca düzeltilebilecek bir güvenlik açığına açabilir .
Çalışan bir web sitesinde tablo önekini değiştirmek için veritabanında birkaç sorgu çalıştırmalı, ardından wp-config.php dosyasını manuel olarak düzenlemelisiniz. Veritabanına erişiminiz yoksa veya özel sorgular oluşturmak için gerekli bilgiye sahip değilseniz, o zaman Tablo Önekini Değiştir gibi veritabanı tablolarını ve alan adlarını yeniden adlandıracak bir eklenti yükleyebilir ve yapılandırma dosyasını hiçbir değişiklik yapmadan güncelleyebilirsiniz. risk.
Not : Tablo önekini bir eklentiyle değiştirseniz bile WordPress dosyalarını ve veritabanını yedeklemek iyi bir uygulamadır .
Şu ana kadar analiz temel konfigürasyonla sınırlıydı. Ancak özellikleri etkinleştirmek, özelleştirmek ve kurulumu güvence altına almak için tanımlayabileceğimiz birçok sabit elimizde mevcuttur.
Temel Yapılandırma Üzerinden: Dosya Sistemini Düzenleme
WordPress dosya sistemi kullanıcılar ve bilgisayar korsanları tarafından iyi bilinmektedir. Bu nedenle, belirli klasörleri isteğe bağlı konumlara taşıyarak ve wp-config dosyasındaki karşılık gelen URL’leri ve yolları ayarlayarak yerleşik dosya yapısını değiştirmeyi düşünebilirsiniz.
Öncelikle iki sabit tanımlayarak içerik klasörünü taşıyabiliriz. İlki tam dizin yolunu ayarlar:
define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/site/wp-content' );
İkincisi yeni dizin URL’sini ayarlar:
define( 'WP_CONTENT_URL', 'http://example.com/site/wp-content' );
Aşağıdaki sabitleri tanımlayarak yalnızca eklenti klasörünü taşıyabiliriz:
define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/wp-content/mydir/plugins' );
define( 'WP_PLUGIN_URL', 'http://example.com/wp-content/mydir/plugins' );
Aynı şekilde, yeni dizin yolunu ayarlayarak yüklenenler klasörünü taşıyabiliriz:
define( 'UPLOADS', 'wp-content/mydir/uploads' );
İşiniz bittiğinde klasörleri düzenleyin ve WordPress’i yeniden yükleyin.
/wp-content/themes klasörünü wp-config dosyasından taşımak mümkün değildir , ancak bir eklentiye veya temanın işlevler dosyasına yeni bir tema dizini kaydedebiliriz .
Geliştiricilere Yönelik Özellikler: Hata Ayıklama Modu ve Sorguları Kaydetme
Bir geliştiriciyseniz, WordPress’i tema ve eklenti hata ayıklamasında size yardımcı olacak hataları ve uyarıları göstermeye zorlayabilirsiniz. Hata ayıklama modunu etkinleştirmek içinWP_DEBUG aşağıda gösterildiği gibi değeri true olarak ayarlamanız yeterlidir :
define( 'WP_DEBUG', true );
WP_DEBUGvarsayılan olarak false olarak ayarlanmıştır. Hata ayıklama modunu devre dışı bırakmanız gerekiyorsa tanımı kaldırabilir veya sabitin değerini false olarak ayarlayabilirsiniz.
Yaşayan bir sitede çalışırken hata ayıklama modunu devre dışı bırakmalısınız. Hatalar ve uyarılar, bilgisayar korsanlarına değerli bilgiler sağlayabileceğinden siteyi görüntüleyenlere asla gösterilmemelidir. Peki ya yine de hata ayıklamanız gerekiyorsa? Bu gibi durumlarda, WordPress’i hataların ve uyarıların hafızasını /wp-content klasörüne yerleştirilen debug.log
dosyasında tutmaya zorlayabilirsiniz . Bu özelliği etkinleştirmek için aşağıdaki kodu kopyalayıp wp-config.php dosyanıza yapıştırın :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
Bu özelliğin çalışması için öncelikle hata ayıklama modunu etkinleştirmemiz gerekir. Ardından, WP_DEBUG_LOGtrue olarak ayarlayarak WordPress’i mesajları debug.log dosyasında depolamaya zorlarız, WP_DEBUG_DISPLAYfalse olarak tanımlayarak ise onları ekrandan gizleriz. Son olarak PHP değişkeninin değerini 0 olarak ayarladık, display_errorsböylece hata mesajları ekrana yazdırılmadı. wp-config hiçbir zaman önbellekten yüklenmez. Bu nedenle php.ini ayarlarını geçersiz kılmak için iyi bir yerdir .
Not: Bu, WordPress’in ekrana yazdırmayacağı mesajları kaydetmek için yararlanabileceğiniz harika bir özelliktir. Örnek olarak,
publish_posteylem tetiklendiğinde WordPress, verileri kaydeden bir komut dosyası yükler ve ardından kullanıcıyı yazı düzenleme sayfasına yönlendirir. Bu durumda mesajları kaydedebilirsiniz ancak ekrana yazdıramazsınız.
Başka bir hata ayıklama sabiti, yüklenecek komut dosyalarının ve stillerin sürümlerini belirler. SCRIPT_DEBUGSıkıştırılmamış sürümleri yüklemek istiyorsanız true olarak ayarlayın :
define( 'SCRIPT_DEBUG', true );
Temanız veya eklentiniz veritabanından alınan verileri gösteriyorsa sorgu ayrıntılarını daha sonra incelemek üzere saklamak isteyebilirsiniz. Sabit SAVEQUERIES, WordPress’i sorgu bilgilerini dizide depolamaya zorlar $wpdb->queries. Bu ayrıntılar, alt bilgi şablonuna aşağıdaki kod eklenerek yazdırılacaktır:
if ( current_user_can( 'administrator' ) ) {
global $wpdb;
echo '<pre>';
print_r( $wpdb->queries );
echo '</pre>';
}
İçerikle İlgili Ayarlar
Web siteniz büyüdüğünde, yayın revizyonlarının sayısını azaltmak isteyebilirsiniz. Varsayılan olarak WordPress, revizyonları her 60 saniyede bir otomatik olarak kaydeder. Bu değeri wp-config’de aşağıdaki gibi özel bir aralık ayarlayarak değiştirebiliriz:
define( 'AUTOSAVE_INTERVAL', 160 );
Elbette otomatik kaydetme aralığını da azaltabilirsiniz.
Düzenlemelerimizi her kaydettiğimizde WordPress, gönderiler tablosuna bir satır ekler, böylece gönderilerin ve sayfaların önceki revizyonlarını geri yükleyebiliriz. Bu, sitemiz büyüdüğünde soruna dönüşebilecek kullanışlı bir işlevselliktir. Neyse ki, saklanacak maksimum revizyon sonrası sayısını azaltabilir veya işlevselliği tamamen devre dışı bırakabiliriz.
Gönderim düzeltmelerini devre dışı bırakmak istiyorsanız aşağıdaki sabiti tanımlayın:
define( 'WP_POST_REVISIONS', false );
Maksimum düzeltme sayısını sınırlamak istiyorsanız bunun yerine aşağıdaki satırı ekleyin:
define( 'WP_POST_REVISIONS', 10 );
Varsayılan olarak WordPress, çöpe atılan gönderileri, sayfaları, ekleri ve yorumları 30 gün boyunca saklar, ardından bunları kalıcı olarak siler. Bu değeri aşağıdaki sabitle değiştirebiliriz:
define( 'EMPTY_TRASH_DAYS', 10 );
Çöp kutusunu bile devre dışı bırakıp değerini 0 olarak ayarlayabiliriz, ancak WordPress’in artık içerikleri geri yüklemenize izin vermeyeceğini göz önünde bulundurun.
İzin Verilen Bellek Boyutu
Bazen aşağıdakine benzer bir mesaj alabilirsiniz:
Önemli hata: İzin verilen xxx baytlık bellek boyutu tükendi…
Maksimum bellek boyutu sunucu yapılandırmasına bağlıdır. Php.ini dosyasına erişiminiz yoksa, wp-config dosyasında sabiti ayarlayarak yalnızca WordPress için bellek sınırını artırabilirsiniz . WP_MEMORY_LIMITVarsayılan olarak WordPress, tek siteler için PHP’ye 40Mb ve çok siteli kurulumlar için 64MB ayırmaya çalışır . Elbette, PHP’ye ayrılan bellek 40Mb’den (veya 64Mb) büyükse, WordPress maksimum değeri benimseyecektir.
Bununla birlikte, aşağıdaki satırla özel bir değer ayarlayabilirsiniz:
define( 'WP_MEMORY_LIMIT', '128M' );
Gerekirse aşağıdaki ifadeyle maksimum bellek sınırını da ayarlayabilirsiniz:
define( 'WP_MAX_MEMORY_LIMIT', '256M' );
Önerilen okuma: WordPress’te PHP Bellek Sınırı Nasıl Geliştirilir ?
Otomatik güncellemeler
Sürüm 3.7’den itibaren WordPress, güvenlik sürümleri için otomatik güncellemeleri desteklemektedir. Bu, site yöneticilerinin web sitelerini her zaman güvende tutmalarına olanak tanıyan önemli bir özelliktir .
Aşağıdaki sabiti tanımlayarak tüm otomatik güncellemeleri devre dışı bırakabilirsiniz:
define( 'AUTOMATIC_UPDATER_DISABLED', true );
Belki güvenlik güncellemelerini devre dışı bırakmak iyi bir fikir değildir, ancak bu sizin seçiminizdir. Otomatik güncellemeler varsayılan olarak büyük sürümlerde çalışmaz ancak aşağıdaki şekilde
tanımlayarak temel güncellemeleri etkinleştirebilirsiniz :WP_AUTO_UPDATE_CORE
# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );
# Enables all core updates, including minor and major:
define( 'WP_AUTO_UPDATE_CORE', true );
Varsayılan değer minor:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
Ek bir sabit, otomatik güncellemeleri (ve herhangi bir dosyadaki herhangi bir güncellemeyi veya değişikliği) devre dışı bırakır. True olarak ayarlarsanız DISALLOW_FILE_MODS, tema ve eklenti kurulumları ve güncellemeleri dahil tüm dosya düzenlemeleri devre dışı bırakılır. Bu sebeple kullanılması tavsiye edilmez.
Güvenlik ayarları
Site güvenliğini arttırmak için wp-config dosyasını kullanabiliriz. Yukarıda incelediğimiz dosya yapısındaki değişikliklere ek olarak, gereksiz güvenlik açıklarını açabilecek bazı özellikleri de kilitleyebiliriz. Öncelikle admin panelinde sunulan dosya düzenleyiciyi devre dışı bırakabiliriz. Aşağıdaki sabit Görünüm Düzenleyici ekranını gizleyecektir:
define( 'DISALLOW_FILE_EDIT', true );
Not: Bu sabit true olarak tanımlanırsa bazı eklentilerin düzgün çalışamayacağını unutmayın.
Bir güvenlik özelliği SSL üzerinden Yönetimdir. Bir SSL sertifikası satın aldıysanız ve bu sertifika doğru şekilde yapılandırılmışsa, WordPress’i herhangi bir oturum açma ve yönetici oturumunda SSL üzerinden veri aktarmaya zorlayabilirsiniz. Aşağıdaki sabiti kullanın:
define( 'FORCE_SSL_ADMIN', true );
SSL üzerinden Yönetim hakkında daha fazla bilgiye ihtiyacınız varsa Kodeksi kontrol edin .
Diğer iki sabit, harici isteklerin engellenmesine ve kabul edilen ana bilgisayarların listelenmesine olanak tanır.
define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'example.com,*.anotherexample.com' );
Bu örnekte, önce harici ana bilgisayarlardan gelen tüm erişimleri devre dışı bıraktık, ardından izin verilen ana bilgisayarları virgüllerle ayırarak listeledik (joker karakterlere izin verilir).
Diğer Gelişmiş Ayarlar
WP_CACHEtrue olarak ayarlanmış wp-content/advanced-cache.php betiğini içerir. Bu sabit yalnızca kalıcı bir önbellek eklentisi yüklediğinizde etkili olur.
CUSTOM_USER_TABLEve CUSTOM_USER_META_TABLEvarsayılan wp_users ve wp_usermeta tabloları dışındaki özel kullanıcı tablolarını ayarlamak için kullanılır. Bu sabitler, site kullanıcılarının tek bir hesapla birden fazla web sitesine erişmesine olanak tanıyan kullanışlı bir özelliği etkinleştirir. Bu özelliğin çalışması için tüm kurulumların aynı veritabanını paylaşması gerekir.
Sürüm 2.9’dan başlayarak, WordPress Otomatik Veritabanı Optimizasyonu’nu desteklemektedir. Bu özellik sayesinde, WP_ALLOW_REPAIRtrue olarak ayarlandığında WordPress, bozuk bir veritabanını otomatik olarak onaracaktır.
WordPress, bir görseli her düzenlediğinizde yeni bir görsel seti oluşturur. Orijinal görüntüyü geri yüklerseniz oluşturulan tüm kümeler sunucuda kalacaktır. Doğru olarak ayarlayarak bu davranışın üzerine yazabilirsiniz IMAGE_EDIT_OVERWRITE; böylece orijinal görüntüyü geri yüklediğinizde tüm düzenlemeler sunucudan silinir.
wp-config.php’yi kilitleme
Artık wp-config.php’nin neden en önemli WordPress dosyalarından biri olduğunu biliyoruz. Peki neden bunu bilgisayar korsanlarına saklamıyoruz? Her şeyden önce, wp-config’i WordPress kök klasörünün bir seviye üstüne ( sadece bir seviye ) taşıyabiliriz . Ancak bu teknik biraz tartışmalı olduğundan dosyayı korumak için başka çözümler benimsemenizi öneririm. Web siteniz Apache Web Sunucusu üzerinde çalışıyorsa , .htaccess dosyasına aşağıdaki yönergeleri ekleyebilirsiniz :
<files wp-config.php>
order allow,deny
deny from all
</files>
Web sitesi Nginx üzerinde çalışıyorsa , aşağıdaki yönergeyi yapılandırma dosyasına ekleyebilirsiniz:
location ~* wp-config.php { deny all; }
Not: Bu talimatlar yalnızca kurulum tamamlandıktan sonra eklenmelidir.
Web siteniz birden fazla geçişten geçtiyse veya onu başka birinden satın aldıysanız, yeni bir WordPress güvenlik anahtarı seti oluşturmanız önerilir. Bu anahtarlar, kullanıcının çerezlerinde saklanan bilgilerin şifrelenmesini geliştiren bir dizi rastgele değişkendir. WordPress 2.7’den bu yana 4 farklı anahtar bulunmaktadır: AUTH_KEY , SECURE_AUTH_KEY , LOGGED_IN_KEY ve NONCE_KEY.
Varsayılan olarak sizin için rastgele oluşturulurlar. Ancak WordPress’in aslında yeni rastgele anahtarlar oluşturmak için kullanabileceğiniz ücretsiz bir aracı vardır . Daha sonra wp-config.php dosyanızda saklanan mevcut anahtarlarınızı güncelleyebilirsiniz.
WordPress güvenlik anahtarları hakkında daha fazlasını okuyun .
Son olarak, wp-config.php dosyanızda izinlerinizin sağlamlaştırıldığını tekrar kontrol etmeli ve emin olmalısınız. Tipik olarak bir WordPress sitesinin kök dizinindeki dosyalar 644 olarak ayarlanacaktır; bu, dosyaların dosyanın sahibi tarafından okunabilir ve yazılabilir olduğu, o dosyanın sahibi gruptaki kullanıcılar tarafından okunabileceği ve diğer herkes tarafından okunabileceği anlamına gelir. WordPress belgelerine göre , sunucudaki diğer kullanıcıların dosyayı okumasını önlemek için wp-config.php dosyasındaki izinlerin 440 veya 400 olarak ayarlanması gerekir. Bunu FTP istemcinizle kolayca değiştirebilirsiniz .
Özet
Bu yazıda wp-config dosyasına tanımlayabileceğimiz birçok WordPress sabitini listeledim. Bu sabitlerden bazıları yaygın olarak kullanılmaktadır ve işlevlerinin anlaşılması kolaydır. Diğer sabitler, WordPress ve site yönetimi konusunda derin bilgi gerektiren gelişmiş özellikleri etkinleştirir.
İlginizi Çekebilir
