I have a weird situation with one of my websites, still in development in AWS. I have nginx 1.9.9 with HHVM 3.6.6-1.amzn1.x86_64 on a t2.micro. It's not publicly accessible.
I have a custom written website in the root of the domain, I have Wordpress in the /blog directory, and wordpress admin is in /blog/wp-admin. The custom site has various files including index.php. Wordpress has index.php and all sorts of other things in the blog directory, wp-admin uses index.php as well.
I can load the custom website, it fully works. Wordpresss admin fully works. The Wordpress blog home screen / story list fully works. The problem is when I click on any of the blog article links to view it in full it shows the custom website home index. So, to say it another way
http://www.example.com/index.php - custom website works
http://www.example.com/blog/index.php - blog index works
http://www.example.com/blog/2015/storyname - story load doesn't work with permalink %postname% regardless of text in post name - http://www.example.com/index.php loads
http://www.example.com/blog/2015/?p=96 - story load works
http://www.example.com/blog/wp-admin/ - admin works
When I click the story link I get the same page content as if I'd clicked http://www.example.com/index.php except the images don't load as they're done with relative URLs
http://www.example.com/blog/2015/storyname
When I load the site root /index.php I get the following debug headers back (see my config below for how they're generated)
Z_LOCATION: PHP MAIN
URI: /index.php
Z_DOCUMENT_ROOT: /var/www/hr
Z_FASTCGI_SCRIPT_NAME: /index.php
Z_REQUEST_FILENAME: /var/www/hr/index.php
When I load /wp-admin/ I get these headers back
Z_LOCATION: PHP MAIN
URI: /blog/wp-admin/index.php
Z_DOCUMENT_ROOT: /var/www/hr
Z_FASTCGI_SCRIPT_NAME: /blog/wp-admin/index.php
Z_REQUEST_FILENAME: /var/www/hr/blog/wp-admin/index.php
When I load the blog home /blog/index.php I get these headers back
Z_LOCATION: PHP MAIN
URI: /blog/index.php
Z_DOCUMENT_ROOT: /var/www/hr
Z_FASTCGI_SCRIPT_NAME: /blog/index.php
Z_REQUEST_FILENAME: /var/www/hr/blog/index.php
When I try to load this URL http://www.example.com/blog/2015/storyname I get the following headers back. Z_REQUEST_FILENAME (above) shows the wrong URL being loaded.
Z_LOCATION: PHP MAIN
URI: /index.php
Z_DOCUMENT_ROOT: /var/www/hr
Z_FASTCGI_SCRIPT_NAME: /index.php
Z_REQUEST_FILENAME: /var/www/hr/index.php
I have no idea why it tries to load the site root index.php when I click that URL. Clues:
- Changing the Wordpress permalink structure from %postname% to ?p=123 fixes the issue
- None of the other permalink structures helps at all
Why would this be a problem just for viewing blog articles???? I wonder if it's something to do with the try_files?
There's nothing in the hhvm error log, there's nothing in the nginx error log. The access log shows the following when I request that last URL
(IP removed) - - [10/Jan/2016:08:22:19 +0000] "GET /blog/2015/storyname HTTP/1.1" 200 4424 "http://www.example.com/blog/" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0" "-" "0.050"
Here's my nginx site config. I haven't included the main nginx.conf as I don't think it's relevant. NB I have updated this work the working code.
server {
server_name www.example.com;
root /var/www/hr;
access_log /var/log/nginx/hr.access.log main;
# Default location to serve
location / {
try_files $uri $uri/ /blog/index.php?$args;
add_header Z_LOCATION "hr_root"; add_header URI $uri; # DEBUG
}
location ~* \.(jpg|jpeg|png|gif|css|js)$ {
log_not_found off; access_log off;
add_header Z_LOCATION "STATIC RESOURCES REGEX"; add_header URI $uri; # DEBUG
}
# Send HipHop and PHP requests to HHVM
location ~ \.(hh|php)$ {
fastcgi_keep_conn on;
fastcgi_intercept_errors on;
fastcgi_pass php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
# DEBUGGING
add_header Z_LOCATION "PHP MAIN"; add_header URI $uri;
add_header Z_DOCUMENT_ROOT "$document_root"; add_header Z_FASTCGI_SCRIPT_NAME "$fastcgi_script_name";
add_header Z_REQUEST_FILENAME "$request_filename";
}
}
# Forward non-www requests to www
server {
listen 0;
server_name example.com;
return 302 http://www.example.com$request_uri;
}
Any thoughts, ideas, or help appreciated. This is a fairly curly one, for me, but I suspect it will be a simple change to fix it.
The WordPress content delivery is performed by the
/blog/index.php
script. Presumably, this is invoked when your send the URI/blog/
because of the$uri/
clause intry_files
. But you have no rules to invoke/blog/index.php
for any other URI beginning with/blog/...
.One option is to make WorkPress the default:
Alternatively, add another location block to handle only the URIs that begin with
/blog/...
: