WordPress'teki göreli URL'ler

WordPress'te resimlerin, dosyaların, bağlantıların vb. Göreli URL yerine mutlak bir URL ile WordPress'e eklenmesini her zaman sinir bozucu bulmuşumdur. Göreli bir url, etki alanı adlarını değiştirmek, http ve https arasında değiştirmek vb. İçin çok daha kullanışlıdır. Bugün, WP_CONTENT_URL'yi göreli bir url ile tanımlarsanız, dosyaları gönderilere eklediğinizde, mutlak url yerine src için göreli url'yi kullandıklarını keşfettim. . Her zaman istediğim şey! Ancak resmi WordPress belgeleri, WP_CONTENT_URL'yi tanımlıyorsanız tam bir URI kullanmanız gerektiğini söylüyor .

WordPress kodeksi diyor ki :

WP_CONTENT_URL'yi bu dizinin tam URI'sine ayarlayın (eğik çizgi yok), örn.

define( 'WP_CONTENT_URL', 'http://example/blog/wp-content');

Göreli bir URL kullandığımda her şey yolunda görünüyor, örneğin

define( 'WP_CONTENT_URL', '/my-content-folder');

Ancak göreli bir URI kullanmanın bir sorunu var mı? Sadece WordPress'in tam bir URI ile tanımlanması gerektiğini belirten bir neden olması gerektiğini düşünüyorum.

Bence bu, yalnızca çekirdek bir geliştiricinin yanıtlayabileceği / yanıtlaması gereken türden bir soru. 17048 numaralı ana bileti araştırdım ve buldum: Tarayıcıya teslim edilen URL'ler kök temelli olmalıdır . Baş çekirdek geliştirici Andrew Nacin tarafından açıklanan nedenleri nerede bulabiliriz. Ayrıca bu [wp-hackerlar] dizisine de bağlantı veriyor . Bu bağlantıların her ikisinde de, WP'nin neden göreceli URL'ler kullanmadığına dair temel alıntılar şunlardır:

Temel bilet:

• Köke bağlı URL'ler gerçekten uygun değildir. /path/WordPress olmayabilir, kurulumun dışında olabilir. Yani gerçekten mutlak bir URL'den çok da farklı değil.

• Herhangi bir göreli URL, yükleme taşındığında dönüşüm gerçekleştirmeyi önemli ölçüde zorlaştırır. Bul-değiştir çoğu durumda gerekli olacaktır ve mutlak bir URL'ye sahip olmak bu nedenlerden dolayı ironik bir şekilde daha taşınabilirdir.

• Diğer birçok yerde mutlak URL'lere ihtiyaç vardır. Bunları koşullu olarak eklemeye ihtiyaç duymak, işlemeye katkıda bulunmanın yanı sıra olası hataları (ve eklentilerle uyumsuzlukları) ortaya çıkaracaktır.

[wp-hackerlar] ileti dizisi

• Neye göre, emin değilim, çünkü WordPress genellikle bir alt dizinde bulunur, bu da içeriği daha sonra yolun geri kalanına eklemek için her zaman işlememiz gerektiği anlamına gelir. Bu, yükü getirir.

• Başta eğik çizgi olan ve olmayan iki tür göreli URL olduğunu unutmayın. Her ikisinde de, bunun düzgün bir şekilde uygulanmasını imkansız kılan uyarılar vardır.

• WordPress mutlak URL'leri saklamalıdır (ve saklamalıdır). Bu, içeriğin önceden işlenmesini, ek yükü, belirsizliği gerektirmez. Taşınmanız gerekirse, bu, veritabanında global bir bul-değiştirdir.

Ve kişisel bir notta, defalarca WP_CONTENT_URL, tanımlandığında basitçe kırılan kötü kodlanmış tema ve eklentiler buldum .
Onlar bilmiyorum bu ayarlanabilir ve bunun doğru olduğunu varsayalım: WP.URL / wp-content / Whatever ve her zaman böyle değil. Ve yol boyunca bir şey kırılacak.

Relative URLs eklentisi ( edse 's Answer'da bağlantılıdır ), işlevi eylem kancasındakiwp_make_link_relative bir dizi filtredetemplate_redirect uygular . Oldukça basit bir kod ve hoş bir seçenek gibi görünüyor.

<?php wp_make_link_relative( $link ) ?>

Tam URL yollarını göreli yollara dönüştürün.

Http veya https protokollerini ve etki alanını kaldırır. Başlangıçta '/' yolunu tutar, bu nedenle bu gerçek bir bağıl bağlantı değil, web kök tabanından gelir.

Referans: Wordpress Codex

Rup'a katılıyorum. Sanırım ana sebep göreceli yollarda kafa karışıklığını önlemek. Bence wordpress göreceli yollarla sıfırdan çalışabilir, ancak sorun birden fazla eklenti kullanıldığında, temanın nasıl yapılandırıldığı vb.

Bir zamanlar bu eklentiyi sunucuları test ederken çalışırken göreli yollar için kullandım:

Kök Göreli URL'ler Aynı siteyi birden çok IP'de barındırmak, daha kolay üretim geçişi ve daha iyi mobil cihaz testi için tüm URL'leri köke göre URL'lere
dönüştürür.

Sitemde bunu functions.php'de yaparak çözdüm

add_action("template_redirect", "start_buffer");
add_action("shutdown", "end_buffer", 999);

function filter_buffer($buffer) {
    $buffer = replace_insecure_links($buffer);
    return $buffer;
}
function start_buffer(){
    ob_start("filter_buffer");
}

function end_buffer(){
    if (ob_get_length()) ob_end_flush();
}

function replace_insecure_links($str) {

   $str = str_replace ( array("http://www.yoursite.com/", "https://www.yoursite.com/") , array("/", "/"), $str);

   return apply_filters("rsssl_fixer_output", $str);

}

Bir eklentinin parçası oldum, parçalara böldüm ve bunu yaptım. Sitemdeki TÜM bağlantıları (menüler, css, komut dosyaları vb.) Değiştirdi ve her şey çalışıyordu.

Ayarlar => Medya altında, 'Dosyalar için tam URL-yolu' seçeneği vardır. Bunu boş yerine varsayılan medya dizini yolu '/ wp-content / uploads' olarak ayarlarsanız, göreli yollar ekler, örneğin '/wp-content/uploads/2020/06/document.pdf'.

Tüm bağlantıları, örneğin gönderilere göre mi yaptığından emin değilim, ama en azından medyayı işliyor, ki bu muhtemelen çoğu insanın endişelendiği şey.

get_home_url () kullanmalısınız, bu durumda bağlantılarınız mutlaktır, ancak site url'sini değiştirirseniz bu etkilenmez

Alan adlarını değiştirirken yaptığınızı düşündüğüm şey, sahip olduğunuz sql dökümü dosyası eski alan adının tüm örneklerini yenisiyle değiştirebilirsiniz. Bu, bunu yapmanıza yardımcı olacak hiçbir eklenti olmadığı için yalnızca seçenektir.

Bu en hızlı yoldur ..

Kolay bir yol var

Yerine /pagename/kullanımı index.php/pagename/Eğer kalıcı bağlantı kullanmayan veya eğer aşağıdakileri yapın:

İleti

index.php?p=123

Sayfa

index.php?page_id=42

Kategori

index.php?cat=7

Daha fazla bilgi burada: http://codex.wordpress.org/Linking_Posts_Pages_and_Categories