Ошибка 404 при обслуживании WordPress на подкаталоге с помощью NGINX, как исправить?

Я бы хотел размещать проверочные ветки для staging, чтобы тестировать и получать отзывы перед публикацией на production. Я пытался следовать некоторой документации, предоставленной в интернете, такой как рецепты для NGINX ( https://www.nginx.com/resources/wiki/start/topics/recipes/wordpress/ ), безуспешно! Так как это исправить?

Шаблон для проверочных веток — /review-xxxxx или /review-xx_x-xxx. Я настроил конвейер развертывания для автоматической публикации на AWS ECS для веток review-*, и я хотел бы, чтобы они оставались приватными только для тестов и получения отзывов.

Я жестко прописал /review-ci, чтобы избежать необходимости решать проблемы с регулярными выражениями и упростить начало работы. Вы найдете путь /review-ci в файле конфигурации NGINX, чтобы было ясно, какова цель.

Мой файл конфигурации NGINX выглядит следующим образом:

server {
    listen 80;
    server_name httpwordpress.docker.localhost;

    # Логи
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    # Настройки расположения по умолчанию
    location / {
        index index.php;
    }

    location /review-ci {
        index  index.php;
        try_files $uri $uri/ /review-ci/index.php?$args;
    }

    # Передача PHP скриптов серверу FastCGI
    location ~ \.php$ {

        fastcgi_split_path_info ^(.+\.php)(/.+)$;

        fastcgi_pass php-fpm:9000;
        fastcgi_index   index.php;
        fastcgi_param   SCRIPT_FILENAME 
        $document_root$fastcgi_script_name;
        include         fastcgi_params;
    }


}

У меня активны постоянные ссылки, и я должен иметь возможность запросить foobar.com/review-ci/wp-admin и увидеть экран входа.

Когда я выполняю curl http://httpwordpress.docker.localhost/review-ci/wp-admin, я получаю:

404 page not found

Я также использую https://github.com/wp-graphql/wp-graphql, что означает, что адрес http://httpwordpress.docker.localhost/review-ci/graphql должен возвращать данные, но вместо этого я получаю 404.

Это небольшой шаг перед введением регулярного выражения, так как я хотел бы развернуть приложение на AWS ECS. И я сразу заметил, что это не сработало с моей первоначальной настройкой, которую я раскрыл и попросил помощи на serverfault ( https://serverfault.com/questions/988035/nginx-location-regex-for-prefixed-paths-failure ).

Между тем, просто полагаться на hostname и корневой путь, как показано ниже, хорошо работает в среде разработки. Но, к сожалению, для staging могут быть одновременные версии, которые содержат отдельные функции или требования, не готовые для публикации, и они сохраняются отдельно из-за соображений или имени ветки git, перед которым стоит review-, если требуется развернуть и иметь staging url.

server {
    listen 80;
    server_name httpwordpress.docker.localhost;

    root /var/www/html;
    index index.php;

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    client_max_body_size 200m;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass php-fpm:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        client_max_body_size 200m;
    }

}

Кто-нибудь знает, как это исправить?

Спасибо за внимание и буду признателен за любые советы или подсказки!

Вы можете попробовать

location /review-ci {
    index  index.php;
    try_files $uri $uri/ /review-ci/index.php;
}

Вопрос выше касается /path-segment, а не /sub-directory или, как обычно называется в сообществе WP, /sub-folder. После большого числа попыток я бы советовал не пытаться создавать /routes, а вместо этого делать хостинг файлов в /sub-directory, чтобы упростить процесс. Решение представлено ниже.

Поскольку то, что я пытаюсь сделать, не соответствует каталогу в www $HOME, это сложно. Как и большинство примеров, которые мы находим в интернете для “WordPress в подкаталоге”, демонстрируют, что общепринятая практика состоит в хранении исходных файлов wp в месте, относительном к www $HOME. По этой причине я отказался от идеи создания /route (внимание, это не подкаталог, он не соответствует директории, например, www.foobar.com/review-foobar/wp-admin должно быть /var/www/home/, а не /var/www/home/review-foobar/wp-admin); я тестировал и видел, что это возможно сделать с использованием регулярных выражений и групп захвата, и NGINX alias; где я передавал бы сегмент wp-admin к alias /var/www/home/wp-admin вместо директив NGINX try_files или root. Возможно, это слишком сложно для понимания здесь, но смысл в том, что лучше придерживаться общепринятой практики и размещать файлы в подкаталоге, относительном к пути $HOME, чтобы избежать регулярных выражений и групп захвата, резервных сценариев и т.д.

Рабочая версия для общепринятой практики:

    server {
        listen PORT;
        server_name httpwordpress.docker.localhost;

        root /var/www/html;
        index index.html index.htm;

        location / {
        try_files $uri $uri/ =404;
        }

        location /review-staging {
            try_files $uri $uri/ /review-staging/index.php?$args;
        }

        location ~ \.php$ {
            try_files $uri =404;
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_pass FPM_HOSTNAME:9000;
            fastcgi_index index.php;
        }
    }

Таким образом, сегмент /review-staging — это директория в $HOME, например, /var/www/html, где исходные файлы WP находятся в /var/www/html/review-staging. Помните, что это не то, о чем я спрашивал, но, похоже, это общепринятая практика здесь и она помогает облегчить некоторые затруднения при настройке.