Geliştiricinin wp-config.php Dosyası için Gelişmiş Kılavuzu

wp-config gerçekten ne kadar iyi tanıyorsunuz? PHP'nin bu birkaç satırında şaşırtıcı miktarda güç var! Bu makale, belki de bilmediğiniz, ancak gerçekten bilmeniz gereken bazı wp-config bitlerinin bir turudur.

wp-config.php dosyası hakkında bilinmesi gereken her şeyi biliyor musunuz? Bununla ilgili WordPress dokümantasyon sayfasının tamamını okudunuz mu? Sonuna kadar mı?

wp-config temellerini zaten biliyorsanız, resmi WordPress belgelerini okumak muhtemelen uygun bir erteleme festivali olacaktır.

Gerçek geliştiricinin, konuya göre güzel bir şekilde gruplandırılmasını ve yalnızca “birkaç PHP sabiti üzerinde tamamen gereksiz coşku” olarak adlandırılabilecek bir şeyle sunulmasını istiyorsanız, o zaman devam edin: wp-config.php yeniden havalı hale getirmek üzereyim.

İçindekiler

1. Bunu Kim Okumalı?
2. Neden Bunu Okumalısınız?
3. Temeller
4. wp-config Sabitlerini Görüntüleme
5. wp-config.php Yükleme İşlemini Yıkmak
   1. wp-config Yukarı Taşınabilir
   2. wp-config.php Dosyası Yok ise Kurulum Ekranı Yüklenir
   3. wp-config.php Çok Erken Yükleniyor
   4. wp-config.php ile Karıştırmayın!
6. wp-config.php Dosyanızı Kontrol Etme/Astarlama
7. wp-config.php ile WordPress Güvenliğini Sağlama
   1. wp-config.php Web Sitesi Ziyaretçilerinden Koruma
   2. Dönen Tuşlar/Tuzlar
   3. Eşyaları Taşımak ve Gizlemek
   4. Dosya Düzenleyicilerini Devre Dışı Bırakma
   5. Otomatik Güncellemeleri Devre Dışı Bırakma
   6. Harici HTTP İsteklerini Önleme
8. Eşyaları Taşımak
   1. User ve Usermeta Tablolarını Taşıma
   2. İçeriği, Yüklemeleri ve Eklenti Dizinlerini Taşı
9. İçerikle İlgili Ayarlar
   1. Site ve Gösterge Tablosu URL'lerini Değiştirin
   2. Gönderi Ayarları
   3. Revizyon Sonrası
   4. Otomatik Kaydetme Aralığını Değiştirme
10. Toplama

Bunu Kim Okumalı?

Bu makale, wp-config.php dosyasını nasıl düzenleyeceğini zaten bilen ve dosyaya koyabileceğiniz bazı yapılandırma ayarlarının farkında olan geliştiricilere ve ileri düzey kullanıcılara yöneliktir.

Size dosyayı FTP veya cPanel kullanarak nasıl düzenleyeceğinizi veya düzenlemek için neden MS Word kullanmamanız gerektiğini söylemeyeceğim.

Size veritabanınızı nasıl yapılandıracağınızı veya 2013'te kullandığınız eski ayarların üzerinden nasıl geçeceğinizi söylemeyeceğim ama gerçekten daha fazlasına ihtiyacınız yok. Ve çoğu ev sahibi zaten sizin için temel bilgilerle ilgilenecektir.

wp-config.php konusunda yeniyseniz, size temel bilgileri verecek kılavuz sıkıntısı yoktur veya her zaman resmi belgeleri inceleyebilirsiniz.

Neden Bunu Okumalısınız?

Evet, evet, seni duyuyorum. Bu makaleye koyabileceklerinizin temel ayrıntıları başka bir yerde ele alındıysa ve ev sahibiniz temel bilgilerin çoğuyla zaten ilgileniyorsa, neden bunu okumalısınız? Ve gerçekten, neden zamanımı onu yazmaya harcıyorum?

Peki, wp-config.php düzenlemekten memnunsanız ve ne yaptığının temellerini biliyorsanız, muhtemelen en azından orta düzey bir WordPress geliştiricisisiniz.

Büyük siteleri, muhtemelen müşteriler için barındırmaktan muhtemelen en azından kısmen siz sorumlusunuz. Yani acil bir durumda bu dosyayı nasıl kullanabileceğinizi bilmeniz gerekiyor. Ve bu dosya hakkında yeterince bilgi sahibi olmak için, eğer onu düzenlerseniz, yanlış bir şey yapmazsınız.

Ek olarak, WordPress'in belirli özelliklerini, sunucunuzun otomatik olarak yapılandırmanıza izin vereceğinin ötesinde kilitlemek isteyeceksiniz.

Muhtemelen wp-config.php ile yapabileceğinizi bile bilmediğiniz şeyler vardır! Bazı "Hah!" olması gereken anlar.

Bu makale, WordPress'in bazı dahili özelliklerini yapılandırmak için yararlı bir referans noktasıdır. Bu yüzden okumaya devam edin, yer imlerine ekleyin ve arkadaşlarınızla ve iş arkadaşlarınızla paylaşın.

Temeller

Bunun yeni başlayanlar için bir makale olmadığını söyledim ama aynı başlangıç ​​noktasında olduğumuzdan emin olmak için temel gerçekleri belirlememiz gerekiyor.

wp-config.php dosyası, WordPress kurulumunuzun kökünde bulunur (başka yerlerde de olabilir, ancak buna geleceğiz), WordPress'in başlatılmasının bir parçası olarak yüklenir ve WordPress çekirdeğini yapılandırmanıza izin verir.

WordPress'in çalışması için gereklidir. Şunları belirtmenize izin veren bir dizi sabiti saklar:

• WordPress'in kullandığı veritabanı bağlantısı ve tablo öneki.
• Tuzlar ve kimlik doğrulama anahtarları gibi güvenlik bilgileri.
• WP_CACHE ve WP_DEBUG gibi WordPress çekirdeğinin diğer özellikleri için ayarlar.
• Dosyaya kendi seçeneklerini ekleyebilecek eklentiler için ayarlar.
• Kendi yapılandırma seçenekleriniz.

En önemlisi, wp-config.php ortama özel bir dosyadır. İçeriği farklı siteler için farklı olabilir (ve olmalıdır!). Aynı sitenin yerel, hazırlama ve canlı kopyaları bile dosyada farklı değerlere sahip olacaktır.

WordPress, çalışması için gereken minimum ayrıntıları içeren bir wp-config-sample.php dosyasıyla birlikte gelir. Bunu kurulumun bir parçası olarak kendi wp-config.php kopyalayabilirsiniz, ancak bu günlerde genellikle sizin için yapılır.

Son olarak, mevcut bir siteden bir wp-config.php dosyasını açtığınızda, varsayılan dosya izinleri ve yükseltmeleri çalıştırmak için FTP kimlik bilgileri gibi eski özellikler için bazı eski PHP sabitlerini görmenizin mümkün olduğunu unutmayın. Bunları kullanmanız gerekmeyeceği için burada bunlara değinmeyeceğiz.

wp-config Sabitlerini Görüntüleme

Uzak bir sunucuya SSH göndermeden ve dosyayı açmadan WordPress sabitlerinin değerlerini hızlı bir şekilde kontrol etmenin birkaç yolu vardır.

WordPress çekirdeğinin Site Sağlığı özelliği, Araçlar -> Site sağlığı -> Bilgi -> WordPress sabitleri'ne giderek bazı temel değerleri görüntülemenizi sağlar. Veritabanı sabitleri de aynı sayfanın “Veritabanı” bölümünde görülebilir.

Query Monitor eklentisi, yaygın olarak kullanılan bazı wp-config sabitlerini görebileceğiniz bir “Ortam” paneline sahiptir.

WordPress komut satırı arayüzü olan WP-CLI, wp-config.php içindeki sabitleri almak ve ayarlamak için kullanılabilecek bir wp config komutuna sahiptir. Bu normalde önce SSH'ye girmenizi gerektirir, ancak WP-CLI yapılandırmanızda takma adlar ayarlarsanız, uzak wp-config dosyalarındaki sabitleri görüntülemek ve değiştirmek için hızlı bir kısayol oluşturabilirsiniz.

wp-config.php Yükleme İşlemini Yıkmak

wp-config.php dosyasının ne zaman yüklendiğini bilmek yararlıdır, çünkü bu, onunla yapabileceğiniz ve yapamayacağınız bazı şeyleri belirler. Yükleme sürecini izlemek için iyi bir alıştırma:

• WordPress, index.php dosyasıyla yüklenmeye başlar. Bu, wp-blog-header.php dosyasını gerektirir.

• wp-blog-header.php yaptığı hemen hemen ilk şey wp-load.php yüklemektir.

• Ardından, wp-load.php , ABSPATH sabitini (temel WordPress çekirdek dizini) ayarlar ve wp- wp-config.php dosyasını yüklemeden önce error_reporting() öğesini başlatır.

Bu yükleme işlemi ve özellikle wp-load.php içindeki kod bize birkaç ilginç şey öğretebilir. İşte o kod:

 /* * If wp-config.php exists in the WordPress root, or if it exists in the root and wp-settings.php * doesn't, load wp-config.php. The secondary check for wp-settings.php has the added benefit * of avoiding cases where the current directory is a nested installation, eg / is WordPress(a) * and /blog/ is WordPress(b). * * If neither set of conditions is true, initiate loading the setup process. */ if ( file_exists( ABSPATH . 'wp-config.php' ) ) { /** The config file resides in ABSPATH */ require_once ABSPATH . 'wp-config.php'; } elseif ( @file_exists( dirname( ABSPATH ) . '/wp-config.php' ) && ! @file_exists( dirname( ABSPATH ) . '/wp-settings.php' ) ) { /** The config file resides one level above ABSPATH but is not part of another installation */ require_once dirname( ABSPATH ) . '/wp-config.php'; } else { // A config file doesn't exist. // [Code here to load the setup screen for in-browser configuration] }

Burada ne görüyoruz?

wp-config.php Yukarı Taşınabilir

İlk olarak, yorum bize wp-config.php “WordPress köküne” koyabileceğimizi söylüyor. Söylemekte başarısız olduğu şey, "kök"ün aslında wp-load.php ABSPATH üzerinde bir dizin olabileceğidir.

Bu ek kontrolü dirname( ABSPATH ) . '/wp-config.php' elseif aradığı elseif'te görebiliriz. dirname( ABSPATH ) . '/wp-config.php' . elseif ek koşul yorumda açıklanmıştır.

wp-config.php Dosyası Yok ise Kurulum Ekranı Yüklenir

İkinci olarak, bir yapılandırma dosyası yoksa kurulum ekranını yükleyeceğini görebiliriz.

Bu ekranı daha önce hiç görmemiş olmanız tamamen mümkün. Veritabanı kimlik bilgileri gibi ilk yapılandırma bilgilerini web tabanlı bir kullanıcı arabiriminde girmenizi sağlar:

Bu, WordPress'in bilmeye değer bir özelliğidir. WordPress çekirdek dosyalarını herkese açık bir web sunucusuna koyarsanız, ancak bir wp-config.php dosyası oluşturmazsanız, başka biri (veya daha büyük olasılıkla bir bot) gelip WordPress'i istediği şekilde kurabilir. ve muhtemelen hostinginizden ödün verebilirsiniz.

wp-config.php Çok Erken Yükleniyor

Unutulmaması gereken üçüncü şey, wp-config.php WordPress'in başlangıç ​​sırasında çok erken yüklenmesidir. Bunun anlamı şudur ki:

1. wp-config.php içinde yapamayacağımız çok şey var. Örneğin, bunu yapmak için işlevler ve veri yapıları henüz yüklenmediği için buraya kancalar (eylemler veya filtreler) ekleyemiyoruz. Ve WordPress'in hiçbir dahili işlevine, nesnesine ve API'sine erişimimiz yok.

2. Bundan sonra ne olacağı üzerinde çok fazla kontrolümüz var. Dosya çok erken yüklendiğinden, WordPress üzerinde çok fazla etkisi vardır. Bu hem iyi hemde kötü. WordPress'i kolayca tamamen yok edebiliriz. Ancak wp-config.php içinde tanımlanan her şeye WordPress'in hemen hemen her yerinden de erişebiliriz.

wp-config.php ile Karıştırmayın!

Bu süreçten öğrendiğimiz son şey, bu büyük gücün beraberinde büyük sorumluluklar getirdiğidir.

wp-config.php dosyasının altında şu satırlar bulunur:

 /* Add any custom values between this line and the "stop editing" line. */ /* That's all, stop editing! Happy publishing. */ /** Absolute path to the WordPress directory. */ if ( ! defined( 'ABSPATH' ) ) { define( 'ABSPATH', __DIR__ . '/' ); } /** Sets up WordPress vars and included files. */ require_once ABSPATH . 'wp-settings.php';

Burada bazı talimatlar var, ancak “düzenlemeyi durdur” satırı önemlidir. Bu satırdan sonra WordPress'in başlatma dizisinin devamı gelir. Yanlış yere yeni kod eklemek, muhtemelen yalnızca yeni kodun hiçbir etkisi olmamasına neden olur. Ancak güvende olmak için bu talimatları izlemenizi öneririm. İyi bir sebep için oradalar.

wp-config.php Dosyanızı Kontrol Etme/Astarlama

Üretimde çalışıyorsanız, wp-config.php dosyasına gerçekten herhangi bir hata koymak istemezsiniz. Buradaki hatalar web sitenizi bozabilir ve bu gerçekleştiğinde görüntülenen yararlı bir hata mesajı alamayabilirsiniz.

wp-config.php dosyanızda önemli PHP sözdizimi hataları olup olmadığını kontrol etmek için php komut satırında -l (“lint”) seçeneğiyle çalıştırabilirsiniz.

$ php -l wp-config.php

Ayrıştırma hatası: sözdizimi hatası, 9. satırda wp-config.php'de beklenmeyen belirteç "require_once"

wp-config.php ayrıştırma hataları

Hatta bir kabuk betiği bile yazabilirsiniz…

1. wp-config.php dosyasını geçici bir dosyaya kopyalayın,
2. Geçici dosyayı düzenleyin,
3. Geçici dosyayı Lint ve
4. Yalnızca sözdizimi hatası yoksa geri kopyalayın.

Komut satırından memnunsanız, değerleri güvenli bir şekilde ayarlamak için elle yapmak yerine wp config set <name> <value> gibi WP-CLI komutlarını kullanmak daha güvenlidir.

Yapılandırma değerlerinizi WP-CLI ile de listeleyebilirsiniz (bu, bazı girişlerin kaldırıldığı bir örnektir - fikri anladınız!):

$ wp yapılandırma listesi
-------------------------------------------------------------------- --------------------+----------+
| isim | değer | tip |
-------------------------------------------------------------------- --------------------+----------+
| root_dir | /Kullanıcılar/demirciler/siteler/snpp | değişken |
| webroot_dir | /Kullanıcılar/demirciler/siteler/snpp/genel | değişken |
| tablo_ön eki | wp_ | değişken |
| WP_HOME | https://snpp.test | sabit |
| WP_SITEURL | https://snpp.test/ | sabit |
| DB_NAME | snpp | sabit |
| DB_USER | kök | sabit |
| DB_PASSWORD | Montgomery | sabit |
| DB_HOST | 127.0.0.1 | sabit |
| DB_CHARSET | utf8mb4 | sabit |
| DB_COLLATE | | sabit |
| DB_PREFIX | wp_ | sabit |
| WP_DEBUG | 1 | sabit |
| WP_DEBUG_LOG | 1 | sabit |
| WP_DEBUG_DISPLAY | | sabit |
| WP_ENVIRONMENT_TYPE | geliştirme | sabit |
| DISABLE_WP_CRON | | sabit |
| DISALLOW_FILE_EDIT | 1 | sabit |
-------------------------------------------------------------------- --------------------+----------+

Bu iki teknik, sizi gerçekten biraz zahmetten kurtarabilir ve böyle kritik bir dosyada yanlışlıkla noktalı virgülü yanlış yere koymaktan korkmanıza engel olabilir.

wp-config.php ile WordPress Güvenliğini Sağlama

Güvenlik, WordPress'te sürekli olarak sıcak bir konudur. wp-config dosyasında değiştirebileceğimiz bazı ayarlar, güvenlik araç kutumuza daha fazla araç yerleştirir.

wp-config dosyasının bu kısımları kesinlikle iyi bir WordPress güvenliği elde etmek için kullanmanız gereken şeyler değildir. Aşağıdaki bölümdeki bilgilere ek olarak web sitesi güvenliğini tam olarak anladığınızdan emin olun.

wp-config.php Web Sitesi Ziyaretçilerinden Koruma

wp-config dosyanız varsayılan olarak web sitenizin kök dizininde bulunur ve yalnızca veritabanı oturum açma bilgileriniz ve parola tuzlarınız gibi kritik bilgileri içerir. Bu bilgilerin herkese açık olmasını istemiyorsunuz, bu nedenle wp-config dosyanızın web sitesi ziyaretçilerinden korunduğundan emin olmalısınız.

Hosting şirketiniz bunu genellikle sizin için yapacaktır. Alan adınızın hemen /wp-config.php ekleyerek tarayıcınızdan dosyaya erişmeyi deneyerek kontrol edebilirsiniz. Dosyayı taşıdıysanız bu URL farklı olabilir.

wp-config dosyasını web sitenizin kök dizininin üstündeki dizine yerleştirdiyseniz, onu görememelisiniz. Diğer birçok durumda, dosyayı yine de ziyaret etmeye çalıştığınızda yalnızca bir PHP hata mesajı alırsınız, bu nedenle genellikle burada yapacak bir şey yoktur. Ancak, düzgün bir şekilde güvenceye almak istiyorsanız, web sunucusu (Apache veya nginx) yapılandırmanızı buna erişimi engelleyecek şekilde değiştirerek yapabilirsiniz.

Son olarak, web sitenizin dosyasını Git'te saklıyorsanız, wp-config dosyasını Git deponuzda saklamamanız önemlidir. Bunu yapmak sitenizle ilgili kritik bilgileri sızdırabilir, ancak ek olarak muhtemelen her ortamda bu dosyanın farklı bir sürümünü istersiniz. Bu nedenle, onu .gitignore eklemek ve her ortamdaki dosyaları manuel olarak yönetmek daha iyidir.

Dönen Tuşlar/Tuzlar

Anahtarlar/tuzlar nedir?

Anahtarlar ve tuzlar bölümü, wp-config daha gizemli kısımlarından biridir. Bu tuhaf görünümlü sabitler seti, tanımlama bilgileri ve nonce'lar gibi şeylerin şifrelenmesine yardımcı olur. Ayrıntılara girmeden - WP Engine'de olduğu gibi - tuzları ve anahtarları bilmiyorsanız şifrenin çözülmesini zorlaştıran ekstra bir rastgelelik katmanı eklerler.

Anahtarları/tuzları neden “döndürelim”?

Öncelikle, "döndür" sadece "değişim" için süslü bir kelimedir. Neden "döndürme" kullandığımızı bilmiyorum. Hiç aynı anahtar setine geri dönmedik!

Anahtarların ve tuzların hala gizli olduğunu garanti edemediğiniz için site saldırıya uğradıysa muhtemelen anahtarlarınızı ve tuzlarınızı değiştirmelisiniz. Ancak, şifrelerde olduğu gibi, kimsenin ne olduğunu bilmediğinden emin olmak için onları yine de düzenli olarak döndürmek isteyebilirsiniz.

Dönen tuşlar/tuzlarla ilgili sorun

Anahtarları ve tuzları değiştirmek acısız değildir. Çerez seti olan herkes onu kaybeder. Böylece giriş yapan herkes önyüklenecek ve WooCommerce sepeti olan herkes boşaltılacaktır.

Tuşlar/tuzlar nasıl döndürülür

Yani, wp-config dosyasını düzenleyebilir ve eskilerin üzerine yeni rastgele karakterler yazabilirsiniz. Ancak bu sıkıcı olurdu ve insanlar rastgelelik konusunda pek iyi değiller.

Bu yüzden size wp-config dosyanızda yeni anahtarlar/tuzları ayarlamanın birkaç yolunu anlatayım.

1. Bir jeneratörden manuel olarak anahtar ekleyin: İhtiyacınız olan kodu almak için wordpress.org oluşturucuyu kullanabilirsiniz. Eski değerlerin yerine wp-config dosyasına kopyalayıp yapıştırın.
2. Bir eklenti kullanın: Sucuri Security, iThemes Security ve Malcare gibi birçok güvenlik eklentisi bu özelliğe sahiptir. Ve Salt Shaker, bu süreci sizin için bir programa göre otomatikleştirecek özel bir eklentidir.
3. WP-CLI'yi kullanın. WP-CLI'nin ne kadar harika olduğunu söylemiş miydik? Yaptık? TAMAM. Eh, yine söylüyoruz! Ve bu işi saniyeler içinde yapmak için wp config shuffle-salts komutunu kullanabilirsiniz.

Eşyaları Taşımak ve Gizlemek

Güvenlik görevlileri size “belirsizliğe bağlı güvenlik” in güvenlik olmadığını söyleyecektir, ancak bazı insanlar bilgisayar korsanlarına bazı ek engeller koymak için WordPress öğelerini gizlemeyi hala seviyor.

wp-config dosyası size bunu yapmak için bir dizi seçenek sunar ve bunları sonraki bölümlerde bir şeyleri taşıma ve dosya düzenlemeyi kapatma hakkında ele alacağız.

Dosya Düzenleyicilerini Devre Dışı Bırakma

WordPress, yönetici panosunun içinden temalardaki ve eklentilerdeki dosyaları düzenlemenizi sağlayan kullanışlı bir özelliğe sahiptir. wp-config.php dosyasını düzenlemek, bu dosya düzenleyicilerini kapatmanıza izin verir! Bazı insanlar gönül rahatlığı için onları devre dışı bırakmayı sever.

Artık, birinin sitenize yönetici erişimi varsa (bu düzenleyicileri kullanmak için gerekli) bir eklenti yükleyip yine de istediklerini yapabileceklerine dair bir güvenlik argümanı olduğunu biliyorum. Bu düzenleyicilerin etkinleştirilmesi, bilgisayar korsanlarına zaten sahip olduklarından daha fazla güç sağlamaz.

Ancak, bunlar kapatılarak güvenlik gerçekten iyileştirilemese de, bunu yapmanın asıl nedeni, gerçekten yönetici olarak yetkilendirilmiş kişilerin bunları kullanmasını engellemektir. Bir ajanssanız, muhtemelen müşterilerinizin tüm tema dosyalarını düzenleyebileceklerini keşfetmesini istemezsiniz, değil mi?

Birçok ana bilgisayar bu özelliği varsayılan olarak devre dışı bırakır. Ancak onları ortadan kaldırmak istiyorsanız, eklemek kadar basit:

 define( 'DISALLOW_FILE_EDIT', true );

Veya dosya sisteminizi gerçekten kilitlemek istiyorsanız, bir sonraki bölümde ele DISALLOW_FILE_MODS var.

Otomatik Güncellemeleri Devre Dışı Bırakma

Onları sevseniz de sevmeseniz de, WordPress'in otomatik güncellemelerinin WordPress ekosistemi üzerinde net olumlu bir etkisi oldu ve görmezden gelinmesi zor. Ancak herkes yazılımlarının kendi kendine ilgilenmesini istemez!

Böylece wp-config , ayarlayabileceğiniz basit bir açıklayıcı sabitler seti ile otomatik güncelleme süreci üzerinde kontrol sağlar:

 # Disable all core updates: define( 'WP_AUTO_UPDATE_CORE', false ); # Enable all core updates, including minor and major: define( 'WP_AUTO_UPDATE_CORE', true ); # Enable core updates for minor releases (default): define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Daha aşırı bir şey istiyorsanız, DISALLOW_FILE_MODS yapabilirsiniz:

 define( 'DISALLOW_FILE_MODS', true );

Ancak bu, WordPress'in çekirdek, temalar, eklentiler veya çevirilerle ilgili diske herhangi bir şey yazmasını engeller ve küçük güncellemeler hakkında e-posta bildirimlerini devre dışı bırakır. Çekirdek bir katılımcı tarafından " tam olarak ne yaptığınızı bilmiyorsanız kullanmak çılgınca aptal" olarak tanımlandı.

AUTOMATIC_UPDATER_DISABLED biraz daha az aşırıdır. Bu, eklentileri ve temaları yüklemenize izin verir, ancak bunları veya çekirdek yazılımı güncellemez. Yine de çeviri güncellemelerini devre dışı bırakır.

 define( 'AUTOMATIC_UPDATER_DISABLED', true );

Tüm bunlarla ilgili ayrıntılı bir kılavuz wordpress.org'da, daha ayrıntılı kontrol için filtreler kullanmak gibi bazı diğer seçenekler de dahil.

Son olarak, siteniz sürüm kontrollüyse, WordPress'in zaten sizin için güncellemeleri devre dışı bırakmış olabileceğini unutmayın. Örneğin, sitenin kökünde bir .git dizininin (veya çeşitli farklı yerlerdeki çeşitli dosyaların) bulunması, wp-config dosyasına herhangi bir şey eklemenize gerek kalmadan otomatik güncellemeleri devre dışı bırakacaktır.

HTTPS'yi Yapılandırma

HTTPS'yi yapılandırmak genellikle zorlayıcıydı. LetsEncrypt ve Cloudflare gibi yerlerden ücretsiz, güvenilir güvenlik sertifikalarının gelmesiyle, birçok ana bilgisayar bunu birkaç tıklamayla sizin için ayarlayacaktır. Bu ayar muhtemelen eski olarak kabul edilmelidir, ancak belki de hala bir şey için buna ihtiyacınız var.

FORCE_SSL_ADMIN sabiti, WordPress'e giriş sayfaları ve WordPress Dashboard için her zaman SSL kullanmasını söyler. Bu, güvenli kimlik bilgilerinin ve çerezlerin şifrelenmemiş olarak gönderilememesini sağlar.

Ama dediğim gibi, iyi bir barındırma şirketi sitenizde HTTPS kurmayı zaten basitleştirecek, o yüzden yapın.

Harici HTTP İsteklerini Önleme

Son olarak güvenlikte, harici HTTP isteklerini engelleyebilirsiniz. Bu, WordPress'in API çağrıları yapmak veya güncellemeleri indirmek gibi şeyler yapmak için internetteki diğer yerlerle iletişim kuramayacağı anlamına gelir.

WordPress'in harici hizmetlerle HTTP üzerinden iletişim kurmasına izin vermek genellikle iyi bir fikirdir çünkü güncellemeler almanıza, eklentiler ve temalar yüklemenize izin verir ve HTTP isteklerini kapatırsanız birçok eklenti bozulur.

Ancak WordPress çekirdeği ve birçok eklenti ve tema, "telemetri" veya "kullanım verilerini" merkezi sunuculara geri gönderir. Bu iyi olabilir – eklenti ve tema geliştiricilerinin yazılımlarını kimin ve nasıl kullandığını bilmelerine yardımcı olur. Ancak, üzerinde özellikle hassas veriler bulunan bir siteniz varsa, bunu devre dışı bırakmak isteyebilirsiniz. Ve bunu şununla yapabilirsiniz:

 define( 'WP_HTTP_BLOCK_EXTERNAL', true );

İletişim kurulabilecek bir izin verilenler listesine sahip olmak istiyorsanız, bunu da yapabilirsiniz:

 define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com' );

Erişilebilir ana bilgisayar listesinin virgülle ayrılmış bir liste olduğunu ve joker karakter alt etki alanlarına izin verildiğini unutmayın. Ayrıca Log HTTP İstekleri eklentisini kullanarak hangi ana bilgisayarlarla iletişim kurulduğunu izleyebilirsiniz.

Eşyaları Taşımak

Her WordPress kurulumu aynı değildir. Bazı ana bilgisayarlar veya çerçeveler, güvenlik nedenleriyle veya siteye özgü kod ve varlıkları WordPress çekirdeğinden ayrı tutmak için dizinleri taşımak ister. WordPress'i yönetmek için Git ve Composer'ı kullanma konusundaki makalem, bu yaklaşımın bazı avantajlarını ele alıyor.

Peki WordPress size – daha iyi bir terim istemek için – “hareket eden şeyler” için hangi seçenekleri sunuyor?

Veritabanı Önekini Değiştirme

WordPress, varsayılan olarak wp_ veritabanı tablosu adı önekini kullanır. Bu önek, tüm veritabanı tablosu adlarına eklenir ve diğer bazı yerlerde de kullanılır; örneğin, seçenekler tablosundaki <prefix>user_roles seçeneği ve <prefix>capabilities kullanıcı meta girdileri.

Bilgisayar korsanları veya saldırganlar, bir saldırıda varsayılan öneki kullanabilir ve veritabanı tablolarınızı keşfetmeye veya değiştirmeye çalışabilir. Bu yüzden bazı insanlar onu varsayılandan değiştirmenizi önerir.

wp_config seçeneği $table_prefix bunu yapmanıza izin verir ve muhtemelen onu alt çizgi ile eklenmiş kısa ama rastgele bir dizeye ayarlamanız gerekir:

 $table_prefix = 'b4F8az_';

Bu, WordPress'e b4F8az_posts yerine wp_posts gibi tablo adlarını kullanmasını söyleyecektir.

Bu değişikliği karşılamak için herhangi bir kodu güncellemeniz gerekmemelidir (bu kod çok kötü bir şekilde yazılmamışsa), ancak bunu mevcut bir sitede değiştiriyorsanız, veritabanınızda bazı güncellemeler yapmanız gerekir - yalnızca yeniden adlandırmak değil Masalar!

Bazı güvenlik eklentileri bunu sizin için yapacak ve bunu yapabilen bir eklenti de var. Bunu yapmadan önce veritabanınızın yedeğini almanızı şiddetle tavsiye ederiz ve varsayılan olmayan bir tablo öneki seçmenin en iyi şekilde WordPress'i kurarken yapılır, siteniz yayındayken değiştirirken değil.

Bununla ilgili ilginç bir not, $table_prefix bir sabit değil bir değişken olmasıdır. WordPress'in size verdiği örnek yapılandırma dosyasında tanımlanan tek değişkendir! Ve hala merak ediyorsanız: evet, WP-CLI'nin wp config komutları, sizin bilmenize bile gerek kalmadan bunu sizin için halleder!

User ve Usermeta Tablolarını Taşıma

Bunun yapıldığını hiç görmedim ve sadece bu makaleyi yazarken yapılabileceğini öğrendim, ancak user ve usermeta tablolarının adlarını tamamen değiştirebilirsiniz.

Sanırım bu, “SELECT * FROM wp_usermeta;”ya çalışan bir SQL enjeksiyon saldırısını önlemeye yardımcı oluyor, ancak bunu yapmak için başka nedenler duyduğuma sevindim.

Her durumda, ihtiyacınız olan şey CUSTOM_USER_TABLE ve CUSTOM_USER_META_TABLE sabitleridir:

 define( 'CUSTOM_USER_TABLE', $table_prefix.'my_users' ); define( 'CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta' );

Bu sabitleri kullanmadan önce bilmeniz gereken bazı uyarılar var. Bu özelliği kullanmadan önce resmi belgeleri kontrol edin. Ve özel bir tablo öneki kullanmak gibi, bu kesinlikle daha sonra değiştirmek yerine yeni bir site kurarken yapılır.

İçeriği, Yüklemeleri ve Eklenti Dizinlerini Taşı

Tüm wp-content dizinini, uploads dizinini ve themes ve plugins dizinlerini taşımak da mümkündür. Dikkat edilmesi gerekenler:

• Bu durumlardan bazılarında dizini olduğu kadar URL'yi de ayarlamanız gerekir.
• Tam yolları veya uygun olan göreli yolları kullanırken dikkatli olmanız gerekir.
• Bu ayarların hiçbirinin sonunda eğik çizgi olmamalıdır.

Ayrıntılar için resmi belgelere bakın – bunların hepsini burada tekrar etmeyeceğim.

Son olarak, bunları değiştirirseniz kötü kodlanmış bir eklenti veya temanın bozulabileceğini unutmayın. Bu asla olmamalı , ama bilmeye değer.

Bir eklenti veya tema geliştiricisiyseniz, bu yolların değişebileceğini unutmamak önemlidir. Bu nedenle, dizinlere veya URL'lere giden yolları sabit kodlamadığınızdan emin olun. Burada sizin için faydalı işlevler şunlardır:

wp_upload_dir
plugins_url
plugin_dir_url
plugin_dir_path
get_stylesheet_directory
get_stylesheet_directory_uri
get_template_directory – bir alt tema için bunun ana temanın konumunu döndürdüğünü unutmayın
get_template_directory_uri

WordPress geliştiricisinin el kitabında bunun gibi daha kapsamlı bir işlev listesi vardır.

Son olarak, dosyaları WordPress kurulumunuzun içinde taşımanın yanı sıra wp-admin konumunuzu da taşımak veya sitenizin konumunu değiştirmek isteyebilirsiniz. Ve wp-config.php bu konuda da yardımcı olabilir.

İçerikle İlgili Ayarlar

WordPress sonuçta bir içerik yönetim sistemidir. Bu nedenle, içerik seçeneklerini kontrol etmek için wp-config.php içinde kullanabileceğiniz bazı sabitleri bekleyebilirsiniz. Bir göz atalım ve neler yapabileceğimizi görelim.

Site ve Gösterge Tablosu URL'lerini Değiştirin

Bunlar hep kafamı karıştırmıştır.

Sitenizin URL'sini ayarlamak için WP_HOME sabitini değil, WP_SITEURL sabitini kullanmanız gerekir.

WP_SITEURL sabiti sitenizin URL'sini değiştirmez.

Kafası karışmış?

WP_SITEURL ne yaptığının resmi açıklaması, "WordPress çekirdek dosyalarınızın bulunduğu adres" dir. Bu aynı zamanda bir dizin değil, bir URL olduğu için kafa karıştırıcıdır.

Bunun için beni suçlama, ben sadece günlük tur rehberinim!

WP_HOME ve WP_SITEURL ayarı, wp_options veritabanı tablosundaki home ve siteurl girişlerini geçersiz kılar. Yani en azından mantıklı.

 // NOTE: These must not have trailing slashes define( 'WP_HOME', 'https://helfish.media' ); define( 'WP_SITEURL', 'https://hellfish.media/wordpress` );

Bir siteyi yeni bir URL'ye taşıdıktan sonra, veritabanını düzgün bir şekilde düzeltirken siteyi çalışır duruma getirmek için bu sabitleri kullanabilirsiniz. Daha sonra onları yerinde bırakmayı bile seçebilirsiniz.

WP_SITEURL ayarı, temel WordPress dosyalarınızı farklı bir dizine taşıdığınızda da kullanılabilir.

Bunları kullanmak, seçenekler tablosundan değerleri almak için bir veya iki veritabanı sorgusunun çalıştırılmasını da önler, bu nedenle marjinal bir performans kazancı olabilir. Nesne önbelleğe alma yapıyorsanız, bu kazanç muhtemelen ihmal edilebilir.

Resmi belgelerde biraz daha ayrıntı ve hatta site URL'sini değiştirmeyle ilgili tam bir destek makalesi var. Ek olarak, bu makale wp-config.php için bu makaleyi araştırmadan önce adını hiç duymadığım belirsiz RELOCATE sabitini içeriyor.

Son olarak, siteleri taşırken, değiştirmeniz gereken tek şeyin bu olmadığını unutmayın. URL dizeleri için tam bir veritabanı arama ve değiştirme önerilir.

Gönderi Ayarları

Gönderiler söz konusu olduğunda değiştirebileceğiniz birkaç farklı ayar vardır. Bunların çoğu, revizyon sonrası veya otomatik kaydetme özelliği ile ilgilidir.

Revizyon Sonrası

WordPress'in varsayılan davranışı, gönderilerde ve sayfalarda yapılan tüm revizyonları kaydetmektir. Bunun avantajı, önceki sürümlere geri dönmenin kolay olmasıdır. Dezavantajları, tüm bu revizyonların veritabanında yer kaplaması ve veritabanı sorgularını yavaşlatarak site performansını etkileyebilmesidir.

wp-config.php dosyanızdaki WP_POST_REVISIONS değerini değiştirerek post revizyonlarını tamamen devre dışı bırakmak mümkündür. Varsayılan olarak true olur. Düzeltmeleri kapatmak için bunun yerine false olarak ayarlayabilirsiniz:

 define( 'WP_POST_REVISIONS', false );:

WP Engine dahil olmak üzere bazı ana bilgisayarlar, varsayılan olarak revizyonları devre dışı bırakır. Herhangi bir değişiklik yapmadan önce barındırma sağlayıcınızla görüşmenizi öneririm. Bu, ana bilgisayardan ana bilgisayara değişir, ancak WP Engine kullanıyorsanız, sunucu düzeyinde üzerine yazılacağı için wp-config aracılığıyla revizyonları etkinleştiremezsiniz.

Ev sahibiniz bunu kontrol ediyorsa ve değiştirmeye çalışırsanız, mutlaka bir şeyi bozmazsınız, ancak zamanınızı boşa harcıyor olabilirsiniz.

Veritabanı sorgularını yavaşlatan revizyon sonrası endişeleriniz varsa , WordPress'in depoladığı revizyon sayısını sınırlamak daha iyi bir seçenek olabilir. Bu, tutmak istediğiniz maksimum revizyon sayısına ayarlayabileceğiniz WP_POST_REVISIONS sabiti tarafından kontrol edilir:

 define( 'WP_POST_REVISIONS', 5 );

Otomatik Kaydetme Aralığını Değiştirme

Otomatik kaydetmenin ne sıklıkta patlayacağını da azaltabilirsiniz. Bu, her 60 saniyede bir varsayılandır, ancak istediğiniz gibi değiştirebilirsiniz. Paranoyaksanız, bunun yerine bunu 20 veya 30 saniyeye ayarlamak isteyebilirsiniz.

Otomatik kaydetmenin ne kadar sürdüğünü akılda tutmak önemlidir. Bunları çok sık yaparak üst üste gelmelerini istemezsiniz, bu nedenle bu değeri örneğin bir saniyeye ayarlamayın. Otomatik kaydetmenin varsayılan 60 saniyeden fazla sürmesi pek olası değildir, ancak istekleri kaydetmek istiyorsanız aralığı artırabilirsiniz:

 define( 'AUTOSAVE_INTERVAL', 120 ); // Seconds

Toplama

wp-config kilidi açılmayı bekleyen çok fazla potansiyel var. Umarım bu tur, mümkün olanlardan sadece bazılarını vurgulamaya yardımcı olmuştur. Gelecekteki bir makalede, çok siteli kurulumlar ve hata ayıklama dahil olmak üzere wp-config içinde bulunan gelişmiş yeteneklerin daha fazlasını inceleyeceğim. Bellek sınırlarının, CRON sorunlarının ve ortam türlerinin nasıl ayarlanacağı dahil olmak üzere performansa da bakacağım.

Resmi belgelerde gizlenen ve keşfedilmeyi bekleyen başka hazineler olduğuna şüphe yok. wp-config kullanmak için hangi ipuçlarını buldunuz? Yorumlarda bana bildirin.