URL relativas en WordPress

Siempre me ha resultado frustrante en WordPress que las imágenes, archivos, enlaces, etc. se inserten en WordPress con una URL absoluta en lugar de una URL relativa. Una URL relativa es mucho más conveniente para cambiar nombres de dominio, cambiar entre http y https, etc. Hoy descubrí que si define WP_CONTENT_URL con una URL relativa, cuando inserta archivos en las publicaciones, usan la URL relativa para el src en lugar de la URL absoluta. . ¡Justo lo que siempre quise! Pero la documentación oficial de WordPress dice que debe usar un URI completo si está definiendo WP_CONTENT_URL.

El códice de WordPress dice :

Establezca WP_CONTENT_URL en el URI completo de este directorio (sin barra diagonal), por ejemplo

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

Todo parece funcionar bien cuando uso una URL relativa, por ejemplo

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

Pero, ¿hay algún problema con el uso de un URI relativo? Solo estoy pensando que debe haber una razón para que WordPress indique que debe definirse con un URI completo.

Creo que este es el tipo de pregunta que solo un desarrollador central podría / debería responder. Investigué y encontré el ticket principal # 17048: las URL entregadas al navegador deben ser relativas a la raíz . Donde podemos encontrar las razones explicadas por Andrew Nacin, desarrollador principal principal. También enlaza a este hilo [wp-hackers] . En ambos enlaces, estas son las citas clave sobre por qué WP no usa URL relativas:

Boleto básico:

• Las URL relativas a la raíz no son realmente adecuadas. /path/podría no ser WordPress, podría estar fuera de la instalación. Entonces, realmente no es muy diferente a una URL absoluta.

• Cualquier URL relativa también dificulta significativamente la realización de transformaciones cuando se mueve la instalación. La búsqueda-reemplazo será necesaria en la mayoría de las situaciones, y tener una URL absoluta es irónicamente más portátil por esas razones.

• Se necesitan URL absolutas en muchos otros lugares. La necesidad de agregarlos de forma condicional aumentará el procesamiento, además de introducir errores potenciales (e incompatibilidades con los complementos).

[wp-hackers] hilo

• En relación con qué, no estoy seguro, ya que WordPress a menudo está en un subdirectorio, lo que significa que siempre necesitaremos procesar el contenido para luego agregar el resto de la ruta. Esto introduce gastos generales.

• Tenga en cuenta que hay dos tipos de URL relativas, con y sin barra inclinada. Ambos tienen advertencias que hacen que esto sea imposible de implementar correctamente.

• WordPress debería (y lo hace) almacenar URL absolutas. Esto no requiere preprocesamiento de contenido, gastos generales ni ambigüedad. Si necesita reubicarse, es una búsqueda y reemplazo global en la base de datos.

Y, en una nota personal, más de una vez he encontrado temas y complementos mal codificados que simplemente se rompen cuando WP_CONTENT_URLse definen.
No saben que esto se puede configurar y asumen que esto es cierto: WP.URL / wp-content / WhatEver , y no siempre es así. Y algo se romperá en el camino.

El plug-in URL relativos (en relación en EDSE respuesta 's ), se aplica la función wp_make_link_relativede una serie de filtros en el gancho de la accióntemplate_redirect . Es un código bastante simple y parece una buena opción.

<?php wp_make_link_relative( $link ) ?>

Convierta las rutas de URL completas en rutas relativas.

Elimina los protocolos http o https y el dominio. Mantiene la ruta '/' al principio, por lo que no es un vínculo relativo verdadero, sino desde la base de la raíz web.

Referencia: Wordpress Codex

Estoy de acuerdo con Rup. Supongo que la razón principal es evitar confusiones en rutas relativas. Creo que WordPress puede funcionar desde cero con rutas relativas, pero el problema puede surgir cuando se usan múltiples complementos, cómo se configura el tema, etc.

Una vez usé este complemento para rutas relativas, cuando trabajaba en servidores de prueba:

URL relativas a la raíz
Convierte todas las URL en URL relativas a la raíz para alojar el mismo sitio en varias direcciones IP, facilitar la migración de la producción y realizar mejores pruebas de dispositivos móviles.

Lo resolví en mi sitio haciendo esto en 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);

}

Tomé parte de un complemento, lo corté en pedazos y lo hice. Reemplazó TODOS los enlaces en mi sitio (menús, css, scripts, etc.) y todo estaba funcionando.

En Configuración => Medios, hay una opción para 'Ruta URL completa para archivos'. Si establece esto en la ruta del directorio de medios predeterminado '/ wp-content / uploads' en lugar de en blanco, insertará rutas relativas, por ejemplo, '/wp-content/uploads/2020/06/document.pdf'.

No estoy seguro si hace que todos los enlaces sean relativos, por ejemplo, a publicaciones, pero al menos maneja los medios, que probablemente es lo que preocupa a la mayoría de la gente.

debe usar get_home_url (), entonces sus enlaces son absolutos, pero no afecta si cambia la URL del sitio

Lo que creo que haces es mientras cambias los nombres de dominio, el archivo de volcado de SQL que tienes puedes reemplazar todas las instancias del nombre de dominio antiguo por uno nuevo. Esta es la única opción disponible, ya que no hay complementos que lo ayuden a hacer esto.

Esta es la forma más rápida ...

Hay una manera facil

En lugar de /pagename/usar index.php/pagename/o si no usa enlaces permanentes, haga lo siguiente:

Enviar

index.php?p=123

Página

index.php?page_id=42

Categoría

index.php?cat=7

Más información aquí: http://codex.wordpress.org/Linking_Posts_Pages_and_Categories