wp-admin удаляет часть URL-адреса

Это выглядит так: wp-admin удаляет URL-адрес подпапки, но это не та же проблема, потому что часть подпапки не является подпапкой.

Я работаю над чистой виртуальной машиной в качестве хоста для контейнеров Docker. У меня есть докционированный WordPress, прослушивающий 8080 на виртуальной машине.

Я могу ударить WordPress по адресу http://<vm_ip>:8080 и установить просто отлично. Он берет меня на бэкэнд по адресу http://<vm_ip>:8080/wp-admin/ и все работает так, как ожидалось.

Теперь я хотел бы получить доступ к своему блогу по адресу http://<vm_ip>/blog/ поэтому я настроил nginx на виртуальную http://<vm_ip>/blog/ для прокси-запросов для каждого местоположения:

 upstream blog { server localhost:8080; } server { listen 80; server_name <vm_ip> localhost; location /blog/ { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Nginx-Proxy true; proxy_pass http://blog/; } } 

Это временно, поскольку nginx, вероятно, окажется докционированным, но для этого требуются пользовательские изображения; одна вещь за раз …
Также с фактическим именем домена я бы использовал субдомены, чтобы позаботиться о моей проблеме

Я попал в http://<vm_ip>/blog/ и я добираюсь до установки, но URL-адрес статических файлов http://<vm_ip>/blog/ : http://blog/wp-includes/css/... поэтому пользовательский интерфейс немного в сыром виде.

Я продолжаю установку. Он работает и переносит меня на http://<vm_ip>/blog/wp-admin/install.php?step=2 но кнопка Connect указывает на http://blog/wp-login.php поэтому я получаю 404.

Мне нужно внести изменения непосредственно в db: site_url и homewp_options ) установлены в http://blog поэтому я обновляю их как на http://<vm_ip>/blog .

Теперь интерфейс прекрасно работает, но у бэкэнда есть проблемы. Хотя большинство ссылок в порядке, некоторые кнопки «href пропустят часть блога : http://<vm_ip>/wp-admin так что мне это некуда.

Эти кнопки обычно имеют какую-то роль в представлении:

  • кнопка закрытия (вверху слева) в Appearance> Customize (указывает на http://wp-admin/ )
  • кнопку «Сохранить» в «Настройки»> «Общие» (отправить для <form action="options.php"> )

Что смешно, это непротиворечиво: кнопка «Сохранить» на странице «Добавить работы просто отлично» (хотя она выдает DOMException: не Failed to execute 'replaceState' on 'History': A history state object with URL 'http://blog/wp-admin/post.php?post=15&action=edit' cannot be created in a document with origin 'http://<vm_ip>' and URL 'http://<vm_ip>/blog/wp-admin/post.php?post=15&action=edit&message=1' )

Это что-то с параметрами site_url и home ?

Должен ли я искать шаблоны администратора для неполных URL-адресов?

Есть ли какой-нибудь крючок или фильтр, чтобы заставить правильный URL-адрес?

Solutions Collecting From Web of "wp-admin удаляет часть URL-адреса"

Я искал в шаблонах администратора. Кажется, что заполнители полагаются на функции wp_get_referer() и wp_get_raw_referer() которые используют $_SERVER["REQUEST_URI"] , $_SERVER['HTTP_REFERER'] и пользовательскую переменную wp, переданную в запросе: $_REQUEST['_wp_http_referer'] .

Поэтому WordPress строит некоторые URL-адреса (по-видимому, не все) на REQUEST_URI , то есть /wp-admin/whatever (в бэкэнд). Журналы показывают, что wp-admin/admin-ajax.php проходит регулярно, поэтому он попадает в правый URL.

Поэтому я предполагаю, что это связано с прохождением заголовков nginx.

(Ответы на мои вопросы касаются WP. Если мне нужно спросить на форуме nginx, я свяжу его здесь.)

Я пробовал различные перезаписи, и если, безрезультатно.

Но я закрываю: запросы http://<vm_ip>/wp-admin/... обрабатываются nginx на VM, в блоке / location, поэтому блок /blog/ location никогда не получает их, и они 'никогда не проксимитируется моему контейнеру WP.

Кажется, что try_files делает трюк, по крайней мере частично:

 location / { try_files $uri /blog$uri; } 

Это означает, что когда / location ловит запрос, он сначала попытается найти файл, соответствующий URI, затем соответствующий файлу /blog + URI, который отправляется в блок /blog/ location и мой контейнер WP.

Итак, теперь, отлично, когда я нажимаю на одну из неисправных кнопок, я перенаправляюсь в мой контейнер WP.

Победа! Еще не совсем так, потому что мне нужно снова войти в систему. И URL-адрес странный: http://<vm_ip>/blog/wp-login.php?redirect_to=http%3A%2F%2Fblog%2Fwp-admin%2Foptions-general.php&reauth=1 – если вы посмотрите на часть redirect_to , теперь это http://blog/wp-admin
Следовательно, когда я снова вхожу в систему, он берет меня в Личный кабинет.

Тем не менее, данные формы были сохранены в то же время. Да, прогресс!

Глубоко внизу, не должен ли WordPress всегда использовать одну и ту же логику для создания URL-адресов, используемых в бэкэнд и интерфейсе? Разве это не какая-то ошибка?