Как иметь WordPress в подпапке, но размещенным в другом месте?

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение

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

Я запускаю свой основной сайт на AWS, допустим, это https://example.com. Я хочу иметь блог на WordPress на https://example.com/blog. Однако, он будет размещаться в другом месте (Dreamhost, если быть точным).
Я попытался настроить это следующим образом:

создал поддомен blog.example.com на Dreamhost и установил WordPress;
установил WordPress Address (URL) на https://blog.example.com;
установил Site Address (URL) на https://example.com/blog;
настроил переадресацию nginx следующим образом:

        location /blog {
            proxy_pass https://blog.example.com/;
        }

Это в основном работает. https://example.com/blog открывается и имеет некоторые посты, например, https://example.com/blog/post1.

Однако, если я пытаюсь войти в админку WordPress по адресу https://example.com/blog/wp-admin, он перенаправляет меня на https://blog.example.com/wp-admin. Само по себе это не проблема, однако я не могу редактировать посты в этом режиме. Если я открываю редактор поста, изменяю что-то и пытаюсь сохранить, появляется сообщение об ошибке: “Обновление не удалось. Возможно, вы офлайн”.

Чтобы успешно отредактировать пост, мне приходится менять Site Address с https://example.com/blog на https://blog.example.com, редактировать пост, а затем менять обратно; но это, очевидно, не решение.

Есть идеи? Заранее благодарю!

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

Конфигурация вашего проекта, где основная часть сайта находится на AWS под доменом https://example.com, в то время как WordPress блог расположен в поддомене https://blog.example.com, хостинг которого осуществляется через Dreamhost, создает интересную техническую задачу. Вы стремитесь сделать так, чтобы блог был доступен по адресу https://example.com/blog, используя поддиректорию для видимого размещения, но фактически размещая его на другом сервере. Ниже я детализирую возможный подход к решению данной задачи, обращая внимание на аспекты, которые необходимо учесть, чтобы избежать описанных вами проблем.

Теория

Текущая проблема, с которой вы столкнулись — это несовпадение URL при доступе к административной части WordPress и проблемой сохранения постов, связанной с редиректами. Это обусловлено тем, как работают и взаимодействуют различные компоненты: ваш сервер Nginx, который выполняет проксирование запросов, конфигурации WordPress URL и самих хостинговых серверов.

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

Пример

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

Применение

Корректировка конфигурации Nginx:

Дополните конфигурацию следующими директивами для корректного проксирования заголовков:

location /blog {
  proxy_pass https://blog.example.com;
  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;
}

Точечная настройка WordPress:
- В wp-config.php убедитесь, что указаны следующие параметры, чтобы URL-адреса корректно переопределялись:
```
define('WP_HOME', 'https://example.com/blog');
define('WP_SITEURL', 'https://example.com/blog');
```
  Убедитесь, что WordPress понимает, под каким URL он должен быть доступен пользователям. Однако этим настройкам может потребоваться дополнительная корректировка в зависимости от применения SSL и настроек вашего прокси-сервера.
Адекватное редиректирование и передача заголовков:
- Использование таких плагинов, как WordPress Plugins для настройки CORS (Cross-Origin Resource Sharing), может помочь в настройке кросс-доменных запросов, если проблема все еще не решена.
- Убедитесь, что ваша SSL-конфигурация корректно обрабатывает переадресацию и проксирование HTTPS запросов.
Оценка и настройка безопасности:
- Не забывайте о безопасности и необходимой конфигурации для предотвращения уязвимостей, где заголовки HTTP могут иметь критическое значение для защиты контента и аутентификации.

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

Если все же проблемы сохраняются, стоит рассмотреть использование более продвинутых решений, имитирующих поведение CDN (Content Delivery Network) или соответствующих сервисов для балансировки нагрузки и проксирования, которые предоставляют автоматизированное управление маршризами и управление сниппетами конфигураций в случаях, подобных вашему.

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