WP_HOME ve WP_SITEURL Farkı: Adres Ayarları

WordPress'in iki adres ayarı vardır: WordPress Adresi ve Site Adresi. İkisi yanlış eşleşirse yönetim paneli açılmaz, ön yüz başka bir adrese atlar ya da tarayıcı sonsuz yönlendirme uyarısı verir. Kısa cevap: WP_SITEURL çekirdek dosyaların bulunduğu adrestir, WP_HOME ise ziyaretçinin tarayıcıya yazdığı adrestir. İkisi sıradan kurulumda aynıdır. WordPress'i ayrı bir klasöre kurduysanız farklı olabilirler. wp-config.php dosyasına yazılan sabitler veritabanındaki değeri geçersiz kılar ama değiştirmez. Taşıma yapan, adres ayarını sertleştiren ya da döngüyle uğraşan bir yayıncı, küçük işletme sahibi ya da ajanssanız, bu ayrım sorunun nerede olduğunu hızla gösterir.

İki adres, iki ayrı rol

wp-config.php düzenleme belgesi (yeni sekmede açılır) iki sabiti ayrı ayrı tanımlar. WP_SITEURL, WordPress adresinin tanımlanmasını sağlar ve belgeye göre tanımlanan değer, WordPress çekirdek dosyalarının bulunduğu adrestir. WP_HOME ise belgenin ifadesiyle, insanların WordPress blogunuza ulaşmak için tarayıcılarına yazmasını istediğiniz adrestir. Bu iki cümle ayrımın tamamını taşır: biri dosyaların yeri, öteki ziyaretçinin kapısı.

İkisinin farklı olduğu kurulum

Belge, WordPress'e kendi dizinini vermek için bir örnek verir. WordPress dosyaları alt klasörde dururken, ziyaretçiler alan adının kökünü kullanır. Böyle bir kurulumda WP_HOME köke, yani alan adının ana adresine ayarlanır ve belgenin söylediği gibi web kökünde ayrıca bir index.php dosyası bulunur. WP_SITEURL ise çekirdek dosyalarının durduğu alt klasörün adresidir. Bu örnek, iki ayarın neden ayrı olduğunu gösterir. Tek klasörlü sıradan kurulumda ikisi aynı değeri taşır.

Hangi adres neyi etkiler

Arayüzü Türkçe kullanıyorsanız ayar ekranındaki alan adları buradaki karşılıklardan farklı görünebilir. wp-config belgesi Ayarlar, Genel ekranındaki bu iki alanı anlatmaz; taşıma belgesi ise bu ekranda adresleri değiştirmeyi anar.

wp-config.php sabitleri ne yapar, ne yapmaz

İki sabit de veritabanındaki wp_options tablosunda saklanan siteurl ve home değerlerini geçersiz kılar. Belgenin yinelediği nokta şudur: sabit veritabanındaki değeri değiştirmez. Sabiti dosyadan silerseniz, belgenin ifadesiyle adres eski veritabanı değerine döner. Bu davranış iki yönlü bir uyarıdır. Sabit, hatalı bir veritabanı değerini örtebilir; ama örttüğü için sorunu çözmüş olmaz.

Sabit tanımının avantajı

Belge, bu sabitleri tanımlamanın site adresi yapılandırmasını koda sabitlediğini, bunun taşınabilirliği artırdığını ve yönetim panelindeki yazım hatalarından ya da yanlış yapılandırmadan doğan sorunları önlemeye yardım ettiğini söyler. Taşıma belgesi buna bir yan etki ekler: wp-config.php'ye eklenen WP_HOME ve WP_SITEURL, yönetim panelindeki ilgili alanları kilitler. Yani panelden değiştirmeye çalıştığınızda alan düzenlenemez durumda görünür.

Biçim kuralları

Her iki sabit için de iki kural geçerlidir. Adres şemayı içermelidir, yani https:// ile başlamalıdır. Sonda eğik çizgi bulunmamalıdır. Belge örneklerinde alt klasörlü bir kurulumda adresin sonuna klasör adı eklendiğini de gösterir. Taşıma belgesi aynı iki kuralı siteurl ve home değerleri için yineler. Uygulama önerisi: adresi değiştirmeden önce yazım denetimini bir kontrol sorusuna çevirin: şema var mı, sonda eğik çizgi yok mu, alan adı doğru yazıldı mı?

Dinamik tanım uyarısı

Belge, adresi sunucu değişkenlerinden türeten dinamik bir örnek de verir. Aynı belge, HTTP_HOST kullanımının dosya ekleme açıklarına yol açabileceği uyarısını yapar ve Apache'de UseCanonicalName açıkken SERVER_NAME'in daha güvenli olduğunu belirtir. Uygulama önerisi: adresi sabit bir metin olarak yazmak, her isteğe göre türetmekten daha öngörülebilirdir; dinamik tanım gerekiyorsa belgenin güvenlik notunu okuyun.

Veritabanı değerini değiştirmek için sabit ne işe yarar

Belge, veritabanı değerlerinin değiştirilmesi için RELOCATE sabitine işaret eder ancak sözdizimini açıklamaz. Bu yüzden bu sabitin ayrıntısını belgeden öğrenemezsiniz; ilgili belge sayfasına bakmanız gerekir. Bu not belgenin taşıma bölümündedir; sunucunuzda farklı olabilir. Taşıma belgesi veritabanı değerini değiştirmenin başka yollarını sayar: yönetim panelinde ayarlar ekranı, geçici bir update_option satırı, phpMyAdmin'de wp_options tablosunu düzenlemek ve WP-CLI'da wp option update komutu.

Veritabanı değeri ile sabit çakıştığında

Üç ayrı yer adresi tutabilir: wp-config.php sabitleri, veritabanındaki siteurl ve home değerleri ve içerik içindeki sabit yazılmış bağlantılar. Sabit varsa veritabanı değeri geçersiz kılınır. Sabit yoksa veritabanı değeri kullanılır. Sorun, bir tarafı değiştirdiğinizi sanıp diğer tarafın hâlâ eski değeri tuttuğu durumlarda çıkar.

Uygulama önerisi: tablodaki son satırı belgeden değil uygulama deneyiminden çıkarım olarak okuyun; belge şema farkını ayrıca ele almaz. Sabitle veritabanı değerinin birbirinden ayrılması, sonradan bir taşıma ya da bir eklenti çakışması sırasında şaşırtıcı davranışa yol açar. Bu nedenle taşıma tamamlandığında iki tarafı da aynı değere getirip sonuçları yazmak, ileride vakit kazandırır.

Döngü, karışık içerik ve panele girememe

Uygulama önerisi: bu bölümdeki belirtileri belgeye değil yoruma dayalı sayın; wp-config belgesi yönlendirme döngülerini ya da karışık içeriği anlatmaz. Belgelerde bu konuda ifade yok. Bu bölümdeki tablo, adres ayarlarıyla ilişkili olabilecek tipik görünümleri ve kontrol edilecek noktayı sıralar.

Yönlendirme döngüsünün iki kaynağı

Uygulama önerisi: döngüyü iki katmandan ayrı ayrı sorgulayın. Birinci katman WordPress'in kendi adres ayarlarıdır. İkinci katman sunucu kurallarıdır: .htaccess dosyasındaki ya da sunucu yapılandırmasındaki www kuralı ve https yönlendirmesi. WordPress adresi https ise ama sunucu kuralı http'ye yönlendiriyorsa iki kural birbirini geri iter. Döngünün genel çözümü için yönlendirme zinciri ve döngüsünün nasıl düzeltileceği yazısındaki yöntem geçerlidir. Burada yapılacak iş, adres ayarlarının bu çatışmanın bir tarafı olup olmadığını elemektir.

Karışık içerik belirtisi

Adresi http'den https'ye geçirdikten sonra bazı sayfaların güvenli görünmemesi, içerikte hâlâ http ile yazılmış görsel ya da betik adresleri kaldığını gösterebilir. Bu sorun adres ayarından değil, içerikteki sabit yazılmış bağlantılardan kaynaklanır. Taşıma belgesi, eski adresin görsel bağlantılarında, eklenti seçeneklerinde ve widget'larda kalabileceğini ve temizliğin dikkatli bir arama-değiştirme ile yapılması gerektiğini anlatır; bu konuya site taşıma sırasında backlink değerini koruma yazısındaki taşıma sırası da değinir.

Örnek durum: yalnızca ön yüz bozuk

Ön yüz açılmıyor ama yönetim paneli çalışıyorsa, şüphe Site Adresi üzerindedir. Bu durumda panelde Ayarlar, Genel ekranına girip Site Adresini kontrol edin; sabit tanımlıysa alan kilitli olacağı için wp-config.php dosyasındaki WP_HOME satırına bakın. Ters durumda, ön yüz çalışıp panel stilsiz ya da hatalı açılıyorsa WordPress Adresi ve WP_SITEURL şüphelidir. Bu ayrım, hangi satıra dokunacağınızı daraltır ve iki ayarı birlikte değiştirip sorunun kaynağını gizlemenizi önler.

Uygulama önerisi: tek seferde yalnızca bir değeri değiştirin ve her değişiklikten sonra kaynağı çıkış yapmış tarayıcıda yeniden okuyun. İki değeri aynı anda değiştirirseniz, düzelmeyi hangisinin sağladığını ya da yeni bir hatanın hangisinden doğduğunu ayırt edemezsiniz. Her değişikliği envanterdeki kayda tarihle yazın.

Alan adı yazımında dikkat edilecek hatalar

Adres sorunlarında şaşırtıcı sayıda neden yazım hatasıdır: eksik şema, fazladan eğik çizgi, www'lu ve www'suz biçimin karışması, alan adında harf hatası ya da eski alan adının kalması. Belge sabit tanımlamanın yazım hatalarından doğan sorunları önlemeye yardım ettiğini söyler; yine de sabitin kendisi de yanlış yazılabilir. Değeri yazdıktan sonra tarayıcı adres çubuğuna yapıştırıp açın; sayfa açılıyorsa yazım doğrudur.

Güvenli düzeltme sırası

Adres ayarını bozmuş bir sitede panik, ikinci bir hata doğurur. Uygulama önerisi: değişiklik yapmadan önce şu sırayı izleyin. Taşıma belgesi de işe yedek alarak başlar ve bu adımı bir tavsiye değil gereklilik olarak anlatır.

1. Dosyaların ve veritabanının yedeğini alın.
2. wp-config.php dosyasının bir kopyasını ayrı bir yere kaydedin.
3. Şu an hangi adresin kullanıldığını yazın: sabitlerde ne yazıyor, veritabanında ne yazıyor.
4. Hangi katmanın doğru olduğuna karar verin. Doğru adres belliyse, her iki yeri de buna eşitleyin.
5. Sabit kullanıyorsanız, sabitin şema ve sondaki eğik çizgi kurallarına uyduğunu doğrulayın.
6. Sunucu tarafındaki yönlendirme kurallarını ayrıca okuyun.
7. Önbelleği temizleyin ve çıkış yapmış bir tarayıcıda ana sayfayı, bir yazıyı ve yönetim giriş sayfasını açın.
8. Sorun sürerse, değişikliği geri alıp bir sonraki katmana geçin.

Panele girilemiyorsa

Yönetim paneline giremiyorsanız adresi panelden değiştiremezsiniz. Taşıma belgesi bu durum için alternatifleri sayar: wp-config.php'ye sabit eklemek, geçici bir update_option satırı eklemek ya da veritabanında wp_options tablosunu düzenlemek ya da WP-CLI kullanmak. Hangi yolu seçerseniz seçin, önce yedek alın ve işiniz bittiğinde geçici satırı kaldırın. Geçici satırı bırakmak, sonraki değişikliklerde yine kilit ve şaşırtıcı davranış demektir.

Taşıma sırasında adres ayarı

WordPress taşıma belgesi (yeni sekmede açılır) iki durumu ayırır. Adresler değişmiyorsa dosyaları ve veritabanını kopyalarsınız; veritabanı adı ya da kullanıcı değişirse yeni sunucuda wp-config.php güncellenir. Adresler değişiyorsa belge sıralı bir yol tarif eder. Yeni sunucuyu canlıya almadan önce sınamak için siteurl ve home değerlerini geçici olarak değiştirebileceğinizi de söyler. Belgedeki alan adı değişikliği sırasında eski sitede Ayarlar, Genel ekranından adresleri değiştirdiğinizde bir 404 sayfası göreceğinizi bekleyin: bu beklenen bir sonuçtur, çünkü site artık yeni adreste olduğunu sanır.

Uygulama önerisi: taşıma sırasında sabit kullanın ve işiniz bitince sabitle veritabanı değerini aynı yere getirin. Böylece taşıma bittikten sonra siteyi bir eklentinin ya da bir sonraki yöneticinin karıştıracağı bir durumda bırakmazsınız. Taşımanın tam sırası için test ortamı indekslenmesini önleme yazısındaki kuralları da gözden geçirin: hazırlık ortamı yeni bir adrese taşındığında arama motorlarına açık kalmamalıdır.

Dizin taşırken sıra: önce adres, sonra dosya

Taşıma belgesi aynı sunucuda dizin değiştirenler için bir sıra verir: adres konumlarını dosyaları taşımadan önce ayarlamak gerekir. Bunu unutursanız belge bir sembolik bağ çözümü önerir. Aynı bölümde birkaç ek not vardır: izni 0000 olan dosyalar bulunursa 0644 yapılmalıdır, ana sayfaya giden bağlantılar eski alt dizini hâlâ taşıyabilir ve bazen sunucuyu yeniden başlatmak gerekir. Bu not belgenin taşıma bölümündedir; sunucunuzda farklı olabilir. Belgede DNS ya da hosts dosyasıyla deneme konusunda ifade yok.

Adresi okumanın üç yolu

Bir adresin şu anda ne olduğunu görmenin birden çok yolu vardır ve her yol farklı bir katmanı gösterir. Üçünü karşılaştırmadan değişiklik yapmayın.

Karşılaştırmanın kendisi sorunun yerini gösterir, çünkü belirtiyi doğuran şey katmanlar arasındaki uyumsuzluktur.

İlgili sabitler: güvenli yönetim ve çerez alanı

Aynı wp-config.php sayfası adres ayarlarının iki komşusunu da anlatır. FORCE_SSL_ADMIN, girişleri ve yönetim alanını güvenli hale getirmek için kullanılır; sayfa FORCE_SSL_LOGIN sabitinin 4.0 sürümünde kullanımdan kaldırıldığını ve bu sabitle değiştirildiğini belirtir. COOKIE_DOMAIN ise alışılmadık alan adı kurulumlarında çerez alanını belirler, örneğin www.example.com biçiminde açıkça yazmak gerektiğinde. İkisi de doğru site adresinin yerine geçmez, ama taşımadan sonra girişin davranışını değiştirebilir. Uygulama önerisi: adres değişikliğinden sonra giriş başarısız oluyor ve adresler doğru görünüyorsa, adresi suçlamadan önce bu iki sabite bakın.

Önbellek, CDN ve oturum katmanları

Adres ayarını doğru yazdıktan sonra bile eski davranışı görmeniz mümkündür, çünkü adres birden çok katmanda önbelleğe alınabilir. Uygulama önerisi: her değişiklikten sonra katmanları sırayla temizleyin ve her temizlikten sonra aynı sayfayı yeniden açın.

Tarayıcının kalıcı yönlendirmeyi hatırlaması, döngü teşhisini zorlaştıran bir ayrıntıdır: ayarı düzelttiğiniz hâlde tarayıcı eski hatalı yönlendirmeyi izlemeye devam edebilir. Bu yüzden aynı sayfayı hem gizli pencerede hem normal pencerede açıp sonuçları karşılaştırın.

Yedekten dönüş ve geri alma notu

Adres ayarını değiştirirken bir şey ters giderse, yedeğe dönmek her zaman mümkündür. Önceki sabit değerlerini ve veritabanı değerlerini yazılı tuttuysanız, yedeği geri yüklemeden yalnızca bu iki değeri eski haline getirmek de yeterli olabilir. Kayıt yoksa elinizdeki tek güvenceniz yedek dosyalardır. Bu nedenle değişiklik kaydını, düzeltmeden önce başlatın; düzeltmeden sonra hatırlamaya çalışmayın.

Ekip içinde sorumluluk

Adres ayarı, bir kişinin yaptığı ve sessizce unutulan bir değişikliğe dönüşebilir. Ekip çalışıyorsanız, adres ayarını kimin değiştirebileceğini ve değişikliğin nereye yazılacağını önceden belirleyin. Müşteri sitelerinde bu kayıt, teslim belgesinin bir satırı olur. Böylece bir yıl sonra siteyi devralan kişi, panelde kilitli duran alanın nedenini kaydı okuyarak bulur.

Adres ayarı arama görünürlüğünü nasıl ilgilendirir

Uygulama önerisi: adres ayarını bir SEO girdisi olarak ele alın, çünkü sayfalarınızda görünen adresleri o besler. Herhangi bir değişiklikten sonra çıkış yapmış tarayıcıda birkaç sayfanın kaynağını açın; canonical etiketine, sitemap adresine ve gezinme bağlantılarına bakın. Biri hâlâ eski alan adını ya da yanlış şemayı gösteriyorsa, adres ayarı ya da içerik niyet ettiğiniz adresle uyumsuz demektir. wp-config sayfası canonical ya da sitemap çıktısını anlatmaz; bu yüzden bu bir WordPress'in nasıl üretim yaptığına dair bir iddia değil, yapılacak bir kontroldür.

Yeniden kullanılabilir değişiklik kaydı

Her adres değişikliği için kısa bir kayıt tutun: tarih, değişikliği yapan kişi, sabitlerin önceki ve sonraki değerleri, veritabanının önceki ve sonraki değerleri ve kontrol ettiğiniz sayfalar. Ay sonra aynı sorun döndüğünde, bu kayıt bir günlük tahmini on dakikalık bir karşılaştırmaya çevirir. Kayıt tablosunu ajanslarda müşteri teslim notuna, tek kişilik sitelerde kendi çalışma defterinize koyun.

Alt klasörlü kurulumda ek dikkat

WordPress'e kendi dizinini verdiyseniz iki adres bilerek farklıdır ve bu fark bir hata değildir. Bu kurulumda web kökündeki index.php dosyasının doğru yolu gösterdiğini, WP_SITEURL'ün çekirdek klasörüne işaret ettiğini ve WP_HOME'un alan adının köküne işaret ettiğini ayrı ayrı doğrulayın. İkisini eşitlemeye kalkmak, bilerek kurulmuş bir yapıyı bozar. Taşıma sırasında bu kurulumu olduğu gibi koruyacaksanız, yeni sunucuda hem alt klasörün hem kökteki dosyanın birlikte taşındığından emin olun.

Karar kuralı

Adres sorununda üç soru yeterlidir.

1. Sorun panelde mi yoksa ön yüzde mi? Panelde ise WordPress Adresi, ön yüzde ise Site Adresi şüphelidir.
2. Adres wp-config.php sabitinden mi yoksa veritabanından mı geliyor? Sabit varsa veritabanını okumak sonuç vermez.
3. Sorunun kaynağı WordPress mi yoksa sunucu mu? Sunucu yönlendirmesi adresle çelişiyorsa ayarı değiştirmek tek başına çözmez.

Cevaplar ayrışıyorsa en küçük değişiklikten başlayın: önce ayar, sonra sabit, en son sunucu kuralı.

Karar tablosu: hangi yolla düzeltmeli

Örnek senaryo: bir mobilya atölyesinin portföy sitesi

Örnek senaryo: Bir mobilya atölyesi, portföy sitesini yeni bir barındırma hizmetine taşımış ve aynı fırsatta https'ye geçmiştir. Taşıma sonrası ana sayfa açılır ama yönetim paneli stilsiz görünür ve bazı görseller güvenli görünmez.

Atölye, hangi adımın neyi çözdüğünü bir sayfaya yazar. Bir sonraki taşımada aynı yol bir kontrol listesine dönüşür.

Örnek senaryo: bir yelken okulunun kurs sitesi

Okulun sitesi, aynı sunucuda bir alt klasörden alan adının köküne taşınıyor. Ekip önce dosyaları taşıyıp sonra adresi değiştirmeye çalışıyor ve panele girilemiyor. Düzeltme sırası şöyledir: veritabanının yedeğini alın, siteurl ve home değerlerini düzeltin, ardından dosya izinlerinde 0000 olanları kontrol edin. Ana sayfadaki bağlantılar eski klasörü taşıyorsa içerikteki sabit adresleri arayın. Her adımdan sonra çıkış yapmış bir tarayıcıda ana sayfayı açın. Bu senaryo kurgusaldır.

Kontrol listesi

Adres ayarını değiştirmeden önce:

• Dosya ve veritabanı yedeği alındı mı
• wp-config.php dosyasının kopyası saklandı mı
• Sabitlerde ve veritabanında şu anki değerler yazıldı mı
• Yeni adres şemayı içeriyor mu, sonunda eğik çizgi yok mu
• Sunucu yönlendirme kuralları okundu mu

Değişiklikten sonra:

• Ana sayfa, bir yazı ve yönetim giriş sayfası çıkış yapmış tarayıcıda açıldı mı
• Önbellek temizlendi mi
• Geçici satırlar kaldırıldı mı
• Sabit ile veritabanı değerleri aynı mı
• İçerikte eski adresli bağlantılar arandı mı

İkinci gün gözden geçirme listesi

• RELOCATE sabiti ve functions.php içindeki geçici kod kaldırıldı mı?
• Veritabanı yedeği dışarıda saklanıyor mu?
• Ana sayfa ve bir iç sayfa çıkış yapmış tarayıcıda doğru adrese açılıyor mu?
• Eski adresi taşıyan bağlantı kaldı mı?
• Değişiklik günlüğüne tarih, değer ve sorumlu yazıldı mı?

Ajanslar için notlar

Birden çok müşteri sitesini taşıyorsanız, adres ayarını her sitede aynı kontrol listesiyle belgeleyin. Bir sitede sabit tanımlıyken başka sitede tanımlı değilse, bir sonraki yönetici paneldeki alanın neden kilitli olduğunu anlamakta zorlanır. Teslim notuna adresin nereden geldiğini yazın. Bu belge sürüme ve barındırma ortamına göre değişebilir; uygulamadan önce güncel WordPress belgelerine bakın.

Geçici yöntemleri işiniz bitince kaldırmak

Taşıma belgesi adresi düzeltmek için iki geçici yol sayar: wp-config.php içine RELOCATE sabiti eklemek ve functions.php içine kısa bir kod parçası yazmak. İkisi için de uyarı açıktır. Belgeye göre RELOCATE sabitini wp-config.php dosyasında bırakmak güvensizdir ve functions.php içine eklenen kod orada bırakılmamalıdır. Adres düzeldikten sonra kaldırma adımı sık unutulduğu için ayrı bir kayda ihtiyaç duyar.

Yanlış anlaşılan noktalar

Birinci yanlış, adresi panelden değiştirmenin dosyaları taşımakla eşdeğer olduğu düşüncesidir; belge dosya konumu ile adres ayarını ayrı adımlar olarak anlatır. İkinci yanlış, sabit tanımlandığında veritabanı değerinin de güncellendiği düşüncesidir; belgeye göre sabit veritabanını değiştirmez. Üçüncü yanlış, çıkış yapmış tarayıcıda görünen adresin yönetim panelindeki adresle aynı olduğu düşüncesidir. Panelde kilitli görünen alan sabitin değerini gösterir, ziyaretçinin gördüğü şeyi değil. Uygulama önerisi: ziyaretçi görünümünü her zaman çıkış yapmış bir pencerede kontrol edin.

Sık Sorulan Sorular

WP_HOME ile WP_SITEURL aynı olmak zorunda mı?

Hayır. Belgeye göre WP_SITEURL çekirdek dosyaların bulunduğu adrestir, WP_HOME ise ziyaretçinin yazdığı adrestir. WordPress'i ayrı bir dizine kurmadıysanız ikisi aynı değeri taşır.

wp-config.php sabiti veritabanındaki değeri değiştirir mi?

Hayır. Belgeye göre sabit veritabanındaki değeri geçersiz kılar ama değiştirmez. Sabit silinirse adres eski veritabanı değerine döner.

Sabiti tanımlayınca panelden adres değiştirebilir miyim?

Taşıma belgesi, sabitleri wp-config.php dosyasına eklemenin yönetim panelindeki alanları kilitlediğini söyler. Değişikliği dosyada yapmanız gerekir.

Adresin sonuna eğik çizgi koymalı mıyım?

Hayır. Belge her iki sabit için de sonda eğik çizgi bulunmaması gerektiğini söyler. Adres https:// gibi şemayı içermelidir.

Yönlendirme döngüsünü bu ayar mı çözer?

Belgelerde döngü konusunda ifade yok. Adres ayarı döngünün bir kaynağı olabilir, ama sunucu yönlendirme kuralları da aynı döngüye yol açabilir; iki katmanı ayrı ayrı kontrol edin.

Sabiti kalıcı olarak bırakmak güvenli mi?

Belge sabit tanımlamanın taşınabilirliği artırdığını söyler. Kalıcı bırakacaksanız veritabanı değerini de aynı yere getirin ve envantere yazın.

Sonuç

Adres ayarı, WordPress'in iki ayrı sorusuna verdiği iki yanıttır: dosyalar nerede, ziyaretçi nereden gelir? WP_SITEURL ilkini, WP_HOME ikincisini karşılar. wp-config.php sabitleri veritabanındaki değeri geçersiz kılar ama değiştirmez; biçim kuralları şema içermek ve sonda eğik çizgi kullanmamaktır. Sorun çıktığında yedek alın, hangi katmanın hangi değeri taşıdığını yazın ve en küçük değişiklikten başlayın.

Adres ayarları yerine oturduğunda geriye düzenli içerik üretmek kalır.

Düzenli ve özenli içerik akışı için makale yazımı hizmetimize göz atabilirsiniz.