повне г, повне г,, показали, від, номер, XNUMX плагін перенаправлення побудований для WordPress - це фантастичний засіб організації та управління переспрямуваннями. Я використовую його на цьому сайті та організував свої групи переспрямувань для оновлених публікацій, партнерських посилань, завантажень тощо.
Однак я зіткнувся з унікальною проблемою, коли у мене встановлено зворотний проксі-сервер для клієнта, де WordPress працює на шляху ... але не кореневого сайту. Основний сайт працює на IIS в Azure. IIS може керувати переспрямуваннями так само, як може будь-який веб-сервер, але проблема полягає в тому, що цьому клієнту потрібно буде включити управління переспрямуванням у свій процес розробки - і він уже зайнятий.
Справа в тому, що типовий стиль перенаправлення у стилі .htaccess не є можливим ... ми повинні фактично писати переспрямування у PHP. Як рішення, ми перенаправляємо запити на WordPress, щоб визначити, чи є перенаправлення на старих шляхах.
У header.php файлу нашої дочірньої теми, ми маємо функцію:
function my_redirect ($oldlink, $newlink, $redirecttype = 301) {
$olduri = $_SERVER['REQUEST_URI'];
if(strpos($olduri, $oldlink) !== false) {
$newuri = str_replace($oldlink, $newlink, $olduri);
wp_redirect( $newuri, $redirecttype );
exit;
}
}
Ми не турбувались розміщенням функції у functions.php просто тому, що це вплине лише на файл заголовка. Потім у файлі header.php ми просто маємо список усіх переспрямувань:
my_redirect('lesson_plans', 'lesson-plan');
my_redirect('resources/lesson-plans/26351', 'lesson-plan/tints-and-shades');
my_redirect('about/about', 'about/company/');
За допомогою цієї функції ви також можете вказати, на який тип перенаправлення ви хочете встановити запит заголовка, ми щойно встановили за замовчуванням переспрямування 301, щоб пошукові системи його виконали.