Вопрос или проблема
Я использую необычную настройку для размещения 3 установок WordPress на Linux CentOS 8.
Спереди у меня HAProxy (для выгрузки TLS), затем я настроил Jetty для FastCGI и php-fpm, и наконец WordPress.
Я использую WordPress вокруг словесной игры, написанной на Pixi.js.
На протяжении нескольких лет я использовал 3 разных IP-адреса и 3 разных доменных имени для 3 языковых версий моей игры: en, de, ru.
Однако моя словесная игра не имеет успеха, поэтому я решил отказаться от дополнительных доменных имен и IP-адресов и просто использовать папки для размещения игры:
- wordsbyfarber.com/en
- wordsbyfarber.com/de
- wordsbyfarber.com/ru
Это работало хорошо, я не использую мультисайт, и я установил
define('WP_HOME', 'https://wordsbyfarber.com/en');
define('WP_SITEURL', 'https://wordsbyfarber.com/en');
в en/wp-config.php (так же для de и ru) и также в панели управления:
И уже можно увидеть мою проблему на скриншоте выше:
Хотя пользовательские сайты работают нормально, панель администратора на /en/wp-admin/
сразу перенаправляется на /wp-admin
, что неправильно, так как я не использую мультисайт.
Я пытался решить проблему самостоятельно и много искал в документации и прочих источниках.
Также мне было интересно, кто делает перенаправление – JS или PHP?
Мне кажется, что это делается PHP-кодом WordPress, который по какой-то причине отправляет новый заголовок Location
:
Как видно на скриншоте выше, при использовании wget
— по какой-то причине WordPress удаляет строку /en
из пути /en/wp-admin
и перенаправляет на новое местоположение.
Почему это происходит и как это остановить?
Я пытался искать в исходном коде WordPress с помощью:
find ./en/ -iname \*.php| xargs grep -riw redirect_to
но пока не смог найти причину.
ОБНОВЛЕНИЕ: У меня нет файла .htaccess, так как я использую Jetty с конфигурацией для FastCGI с следующим конфигурационным файлом:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN"
"http://www.eclipse.org/jetty/configure_9_3.dtd">
<Configure class="org.eclipse.jetty.servlet.ServletContextHandler">
<New id="root" class="java.lang.String">
<Arg>/var/www/html/wordsbyfarber.com/en</Arg>
</New>
<Set name="contextPath">/en</Set>
<Set name="resourceBase"><Ref refid="root" /></Set>
<Set name="welcomeFiles">
<Array type="string">
<Item>index.php</Item>
<Item>index.html</Item>
</Array>
</Set>
<Call name="addFilter">
<Arg>org.eclipse.jetty.fcgi.server.proxy.TryFilesFilter</Arg>
<Arg>/*</Arg>
<Arg>
<Call name="of" class="java.util.EnumSet">
<Arg><Get name="REQUEST" class="javax.servlet.DispatcherType" /></Arg>
</Call>
</Arg>
<Call name="setInitParameter">
<Arg>files</Arg>
<Arg>$path /index.php?p=$path</Arg>
</Call>
</Call>
<Call name="addServlet">
<Arg>
<New class="org.eclipse.jetty.servlet.ServletHolder">
<Arg>default</Arg>
<Arg>
<Call name="forName" class="java.lang.Class">
<Arg>org.eclipse.jetty.servlet.DefaultServlet</Arg>
</Call>
</Arg>
<Call name="setInitParameter">
<Arg>dirAllowed</Arg>
<Arg>false</Arg>
</Call>
<Call name="setInitParameter">
<Arg>gzip</Arg>
<Arg>true</Arg>
</Call>
</New>
</Arg>
<Arg>/</Arg>
</Call>
<Call name="addServlet">
<Arg>org.eclipse.jetty.fcgi.server.proxy.FastCGIProxyServlet</Arg>
<Arg>*.php</Arg>
<Call name="setInitParameter">
<Arg>proxyTo</Arg>
<Arg>http://localhost:9000</Arg>
</Call>
<Call name="setInitParameter">
<Arg>prefix</Arg>
<Arg>/</Arg>
</Call>
<Call name="setInitParameter">
<Arg>scriptRoot</Arg>
<Arg><Ref refid="root" /></Arg>
</Call>
<Call name="setInitParameter">
<Arg>scriptPattern</Arg>
<Arg>(.+?\\.php)</Arg>
</Call>
</Call>
</Configure>
У вас случайно не установлен PHPMyAdmin или Adminer или аналогичный инструмент на веб-сервере? Вы могли бы легко выполнить поиск и замену. Я бы порекомендовал сначала выполнить поиск и убедиться, что все совпадающие записи имеют смысл. Затем выполните поиск и замену.
Как упомянула @WebElaine, WP обычно сохраняет URL-адреса в нескольких местах, включая некоторые плагины, поэтому это не всегда однозначный ответ.
Эти URL-адреса хранятся в таблице [prefix]_options
(обычно wp_options).
Но как только вы определите WP_HOME
и SITE_URL
в конфигурационном файле, эти параметры автоматически отключаются в админке.
На мой взгляд, эта проблема не связана с WordPress, скорее всего, это связано с вашей конфигурацией Jetty для FastCGI.
Вы можете попытаться “заставить” WordPress использовать вручную определенный URL сайта. Добавьте этот код в ваш файл wp-config.php
. Этот метод не является наилучшим решением, но в вашем случае это экстренная мера 😀
define('WP_HOME', 'https://yourwebsite.com/en');
define('WP_SITEURL', 'https://yourwebsite.com/en');
Согласно странице WordPress “Changing The Site URL”
Это не обязательно самое лучшее исправление, оно просто кодирует значения в сам сайт. Вы больше не сможете редактировать их на странице общих настроек, используя этот метод.
.
Ответ или решение
Ваш вопрос касается перенаправления панели администратора WordPress с /en/wp-admin/
на /wp-admin/
, и это происходит в довольно сложной конфигурации серверной архитектуры с применением HAProxy и Jetty.
Ваша конфигурация включает в себя HAProxy для разгрузки TLS, Jetty, настроенный на использование FastCGI, и php-fpm для обработки PHP сценариев WordPress. Такое сочетание технологий может создавать нестандартные ситуации, особенно при отсутствии файла .htaccess
, который обычно управляет перенаправлениями в Apache. Поскольку вы используете Jetty, перенаправление может быть инициировано настройками FastCGI в Jetty.
Потенциальные причины и решения проблемы
-
Конфигурация WordPress:
- Вы указали, что установили
WP_HOME
иWP_SITEURL
вwp-config.php
. Убедитесь, что эти параметры правильно настроены в каждом инстансе для всех языков:https://wordsbyfarber.com/en
,https://wordsbyfarber.com/de
,https://wordsbyfarber.com/ru
.
- Вы указали, что установили
-
Jetty и FastCGI:
- Проверьте конфигурацию файла Jetty. Возможно, проблема в параметре
contextPath
, который может не учитывать необходимые подкаталоги. Убедитесь, что все языковые подкаталоги правильно указаны и настроены в конфигурации Jetty. - Параметры внутри
FastCGIProxyServlet
, такие какproxyTo
иscriptRoot
, также должны правильно отражать структуру ваших директорий и подкаталогов.
- Проверьте конфигурацию файла Jetty. Возможно, проблема в параметре
-
База данных WordPress:
- Убедитесь, что в базе данных, в таблице
wp_options
, нет устаревших записей или ссылок, которые могут противоречить новым настройкам. - Инструменты, такие как PHPMyAdmin, могут помочь провести поиск и заменить некорректные ссылки. Просто удостоверьтесь, что все изменения записей соответствуют вашему текущему URL.
- Убедитесь, что в базе данных, в таблице
-
Диагностика:
- Используйте инструменты отладки, такие как подключение логов на уровне Jetty и WordPress, чтобы отследить причины перенаправления. Это подтвердит, что перенаправление идет от Jetty, а не от WordPress или PHP кода.
- Проверьте доступность всех файлов, которые могут повлиять на выполнение PHP-кода, включая разрешения на выполнение скриптов и доступ к директориям.
Основные шаги
- Перепроверьте всё параметризованные пути и URL в вашей конфигурации.
- Используйте средства настройки и мониторинга Jetty для обнаружения некорректных настроек.
- Проверьте базу данных на предмет некорректных или устаревших записей URL.
Таким образом, подход к решению проблемы требует тщательного анализа конфигураций и согласования всех систем. Данный подход позволит вам избавиться от зависимости от нескольких доменных имен и настроить ваш сервер для корректной работы с подкаталогами.
Если необходимо, привлеките специалиста по Jetty, так как проблемы с конфигурацией FastCGI могут быть достаточно специфичными и требовать детального понимания Jetty и его взаимодействия с PHP.
Надеюсь, это поможет вам устранить проблему с перенаправлением и добиться корректной работы вашей панели администратора в WordPress.