dinamica - URL relativas en Wordpress

url dinamica wordpress

Question

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 los nombres de dominio, cambiar entre http y https, etc. Hoy descubrí que si defines WP_CONTENT_URL con una URL relativa, cuando insertas archivos en las publicaciones usan la url relativa para el src en lugar de la url absoluta . ¡Justo lo que siempre he querido! Pero la documentación oficial de Wordpress dice que debe usar un URI completo si está definiendo WP_CONTENT_URL.

Wordpress codex dice :

Establezca WP_CONTENT_URL en el URI completo de este directorio (sin barra inclinada), 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.

Answer 1

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

Boleto principal:

• 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 hace que sea significativamente más difícil realizar transformaciones cuando se mueve la instalación. El reemplazo de búsqueda va a ser necesario 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. Necesitar agregar esto en forma condicional se agregará al procesamiento, así como también introducirá posibles errores (e incompatibilidades con los complementos).

[wp-hackers] hilo

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

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

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

Y, en una nota personal, más de una vez encontré el tema y los complementos mal codificados que simplemente se rompen cuando WP_CONTENT_URL está definido.
No saben que esto se puede configurar y suponen que esto es cierto: WP.URL / wp-content / WhatEver , y no siempre es así. Y algo se romperá en el camino.

Las wordpress.org/plugins/relative-url complementos (vinculadas en la respuesta de edse ) aplican la función wp_make_link_relative en una serie de filtros en la acción hook template_redirect . Es un código bastante simple y parece una buena opción.

Answer 2

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

Una vez utilicé este complemento para rutas relativas, cuando trabajo en servidores de prueba:

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

Answer 3

Lo que creo que haces es cuando cambias los nombres de dominio, el archivo de volcado sql que tienes puedes reemplazar todas las instancias del antiguo nombre de dominio 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 ...

Answer 4

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. Sustituyó TODOS los enlaces en mi sitio (menús, CSS, scripts, etc.) y todo estaba funcionando.

Answer 5

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

Answer 6

Hay una manera fácil

En lugar de /pagename/ use index.php/pagename/ o si no usa index.php/pagename/ 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

Answer 7

<?php wp_make_link_relative( $link ) ?>

Convierta rutas de URL completas a rutas relativas.

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

Referencia: Wordpress Codex