Score:1

Issue with setting up nginx for wordpress

cn flag

I have a following wordpress nginx configuration in my /etc/nginx/sites-available/wordpress:

    index index.html index.htm index.nginx-debian.html;

    location / {
        proxy_pass http://nextjs;
        proxy_http_version 1.1;
            proxy_set_header X-Forwarded-Host $host;
            proxy_set_header X-Forwarded-Server $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;
            proxy_set_header Host $http_host;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "Upgrade";
            proxy_pass_request_headers on;
    }


    location /wordpress {
        root /var/www;
        try_files $uri $uri/wordpress/ /wordpress/index.php$is_args?$args;

            location ~ \.php$ {
            include fastcgi_params;
            fastcgi_pass unix:/run/php/php8.1-fpm.sock;
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                    include snippets/fastcgi-php.conf;
                    fastcgi_buffers 1024 4k;
                    fastcgi_buffer_size 128k;
            }
    }

As you can seem, there is a static, NextJS-based frontend for WordPress. And generally, it works just great. There is this one quirk that does not work, though, and I'm not sure if it is a WordPress issue or a Nginx issue.

  • When the user navigates to /wordpress, then we see content from wordpress, which is fine
  • When the user navigates to /wordpress/graphql, then the grahpql endpoint is working just fine
  • When the user navigates to /wordpress/wp-admin, then the things break. There is a redirect loop, and the brauser reports that the site is not redirecting properly and so on.
  • when the user navigates to /wordpress/wp-admin/index.php, then everything works fine though.

So where does this come from? Is it a Nginx thing? WordPress thing? How do I fix this?

Edit 1: Added curl -vvv output:

C:\Users\alank>curl -vvv https://mydomain.ee/wordpress/wp-admin
*   Trying 194.204.13.171:443...
* Connected to mydomain.ee (194.204.13.171) port 443 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* ALPN: server did not agree on a protocol. Uses default.
* using HTTP/1.x
> GET /wordpress/wp-admin HTTP/1.1
> Host: mydomain.ee
> User-Agent: curl/8.0.1
> Accept: */*
>
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
< HTTP/1.1 302 Found
< server: nginx/1.18.0 (Ubuntu)
< date: Tue, 22 Aug 2023 10:19:10 GMT
< content-type: text/html; charset=UTF-8
< transfer-encoding: chunked
< expires: Wed, 11 Jan 1984 05:00:00 GMT
< cache-control: no-cache, must-revalidate, max-age=0
< link: <https://mydomain.ee/wordpress/wp-json/>; rel="https://api.w.org/"
< x-redirect-by: WordPress
< location: https://mydomain.ee/wordpress/wp-admin/
<
* Connection #0 to host mydomain.ee left intact

Edit 2: curl -vvv with trailing slash:

C:\Users\alank>curl -vvv https://mydomain.ee/wordpress/wp-admin/
*   Trying 194.204.13.171:443...
* Connected to  mydomain.ee (194.204.13.171) port 443 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* ALPN: server did not agree on a protocol. Uses default.
* using HTTP/1.x
> GET /wordpress/wp-admin/ HTTP/1.1
> Host: mydomain.ee
> User-Agent: curl/8.0.1
> Accept: */*
>
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
< HTTP/1.1 302 Found
< server: nginx/1.18.0 (Ubuntu)
< date: Tue, 22 Aug 2023 11:13:01 GMT
< content-type: text/html; charset=UTF-8
< transfer-encoding: chunked
< expires: Wed, 11 Jan 1984 05:00:00 GMT
< cache-control: no-cache, must-revalidate, max-age=0
< link: <https://mydomain.ee/wordpress/wp-json/>; rel="https://api.w.org/"
< x-redirect-by: WordPress
< location: https://mydomain.ee/wordpress/wp-admin/
< 
* Connection #0 to host mydomain.ee left intact
Richard Smith avatar
jp flag
I do not understand the purpose of `$uri/wordpress/` in your `try_files` statement. I would expect to see `$uri/`. Also, do you have `index index.php;` or `index index.html index.php;` defined somewhere?
Zayatzz avatar
cn flag
I have `index index.html index.htm index.nginx-debian.html; ` in the nginx config - updated the initial config block. As for the purpose of $uri/wordpress/- I'm no server guru. I copied the conf from some example or another, saw it worked and saw no need to change it further.
jp flag
Could you test with `curl -vvv https://example.com/wordpress/wp-admin` what the redirect loop is?
Zayatzz avatar
cn flag
@EsaJokinen - added the curl output to the post.
jp flag
So, `https://example.com/wordpress/wp-admin` forwards to `https://example.com/wordpress/wp-admin/` with a slash, and what happends next?
Zayatzz avatar
cn flag
@EsaJokinen added the curl output with trailing slash too.
Zayatzz avatar
cn flag
I did some more googling. Could it be this issue: https://wordpress.stackexchange.com/questions/170165/wordpress-wp-admin-https-redirect-loop AS I understand (not being an actual server guy), that the site sits behind a load balancer (that was configured by someone else.
jp flag
On the other hand, `/wordpress` doesn't? But indeed the second `curl` shows the problem. I can't see anything in this configuration causing this. Maybe Wordpress interprets it differently and performs some internal redirection?
Zayatzz avatar
cn flag
I guess we at least established that Wordpress is the cause of this, not my Nginx config. That is a step forward, too, in my book.
Alexander Pavluchenko avatar
pl flag
looks like a typical redirect loop- check both the Nginx error and access logs, as well as the WordPress debug logs, to get more insights into the issue
Alexander Pavluchenko avatar
pl flag
Adjust your location /wordpress block as follows: location ^~ /wordpress/ { root /var/www; try_files $uri $uri/ /wordpress/index.php$is_args$args; } The ^~ modifier ensures that this location block is chosen as a match if the prefix matches, and no regular expression matches, which is a good measure to ensure the /wordpress/wp-admin and /wordpress/wp-admin/ requests end up in the same block.
Zayatzz avatar
cn flag
Nginx access and error logs do not give any information. The curl that @EsaJokinen had me do provide more insight. I'll try the nginx settings changes, but it seems that both requests end up in the same block anyway. That is not the problem. AS you can see both curl requests have same response.
Score:0
jp flag

The /wordpress/wp-admin/ redirects to itself.

Have you tried using the exact example for this use case from the official Nginx WordPress documentation?

Here, modified for your use case where it should not affect .php outside /wordpress/:

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

        location ~ \.php$ {
                fastcgi_split_path_info ^(/wordpress)(/.*)$;
        }
}

Your fastcgi_split_path_info differs from this recommendation.

Zayatzz avatar
cn flag
I'll test it out. Thanks.
Score:-1
sa flag

one can try using following in the location block (feel free to adjust path as needed) i.e. /wp-admin/index.php?$args depending on your environment/setup:

try_files $uri  $uri/ /index.php?$args;

REF:

ws flag
That's not going to help when wordpress is not configured at the root of the path
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.