Search code examples
phpwordpressnginxheadlessstatic-site

Unusual NGINX Wordpress Configuration Issues (Headless Wordpress + Static Site Front-End on Single Domain)


I have a very particular use case where I use Wordpress as a CMS backend (mostly in a headless configuration), with the exception of certain URLs that I want the usual NGNIX/Wordpress config to apply. Specifically:

Most url requests to the NGINX root should serve static HTML files from a subdirectory. I have this identified in this location block within the server block of my virtual hosts file:

location / {
    root /var/www/html/node/website.com/_build;
    index index.html;

    try_files $uri $uri.html $uri/ /404/index.html;
}

But all Wordpress specific files (i.e. those behind a /wp-* URL) should still be served by Wordpress. Eventually, a few specific URLs (i.e. /shop, /my-account) should also be served by Wordpress and not the static html files, but I can work on that later. I currently have the WP-specific location identified as:

location ~* /wp- {
    index index.php;
    try_files $uri $uri/ /index.php?$query_string;

    location ~ \.php$ {
        root /var/www/html/php/website.com;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
    }
}

This works partially. website.com/wp-json works correctly. Most URL endpoints are served from the _build subdirectory, assuming a relevant HTML file exists. But, website.com/wp-admin and website.com/wp-login.php auto-download the relevant PHP files instead of processing them.

This tells me there is an issue with passing the index.php files to php-fpm, but I can't figure out where the break is. FWIW, I am duplicating the location ~ \.php$ block in the server block as well, outside of the wp- block.

Any suggestions?

Also, if anyone has suggestions for correct configuration of specific "front-end" URLs (i.e. /shop,/my-account) to be served by Wordpress vs. the _public HTML files, that would be really helpful and awesome.


Solution

  • Turns out this was a caching issue in Chrome. An incognito window load showed that my location blocks were written correctly and working. Leaving this question here in case someone has a better suggestion for what I am trying to do, or can use this as a reference.