URLs relativos no WordPress

Sempre achei frustrante no WordPress que imagens, arquivos, links, etc. sejam inseridos no WordPress com uma URL absoluta em vez de uma URL relativa. Um url relativo é muito mais conveniente para trocar nomes de domínio, mudar entre http e https etc. Hoje eu descobri que se você definir WP_CONTENT_URL com um url relativo, quando você inserir arquivos em postagens eles usarão o url relativo para src em vez de url absoluto . Exatamente o que sempre quis! Mas a documentação oficial do WordPress diz que você deve usar um URI completo se estiver definindo WP_CONTENT_URL.

O códice do WordPress diz :

Defina WP_CONTENT_URL para o URI completo deste diretório (sem barra final), por exemplo

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

Tudo parece funcionar bem quando uso um URL relativo, por exemplo

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

Mas há algum problema em usar um URI relativo? Só estou pensando que deve haver um motivo para o WordPress declarar que deve ser definido com um URI completo.

Acho que esse é o tipo de pergunta que apenas um desenvolvedor central poderia / deveria responder. Eu pesquisei e encontrei o tíquete principal # 17048: URLs entregues ao navegador devem ser relativos à raiz . Onde podemos encontrar as razões explicadas por Andrew Nacin, desenvolvedor líder do núcleo. Ele também tem um link para este tópico [wp-hackers] . Em ambos os links, estas são as citações principais sobre por que o WP não usa URLs relativos:

Tíquete principal:

• URLs relativos à raiz não são realmente adequados. /path/pode não ser WordPress, pode estar fora da instalação. Então, realmente não é muito diferente de um URL absoluto.

• Quaisquer URLs relativos também tornam significativamente mais difícil realizar transformações quando a instalação é movida. A localização e substituição será necessária na maioria das situações, e ter uma URL absoluta é ironicamente mais portátil por esses motivos.

• URLs absolutos são necessários em vários outros lugares. A necessidade de adicioná-los condicionalmente aumentará o processamento, bem como introduzirá possíveis bugs (e incompatibilidades com plug-ins).

discussão [wp-hackers]

• Em relação ao que, não tenho certeza, já que o WordPress costuma estar em um subdiretório, o que significa que sempre precisaremos processar o conteúdo para adicionar o resto do caminho. Isso introduz sobrecarga.

• Lembre-se de que existem dois tipos de URLs relativos, com e sem barra inicial. Ambos têm ressalvas que tornam isso impossível de implementar adequadamente.

• O WordPress deve (e faz) armazenar URLs absolutos. Isso não requer nenhum pré-processamento de conteúdo, nenhuma sobrecarga, nenhuma ambigüidade. Se você precisar realocar, é um localizar-substituir global no banco de dados.

E, a título pessoal, mais de uma vez encontrei tema e plug-ins mal codificados que simplesmente quebram quando WP_CONTENT_URLsão definidos.
Eles não sabem que isso pode ser definido e presumem que isso é verdade: WP.URL / wp-content / WhatEver , e nem sempre é o caso. E algo vai quebrar ao longo do caminho.

O plugin URLs relativos ( link na Resposta do edse ), aplica a função wp_make_link_relativeem uma série de filtros no gancho de açãotemplate_redirect . É um código bastante simples e parece uma boa opção.

<?php wp_make_link_relative( $link ) ?>

Converta caminhos de URL completos em caminhos relativos.

Remove os protocolos http ou https e o domínio. Mantém o caminho '/' no início, então não é um link relativo verdadeiro, mas da base da raiz da web.

Referência: Wordpress Codex

Eu concordo com Rup. Acho que o principal motivo é evitar confusão em caminhos relativos. Acho que o wordpress pode funcionar do zero com caminhos relativos, mas o problema pode surgir ao usar vários plug-ins, como o tema é configurado etc.

Uma vez usei este plugin para caminhos relativos, ao trabalhar em servidores de teste:

URLs relativos
à raiz Converte todos os URLs em URLs relativos à raiz para hospedar o mesmo site em vários IPs, migração de produção mais fácil e melhores testes de dispositivos móveis.

Resolvi no meu site fazendo isso em functions.php

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);

}

Participei de um plugin, cortei-o em pedaços e fiz isso. Ele substituiu TODOS os links no meu site (menus, css, scripts etc.) e tudo estava funcionando.

Em Configurações => Mídia, há uma opção para 'Caminho de URL completo para arquivos'. Se você definir isso para o caminho do diretório de mídia padrão '/ wp-content / uploads' em vez de em branco, ele irá inserir caminhos relativos, por exemplo, '/wp-content/uploads/2020/06/document.pdf'.

Não tenho certeza se isso torna todos os links relativos, por exemplo, a posts, mas pelo menos lida com mídia, o que provavelmente é o que preocupa a maioria das pessoas.

deve usar get_home_url (), então seus links são absolutos, mas não afetará se você alterar o url do site

O que eu acho que você faz é enquanto você altera os nomes de domínio, o arquivo de despejo sql que você tem pode substituir todas as instâncias do nome de domínio antigo por um novo. Esta é a única opção disponível, pois não há plug-ins que o ajudem a fazer isso.

Esta é a maneira mais rápida ..

Existe uma maneira facil

Em vez de /pagename/usar index.php/pagename/ou se você não usar permalinks, faça o seguinte:

Postar

index.php?p=123

Página

index.php?page_id=42

Categoria

index.php?cat=7

Mais informações aqui: http://codex.wordpress.org/Linking_Posts_Pages_and_Categories