Відносні URL-адреси в WordPress

У WordPress мені завжди було страшно, що зображення, файли, посилання тощо вставляються в WordPress з абсолютною URL-адресою замість відносної URL-адреси. Відносна URL-адреса набагато зручніша для перемикання доменних імен, зміни між http та https тощо. Сьогодні я виявив, що якщо ви визначаєте WP_CONTENT_URL з відносною URL-адресою, тоді, коли ви вставляєте файли в повідомлення, вони використовують відносний URL для src замість абсолютного URL. . Просто те, чого я завжди хотів! Але офіційна документація WordPress говорить, що ви повинні використовувати повний URI, якщо ви визначаєте WP_CONTENT_URL.

WordPress кодекс говорить :

Встановіть WP_CONTENT_URL на повний URI цього каталогу (відсутній кінець косої риси), наприклад

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

Здається, все працює добре, коли я використовую відносну URL-адресу, наприклад

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

Але чи є якась проблема із використанням відносного URI? Я просто думаю, що в WordPress повинна бути причина, що вона повинна визначатися з повним URI.

Я думаю, що це питання, на яке міг / повинен відповісти лише розробник ядра. Я дослідив і знайшов основний квиток № 17048: URL-адреси, що надходять до браузера, мають бути кореневими . Де ми можемо знайти причини, пояснені Ендрю Начіним, головним розробником ядра. Він також посилається на цю тему [wp-хакери] . На обох цих посиланнях це ключові цитати про те, чому WP не використовує відносні URL-адреси:

Основний квиток:

• Кореневі URL-адреси насправді не є правильними. /path/може бути не WordPress, це може бути поза встановленням. Тож насправді це не сильно відрізняється від абсолютної URL-адреси.

• Будь-які відносні URL-адреси також значно ускладнюють виконання перетворень під час переміщення встановлення. У більшості ситуацій пошук-заміна буде необхідним, а наявність абсолютної URL-адреси з цих причин іронічно більш портативна.

• абсолютні URL-адреси потрібні в багатьох інших місцях. Необхідність додавати ці умови умовно додасть до обробки, а також введе потенційні помилки (та несумісність із плагінами).

[wp-хакери] нитка

• Щодо того, я не впевнений, оскільки WordPress часто знаходиться у підкаталозі, а це означає, що нам завжди потрібно буде обробляти вміст, а потім додавати його в іншій частині шляху. Це вводить накладні витрати.

• Майте на увазі, що існують два типи відносних URL-адрес із провідною косою рисою та без неї. В обох є застереження, які унеможливлюють належне виконання.

• WordPress повинен (і дійсно) зберігає абсолютні URL-адреси. Це не вимагає попередньої обробки контенту, ніяких накладних витрат, неясності. Якщо вам потрібно переїхати, це глобальна знахідка-заміна в базі даних.

І, в особистому записі, не раз я знаходив тему та плагіни, кодовані неправильно, які просто ламаються, коли WP_CONTENT_URLвизначено.
Вони не знають, що це можна встановити і припускати, що це правда: WP.URL / wp-content / WhatEver , і це не завжди так. І щось поламає по дорозі.

Плагін Відносні URL (пов'язані в edse Відповідь «и ), застосовує функцію wp_make_link_relativeв серії фільтрів в гаку дійtemplate_redirect . Це досить простий код і здається приємним варіантом.

<?php wp_make_link_relative( $link ) ?>

Перетворення повних URL-адрес у відносні шляхи.

Вилучає протоколи http або https та домен. Зберігає шлях '/' на початку, тому це не справжнє відносне посилання, а від бази кореневих веб-сторінок.

Довідка: Wordpress Codex

Я згоден з Рупом. Гадаю, головна причина - уникнути плутанини щодо відносних шляхів. Я думаю, що wordpress може працювати з нуля з відносними шляхами, але проблема може виникнути при використанні декількох плагінів, налаштування теми тощо.

Я колись використовував цей плагін для відносних шляхів, коли працював на тестуванні серверів:

Кореневі відносні URL-адреси
Перетворює всі URL-адреси у відносні кореневі URL-адреси для розміщення одного і того ж сайту на декількох IP-адресах, легшої міграції виробництва та кращого тестування мобільних пристроїв.

Я вирішив це на своєму веб-сайті, зробивши це у function.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);

}

Я взяв частину одного плагіна, розрізав його на шматочки і зробив це. Він замінив ВСІ посилання на моєму сайті (меню, css, скрипти тощо), і все працювало.

У розділі Налаштування => Медіа є опція "Повний URL-шлях для файлів". Якщо встановити цей шлях до медіа-каталогу за замовчуванням '/ wp-content / uploads' замість порожнього, він буде вставляти відносні шляхи, наприклад '/wp-content/uploads/2020/06/document.pdf'.

Я не впевнений, чи це робить усі посилання відносними, наприклад, до публікацій, але, принаймні, він обробляє засоби масової інформації, що, мабуть, саме це хвилює більшість людей.

слід використовувати get_home_url (), тоді ваші посилання абсолютні, але це не впливає на зміну URL-адреси сайту

Я думаю, що ви робите, коли ви змінюєте доменні імена, файли дамп-файлу sql, які у вас є, ви можете замінити всі екземпляри старого доменного імені на нові. Це лише варіант, оскільки немає плагінів, які допоможуть вам це зробити.

Це найшвидший спосіб ..

Є простий спосіб

Замість /pagename/використання index.php/pagename/або якщо ви не використовуєте постійні посилання, виконайте наступне:

Опублікувати

index.php?p=123

Сторінка

index.php?page_id=42

Категорія

index.php?cat=7

Більше інформації тут: http://codex.wordpress.org/Linking_Posts_Pages_and_Ca категории