permalinks - NGINX serve Wordpress from sub-path fails with 404, how to fix?

admin管理员组

文章数量:1122846

I'd like host review branches for staging, to test and get feedback before publishing to production. I tried to follow some documentation provided online such as the NGINX recipes ( / ) without success! So, how to fix it?

The pattern for the review branches are /review-xxxxx or /review-xx_x-xxx. As I have setup the Deployment pipeline to trigger publishing to AWS ECS for review-* branches and that's where I'd like to keep it private for tests and feedback only.

I've hard typed /review-ci to avoid having to troubleshoot any regex pattern issues and keep it simple to start with. So, you'll find the /review-ci path in the NGINX Conf file, so that it's clear what the goal is.

My NGINX conf file looks like:

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

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

    # Default location settings
    location / {
        index index.php;
    }

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

    # Pass the PHP scripts to FastCGI server
    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;
    }


}

I have perm links active and I should be able to request foobar/review-ci/wp-admin and see the login screen.

When I do curl /review-ci/wp-admin, I get:

404 page not found

I'm also using , which means that the address /review-ci/graphql should return a data response, but instead, I get 404.

This is a small step before I introduce a regex pattern, as I'd like to deploy the application to AWS ECS. And I noticed straight away that this failed with my original setup which I exposed and requested for help in serverfault ( ).

Meanwhile, simply relying on the hostname and ROOT path as seen bellow works fine in the development environment. But unfortunately, staging might have concurrent versions that have separate features or requirements not ready for publishing and it's kept separate by concern or "git branch name" prefixed by review- if required to deploy and have a 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;
    }

}

Does anyone know how to fix this?

Thanks for looking and any feedback or hint is appreciated!

I'd like host review branches for staging, to test and get feedback before publishing to production. I tried to follow some documentation provided online such as the NGINX recipes ( https://www.nginx.com/resources/wiki/start/topics/recipes/wordpress/ ) without success! So, how to fix it?

The pattern for the review branches are /review-xxxxx or /review-xx_x-xxx. As I have setup the Deployment pipeline to trigger publishing to AWS ECS for review-* branches and that's where I'd like to keep it private for tests and feedback only.

I've hard typed /review-ci to avoid having to troubleshoot any regex pattern issues and keep it simple to start with. So, you'll find the /review-ci path in the NGINX Conf file, so that it's clear what the goal is.

My NGINX conf file looks like:

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

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

    # Default location settings
    location / {
        index index.php;
    }

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

    # Pass the PHP scripts to FastCGI server
    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;
    }


}

I have perm links active and I should be able to request foobar.com/review-ci/wp-admin and see the login screen.

When I do curl http://httpwordpress.docker.localhost/review-ci/wp-admin, I get:

404 page not found

I'm also using https://github.com/wp-graphql/wp-graphql, which means that the address http://httpwordpress.docker.localhost/review-ci/graphql should return a data response, but instead, I get 404.

This is a small step before I introduce a regex pattern, as I'd like to deploy the application to AWS ECS. And I noticed straight away that this failed with my original setup which I exposed and requested for help in serverfault ( https://serverfault.com/questions/988035/nginx-location-regex-for-prefixed-paths-failure ).

Meanwhile, simply relying on the hostname and ROOT path as seen bellow works fine in the development environment. But unfortunately, staging might have concurrent versions that have separate features or requirements not ready for publishing and it's kept separate by concern or "git branch name" prefixed by review- if required to deploy and have a 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;
    }

}

Does anyone know how to fix this?

Thanks for looking and any feedback or hint is appreciated!

• permalinks
• nginx

Share Improve this question edited Oct 15, 2019 at 14:35 punkbit asked Oct 15, 2019 at 11:22 punkbitpunkbit 16111 silver badge99 bronze badges

Add a comment  | 

2 Answers 2

Sorted by: Reset to default 0

You can try

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

The question above is about /path-segment and not /sub-directory or as commonly called in the WP community /sub-folder. After a lot of trying, I'd suggest not to attempt to create the /routes but instead do the file hosting in a /sub-directory to ease the process. The solution follows.

Since what I'm attempting to do does not map to a directory in the www $HOME, it's tricky to do. Like most examples, we find online for the use case "Wordpress in a subfolder" demonstrate, the common practice is to have the wp source files stored in a location relative to the www $HOME. For that reason, I've quit the idea about creating a /route (attention it's not a subfolder, it does not map to a directory, for example, www.foobar.com/review-foobar/wp-admin should be /var/www/home/ and not /var/www/home/review-foobar/wp-admin); I've tested and seen that it's possible to do with regex and capture groups, and NGINX alias; Where I'd pass the group wp-admin segment part to the alias /var/www/home/wp-admin instead of the NGINX try_files or root directives. Maybe this is a bit too much to understand here, but the point is that it's best to stick with the common practice and host the files in a sub-directory relative to the $HOME path to avoid regex and capture groups, fallbacks etc.

A working version for the common practice is:

    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;
        }
    }

So, the /review-staging segment is a directory in $HOME, for example /var/www/html, where the source files for WP exist in /var/www/html/review-staging. Have in mind that this is not what I was asking for, but seems to be the common practice here and helps alleviate some pain when setting up.

本文标签： permalinksNGINX serve Wordpress from subpath fails with 404how to fix