Docker/WordPress в подкаталоге перенаправляет на корневой каталог.

Вопрос или проблема

Я установил WordPress+OpenLiteSpeed в Docker с помощью этого скрипта, адаптировав его под свои нужды.

Я размещаю блог в подкаталоге /blog.

Я добавил это в wp-config.php

define('WP_HOME', 'https://www.shamanicattraction.com/blog/');
define('WP_SITEURL', 'https://www.shamanicattraction.com/blog/');

Главная страница работает! Административная панель перенаправляет на корень.

Развертывание наконец-то работает. Выяснил, что могу исправить административную панель, добавив это в wp-config.php

$_SERVER['REQUEST_URI'] = str_replace("/wp-admin/", "/blog/wp-admin/",  $_SERVER['REQUEST_URI']);

Отлично, корень и административная панель работают… но каждая другая страница возвращает ошибку 404 от OpenLiteSpeed.

Вот мой конфигурационный файл nginx.

server {
    listen        80;
    listen        [::]:80;
    server_name   shamanicattraction.com;
    return 301 $scheme://www.shamanicattraction.com$request_uri;

    listen [::]:443 ssl; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/www.shamanicattraction.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/www.shamanicattraction.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    server_name   www.shamanicattraction.com;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        proxy_pass         http://127.0.0.1:5004/;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection $connection_upgrade;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }

    location /blog/ {
    proxy_pass         http://127.0.0.1:5080/;
        proxy_set_header   Host $host;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }

    listen [::]:443 ssl; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/www.shamanicattraction.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/www.shamanicattraction.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    if ($host = www.shamanicattraction.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    listen        80;
    listen        [::]:80;
    server_name   www.shamanicattraction.com;
    return 404; # managed by Certbot
}

OpenLiteSpeed, работающий в Docker на порту 5080, имеет автоматическую конфигурацию по умолчанию, вот нижняя часть конфигурационного файла

vhTemplate docker {
    templateFile            conf/templates/docker.conf
    listeners               HTTP, HTTPS
    member shamanicattraction.com {
        vhDomain              shamanicattraction.com,www.shamanicattraction.com
    }
    note                    docker

    member localhost {
        vhDomain              localhost, *
    }
}

Не могу понять, в чем дело. Почему он продолжает перенаправлять на корень и ломать URL? В WordPress вкладки “Общие” и “Постоянные ссылки” выглядят в порядке.

server {
    listen 80;
    listen [::]:80;
    server_name shamanicattraction.com;
    return 301 $scheme://www.shamanicattraction.com$request_uri;
}

server {
    server_name www.shamanicattraction.com;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        proxy_pass         http://127.0.0.1:5004/;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection $connection_upgrade;
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
    }

    location /blog {
        proxy_pass         http://127.0.0.1:5080/;
        proxy_set_header   Host $host;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # Переписываем URI для обработки подкаталога WordPress
        rewrite ^/blog/(.*)$ /$1 break;
    }

    listen [::]:443 ssl;
    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/www.shamanicattraction.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.shamanicattraction.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}

# Этот блок серверов для перенаправления с HTTP на HTTPS
server {
    if ($host = www.shamanicattraction.com) {
        return 301 https://$host$request_uri;
    } 

    listen 80;
    listen [::]:80;
    server_name www.shamanicattraction.com;
    return 404; # managed by Certbot
}

Ответ или решение

Для понимания проблемы, связанной с использованием Docker и WordPress в подкаталоге, нужно разобрать ключевые элементы взаимодействия между ними. Ситуация, описанная вами, касается реализации WordPress в подкаталоге /blog и возникающих при этом проблем с перенаправлениями, когда страницы продолжают перенаправляться на корневой домен и выдают ошибки 404. Рассмотрим теорию, примеры и решения этой проблемы более подробно.

Теория: Основы конфигурации веб-серверов

Когда мы развертываем WordPress в подкаталоге, необходимо убедиться, что все части серверной конфигурации правильно настроены для передачи запросов и их обработки. Это включает в себя настройку таких серверов, как Nginx, для правильной маршрутизации запросов к OpenLiteSpeed, который обслуживает WordPress.

Основные компоненты:

  1. Nginx как обратный прокси: Нужен для маршрутизации исходящих и входящих запросов. Он должен правильно пересылать запросы к OpenLiteSpeed, который выполняет PHP-код WordPress.
  2. OpenLiteSpeed: Служит для выполнения запросов WordPress и обработки PHP. Он должен быть настроен для функционирования WordPress в указанном подкаталоге.
  3. WordPress: Требуется корректное указание URL в конфигурационных файлах, таких как wp-config.php, для работы с подкаталогами.

Пример: Разбор текущей конфигурации

Взглянем на предоставленную конфигурацию и разбираемся, почему она может не работать должным образом:

  1. Конфигурация wp-config.php:

    define('WP_HOME', 'https://www.shamanicattraction.com/blog/');
    define('WP_SITEURL', 'https://www.shamanicattraction.com/blog/');

    Эти строчки задают основные URL вашего сайта правильно, указывая на подкаталог.

  2. Nginx конфигурация:

    location /blog/ {
        proxy_pass         http://127.0.0.1:5080/;
        proxy_set_header   Host $host;
        proxy_set_header   X-Forwarded-Proto $scheme;
        rewrite ^/blog/(.*)$ /$1 break;
    }

    Здесь важна строка с rewrite, так как она удаляет /blog из URL, позволяя серверу OpenLiteSpeed правильно обрабатывать запросы.

  3. OpenLiteSpeed конфигурация:
    Решение требует, чтобы Litespeed понимал, что WordPress работает в подкаталоге, и правильно маршрутизировал запросы. Если в шаблоне виртуального хоста нет специальных правил под подкаталог, это может вызывать ошибки обработки.

Применение: Исправление конфигурации

Для устранения ошибки 404 и неправильно работающих редиректов выполните следующие действия:

  1. Анализ OpenLiteSpeed Конфигурации: Проверьте настройки, чтобы убедиться, что WordPress понимает, что он находится в подкаталоге. Возможно, потребуются правки .htaccess для WordPress.

  2. Тестирование и отладка:

    • Проверьте /etc/nginx/sites-available/ для любой дополнительной конфигурации, которая может влиять на поведение сервера.
    • Убедитесь, что SSL сертификаты корректно настроены.
    • Протестируйте разные URL, чтобы увидеть, где именно система ломается, используя инструменты отладки в браузере, такие как Network в DevTools.
  3. WordPress настройки:

    • В админке WordPress проверьте настройки URL в разделе «Общие» и «Постоянные ссылки». Они должны совпадать с теми, что находятся в wp-config.php.
  4. Логирование и Мониторинг: Use логи для Nginx и OpenLiteSpeed для мониторинга ошибок в процессе прохождения запросов, примените комплексную настройку логирования, чтобы выявлять точки сбоя.

Заключительные Соображения

Проблемы с перенаправлениями и ошибками 404 являются частыми при использовании подкаталогов в Docker и требуют внимательного подхода к конфигурации серверов и WordPress. Ключ к успешному решению проблемы – в комплексном и междисциплинарном понимании взаимодействия между различными компонентами системы и их правильной настройке. Уделите особое внимание деталям и регулярно тестируйте изменения для гарантии стабильности и функциональности вашей установки.

Оцените материал
Добавить комментарий

Капча загружается...